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.

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.

On my menu it does say original next to one of them, but tapping on the options (any of the options) doesn’t do anything. My phone is set to french because I’m an immigrant in a french-speaking region and am making sure to engage with the language as much as possible. But this means the autodub puts a stupid robo-french voice on everything – and it’s not always a faithful translation either.

At this point I just let the creators know that YouTube is making their videos unwatchable to people with different language settings and that they can disable this when they upload videos.

I’d argue that the resulting tragedy is the moron’s fault in all of the ways that matter. The things the post are “warning” about are still alarmism.

“quantum teleportation” is the correct technical term. The problem is articles being written by people who don’t realize this is a technical term that needs explanation.

I use vim, or spacemacs with evil mode (emacs distribution with sensible shortcuts and vim emulation). Or VSCode with spacemacs emulation.

You will pass your current productivity in less than a month. All of the things you describe are easily done in VSCode with vim emulation (I prefer the full spacemacs emulation but it’s not actually a huge difference). You won’t have to move your hands away from the normal typing spot on your keyboard – no home and end, just 0 and $. No control+arrow keys, just w and b (or e or even more motion options). Highlighting is as easy as v and then motion commands. And there are so many more useful things that vim (and vim emulation) make simple and fast. Orthogonal VSCode features like multi cursors still work.

You have to be explicit about which module you’re using at all times, even though 99% of the time only one could apply. When the type class resolution is unique, but complicated, there’s no mental overhead for the Haskell programmer but getting all the right modules is a lot of overhead for the OCaml programmer. It also lets us write functions that are polymorphic under a class constraint. In OCaml you have to explicitly take a module argument to do this. If you want to start composing such functions, it gets tedious extremely fast.

And then even once you’re using a module, you can’t overload a function name. See: + vs +.. Basically modules and type classes solve different problems. You can do some things with modules that you cannot ergonomically do with type classes, for example. create a bit-set representation of sets of integers, and a balanced search tree for sets of other types, and expose that interface uniformly from the same module functor. But Haskell has other ways to achieve that same functionality and more.

OCaml’s type system cannot replicate the things you can do with Haskell’s higher kinded types, type families, or data kinds at all (except for a fraction of Haskell’s GADTs).

Largely reasonable?

Haskell is not good for systems programming which sums up about 60-70% of that post. Laziness is lovely in theory but many industry uses of Haskell use stricthaskell for all or most of their code, so I certainly agree with that part too.

Their largest complaint about using Haskell for small non-systems programs seems to be the mental overhead induced by laziness. But for me, for small programs where performance isn’t a huge concern (think Advent of code or a script for daily life) laziness reduces my mental overhead. I think that author is just especially concerned about having a deep understanding of their programs’ performance because of their systems background. I worry about performance when it becomes relevant. Debugging Haskell performance issues is certainly harder than strict languages but still totally doable.

The lack of type classes or other form of ergonomic overloading in OCaml is easily the single “feature” most responsible for the language never taking off.

As a Haskell programmer, “OCaml has the nicest type features” hurts just a little bit.

I sometimes teach a course in OCaml. The students who are very engaged inevitably ask me about Haskell, I encourage them to try it, and then they spend the rest of the semester wondering why the course is taught in OCaml. Bizarre how different that is from when colleagues in industry want to try Haskell.

Is Printf.printf not a good generic print function? It’s even variadic!

Yeah, I like subleq.

• compiler is extremely fast, faster even than tinycc
• strongly statically typed: all values are ints. Since it’s all of them, you don’t even need to write it!
• memory safe: the entire (virtual) address space is guaranteed to be accessible at all times so there’s no way to leak any of it (can’t release it anyway) or to segfault (it’s all accessible).

Subleq is the obvious winner in my mind.