

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.
Programmer, University lecturer, and gamer. I’m also learning French and love any opportunity to practice :)


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.


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.
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.