For those unaware, HP recently secured one of the most idiotic deals I have ever seen a state-level government agree to: all laptops in Quebec purchased with public funds must be HP laptops. They said this will “encourage competition in the laptop market.”

I can’t wait to see this new decision blow up in HP’s face.

https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines

Clickbait.

Yeah it depends what you’re doing. I do a lot of circuit modeling where different subsystems need to talk to each other. The solutions are either Rcs (and a bunch of custom drop logic) or a parent struct holding all the others. Both are awkward. But in other programming domains I’ve found rust pleasant.

Eh rust still has issues in some domains, e.g., when cyclic data is appropriate. You can do it, but it’s annoying. To me, Haskell is really peak programming, but I know that’s opinionated and most won’t agree.

Vscode can do cross-file renames in pretty much any language. An LSP that doesn’t support this is not doing its job.

Obra Dinn and outer wilds are two of my top 3 games ever made. If you liked outer wilds I’m pretty sure you’ll like Obra Dinn.

Blue prince is great until you “win” the first time. After that, imo, it starts falling off. Slowly at first, then harder. I have completionist friends to whom I have given it negative reviews. But if you just want to win and explore the space for a while, even potentially hundreds of hours if you don’t use guides, it’s fun. Don’t start a game day aiming to work on something specific. Work on what comes your way, and it is easily possible to make substantial progress every single game day.

The C Preprocessor also does all of those things. That’s expected of a preprocessor. If you say “you can write java code with a bit of extra sugar and JPlus turns it back into ‘regular’ java,” then that’s a preprocessor.

I don’t think anyone’s calling it a scam, but it’s pretty clear as an outside observer that a very specific point was questioned (about where JPlus fits into the existing ecosystem) and your replies have very little to do with that topic.

Also, your replies really do look AI-written. I know it’s hard to be sure, but humans expressing a point don’t usually write summaries in the fashion of your replies and LLMs almost always do.

Anyway, personally, if I have an existing application java program then maybe there’d be an argument to use a lightweight syntax extension to continue developing it more safely. But if I were starting a new project, whether a library or application, I would just use Scala or Kotlin from the get-go. The JVM platform is already versatile enough to get us much more than just some basic extra type safety and boilerplate generation. I’m all for static analysis tools, it’s just (again) hard to see what you get from JPlus that you can’t get from either groovy or a better language.

Your replies don’t address that at all.

But neither of them even close to predate combinatory logic (1920), which is what OP claims to be the spark for functional programming. It’s an argument I buy.

The corresponding work on imperative programming models was done by Turing and Church in the 1930s.

I don’t need syntax highlighting for that in Haskell either. My usual highlighting just leaves them both in the default text color.

And I’m specifically arguing that the other things on your list do not inherently make code bad.

Raymond’s document does not, and I believe never has, mentioned Haskell.

I also disagree with him, given that it does recommend Java, but the quote is correct.

The only things on the bad list that I agree with are top-level type inference and small communities. And ocamls windows support is terrible. Haskell’s is more than ok now.

In Haskell, any style guide worth its salt requires annotations on top level functions, and many of them also require annotations on local bindings. This pretty effectively works around the problem.

Bad code will be unreadable in any language of course. But the other things don’t themselves make code unreadable once you’re actually familiar with the language and its ecosystem.

What does any of this have to do with LLMs?

I mean I agree with the conclusion but the confused people here are… people. I think if you ask an LLM about the “common name Rach,” it’ll also tell you that you probably mean Rachel.

I believe you didn’t intend to, but you did claim it, twice. Hence why the commenter I initially replied to (in which I guessed you meant the common _nick_name) was confused.

Then you replied to me saying “it’s literally from the bible [so it’s a common name]” implying that you disagreed with me about it being a nickname and you did really mean it as a given name.

Hopefully that explains the confusion.

Rachel is a very common given name. “Rach” is a fairly common nickname for it. “Rach” is not a common given name. (This matches what I said above.)

I just took a look at some baby name sites to try and find some statistics. I actually can’t find a single person named “Rach” because all the sites assume I want statistics for the long form, even when I’m on the page for “Rach” and they also have a page for “Rachel.” I’m interpreting this as being given the short form as your name is extremely rare.

Given that OP says this is a common English name (it’s not), I have to imagine that they’re referring to the common short form of Rachel. Pronounced as just the first syllable.

The LLM in the most recent case had a monumental amount of context. I then gave it a file implementing a breed of hash set, asked it to explain several of the functions which it did correctly, and then asked it to convert it to a hash map implementation (an entirely trivial, grunt change, but which is too pervasive and functionality-directed for an IDE to have a neat function for this).

It spat out the source code of the tree-based map implementation in the standard library.

I’ve only tried a handful of times, but I’ve never been able to get an LLM to do a grunt refactoring task that didn’t require me to rewrite all the output again anyway.

Did you play on original PS2? The game was computationally a bit ahead of its time and the hardware wasn’t capable enough to run it smoothly. The resulting lag and stuttering could make some really weird things happen, and I remember some people saying if the console was struggling more than usual (overheating etc) it could become impossible to properly play in some areas.

If you still own a copy, try emulating it to on a modern PC instead. PCSX2 does some wild stuff internally and can emulate PS2 code on a modern system faster than it ran on the PS2. SOTC is actually a pretty common performance benchmark. As long as you don’t try to use the emulator’s graphics upscaling (which increases computational load a ton) it runs much better than on console.

This is, nonobviously, the definition of the cutting stock problem. The cutting stock is your tables, from which you want to cut item-sized chunks. A table that can hold two items is just two tables that can only hold one. Mathematically, you can’t do it faster than enumerating all the possibilities and checking them. But that doesn’t help you much.

There are plentiful ready-made solutions online, or you can do it with an SMT solver if you prefer.

This is definitely true for code but in terms of information retrieval and explaining complex topics, they have gotten much better in the sense that they can cite real sources (with links) now.

The analysis and synthesis that they do of those sources is still often bogus though. I’ve had one explain some simple Magic the Gathering rules with real-looking words but completely bogus interpretations and conclusions, but it did cite the correct rulebook with a link. I’ve also had one give a pretty strong overview of the construction and underlying theory of a particular compiler (a specific compiler, not the language it compiles) that matches up quite well with my own fairly deep understanding of that compiler.

Overall the real information is better, but the hallucinations look more real too. And they’re still pretty unhelpful for programming in my experience.