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.

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.

There is no official definition, in part because there isn’t any formal way to define the term that satisfies our intuition.

Most treatments will handle “transpiling” as a special case of “compiling” and some will even handle decompilation as a special case where the object language is higher level than the source. Of course, even defining “higher level” can be quite hard.

Plenty of languages “compile to C” and I see no issue with saying something “compiles to js,” especially given that js mostly lacks features of purescript rather than the other way around.

“Monadic type” has something like three meanings depending on context, and it’s not clear which one you mean. One of them is common in math, but not so common in programming, so probably not that. But neither “parametric types with a single argument” nor “types that encode a category-theoretic monad” have the property you say, as far as I know.

I imagine you’re probably referring to the latter, since the optional monad exists. That’s very different from returning null. The inhabitants of Integer in Java, for example, are the boxed machine ints and null. The inhabitants of Optional[Integer] (it won’t let me use angle brackets here) are Optional.of(i) for each machine int i, Optional.empty(), and null.

Optional.empty() is not null and should not be called a “Null object.” It’s also not of type Integer, so you’re not even allowed to return it unless the function type explicitly says so. Writing such function types is pretty uncommon to do in java programs but it’s more normal in kotlin. In languages like Haskell, which don’t have null at all, this is idiomatic.

Which, to be fair, is also derived from a word which would be most accurately (with English vowels) pronounced as mah-nuh. Although at this point “manna” is definitively also a word of English whose correct pronunciation is with /æ/.

I’ve only ever seen “one-time” in cryptography to refer to One-Time Pads (OTP). They are literally uncrackable (because every possible plaintext could be encoded by every possible ciphertext) but they achieve that by using a shared private key. The cipher becomes attackable if the key is re-used, hence the “one-time.”

But that key has to be exchanged somehow, and that exchange can be attacked instead. Key exchange algorithms can’t necessarily transfer every possible OTP which means eavesdropping on the exchange would make an OTP attackable. So the best option we know of that doesn’t require secret meetings to share OTPs* really is to use RSA encryption. Once we have efficient quantum-resistant schemes, they’ll be the best option we know.

* and let’s be honest, secret meetings can be eavesdropped on as well.

Bril is the only compiler IL I know of that is specifically designed for education.

R. Kent Dybvig’s compilers course has had approximately 15 “intermediate” representations designed for his course since at least 2004 – a consequence of teaching the course using the nanopass compiler framework for scheme. You could broadly divide these into “representations that are restrictions of scheme,” and “representations that are increasingly-annotated versions of UIL” where UIL is the underlying intermediate representation. As far as I know, UIL was also designed for this course.

How does this compare with GumTree? It’s weird that the page doesn’t even mention existing state-of-the-art tools for this task.

edit: I’ve compared GumTree and difftastic myself while working on a project this past week. Difftastic is harder to use programatically (the JSON format is unstable and leaves something to be desired) but other than that it’s miles and miles better.

Most recently, KeyWe and modded Keep Talking with friends. Solo, still ol’ reliable slay the spire.

I have a plan to teach someone how to play schnapsen and crazyhouse chess tomorrow so that’s exciting.

I find there’s a lot less variety in my monster train runs. Most classes have a distinctly best strategy and the artifacts generally also funnel you towards that strategy. For example, I can’t remember the last time I played an Umbra run that didn’t set up a morsel engine behind a warden or alloyed construct - as far as I’m concerned, those are the same strategy, it doesn’t feel different. The only other build I think is viable is just “play Shadowsiege,” which rarely happens early enough to build for it.

Every class in STS has at least three viable archetypes and almost every run within those archetypes still feels different to me.