Edit: but in this case, apparently the book was written for a course at Cornell where they teach both functional and imperative programming using the same language.

So my guess would be less that Haskell is not these things (nor couldn't it be) but rather that OCaml has had the external forces necessary to optimise for these things above all else.

Plus, though both languages allow defining new infix operators, ocaml coders are much more restrained about it than haskellers, and I hate having to figure out what >>>>$=<<< does when it shows up in code.

- Pragmatism: The ocaml community has a stronger focus on practical real projects. This is shown by the kind of packages available on the ecosystem and the way those packages are presented. (A number of Haskell packages I've tried to use often seen to be primarily intellectual pursuit with little documentation on actually using them).

- Simplicity: Haskell does have some amazing features, but it has so many different ways to do things, so many compiler flags, code can look vastly different from one codebase to another. It's kind of the c++ of FP. Ocaml is definitely more cohesive in its approach.

Tooling: last I used Haskell the whole ecosystem was pretty rough, with two package managers and a lot of complexity in just setting up a project. Ocaml is not at the level of rust or other modern languages, but is definitely a stop above I'd say.

Everyone talks a good line about more powerful, expressive programming languages till they need to put in the work. Ten years effort to program like ten people the rest of your life? I'm 69 now, I can see how such an investment pays off.

I moved to OCaml. Studying their library source code is the best intro ever to functional programming, but I felt your "all the way" pull and switched to Haskell. (Monads make explicit what a C program is doing anyway. Explicit means the compiler can better help. What it comes down to is making programming feel like thinking about algebra. This is only an advantage if one is receptive to the experience.)

I'm about to commit to Lean 4 as "going all the way". Early in AI pair programming, I tested a dozen languages including these with a challenging parallel test project, and concluded that AI couldn't handle Lean 4. It keeps trying to write proofs, despite Lean's excellence as a general purpose programming language, better than Haskell. That would be like asking for help with Ruby, and AI assuming you want to write a web server.

I now pay $200 a month for Anthropic Max access to Claude Code Opus 4 (regularly hitting limits) having committed to Swift (C meets Ruby, again not just for macOS apps, same category error) so I could have first class access to macOS graphics for my 3-manifold topology research. Alas, you can only build so high a building with stone, I need the abstraction leverage of best-in-category functional languages.

It turns out that Opus 4 can program in Lean 4, which I find more beautiful than any of the dozens of languages I've tried over a lifetime. Even Scheme with parentheses removal done right, and with far more powerful abstractions.

That being said, Haskell is pretty nice as well but I'd pick OCaml for real world stuff.

One thing that bothered me with both these languages is that people not fluent with FP could write code that isn't idiomatic at all. It's probably a bit harder to do in Haskell.

OCaml is immediate by default instead of lazy, and allows imperative code with side-effects. Both escape hatches from the pure FP world.

So, performance is easier to reason about and you can interact with your side-effecty real world stuff without having to reorganize your whole program around the correct monad.

Most of the time you want your loops to be higher order functions but once in awhile you want to just build a vector from a for loop. OCaml let's you do it without it being a whole intervention.

Better spend some time having fun with std::variant, visit, and ranges transformers.

Depends on the correctness requirements in question. But overall you are 100% correct about this.

FP, among other aspects, enables and promotes some ways of reasoning, for instance when mutation is avoided, that can be relatively easy to use to verify correctness of certain types of properties. For instance, induction proofs and some other kinds of mathematical proofs. However, for some other types of correctness properties, imperative programming can be easier to reason about than FP. One possible example is in regards to implementation of algorithms, where for instance an implementation of quicksort in C is likely to be more concise and clearer than a "true" quicksort implementation in Haskell. Another possible example is (if one assumes that FP requires garbage collection) that of hard real-time systems, for instance some types of medical devices, where even though some types of garbage collection may be viable, approaches like forgoing dynamic memory allocation (no malloc, no reference counting, no types of garbage collection, etc.) may be easier to reason about regarding achieving the correctness requirement of hard real-time.

Overall, I definitely agree that ML and FP are not the best for achieving correctness in all cases.

I personally like to pick and choose between FP and other approaches, and mix them in different ways dependent on the project or task at hand. Like, a purely functional interface with internal mutation in the implementation for optimization. Or, some mutable API that uses FP for some aspects of the implementation where FP is easier to reason about.

> I can tell you that debugging a compiler written in ML is a dumpster fire compared to debugging a compiler written in C++. If take C++ over any FP language for compilers any day of the week.

For larger compilers for some requirements, I could for some projects imagine that this is true. But, for smaller compilers with relatively few requirements, the pattern matching and tagged union features of modern ML languages are very popular, and I like having access to those features when writing smaller compilers. If you do not mind spending the time to expound on this topic, I would very much like to know more. Or, maybe some links, like blog posts, that discuss this topic. I am genuinely curious. A blog post could also be shared elsewhere, instead of just lost in some Hacker News discussion. (Maybe I should start blogging myself).

Also, Hacker News/Ycombinator is censorship-infested.

Do you simply dislike the OCaml syntax or is it some particular quirk?

> the variable scope thing

The what thing? Variables are just lexically scoped, are you referring to shadowing?