Coming from Haskell, OCaml always felt a bit strange to me. The double semicolons, the inconsistency in the standard library between curried and uncurried functions etc. Maybe I’m confusing it with Standard ML though, can’t remember.
I know double semicolons are a thing, but I’ve never had to use them. I forget what they’re for, but yeah it’s supposed to be an escape hatch for something that shouldn’t be happening iirc.
The curried snd uncurried functions… Maybe you are confusing with SML, because everything in ocaml is curried by default. Though admittedly the standard library could be more complete, but I personally am happy to use third party dependencies for less common things.
When you want to print something, you can’t just Printf.printf x, you have to explicitly give it instructions on how to print a value of that specific type.
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.
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.
OCaml.
Sad I had to scroll to the end to see this.
Ocaml is brilliant and has the nicest type features. It’s almost like Haskell but more approachable imo.
Coming from Haskell, OCaml always felt a bit strange to me. The double semicolons, the inconsistency in the standard library between curried and uncurried functions etc. Maybe I’m confusing it with Standard ML though, can’t remember.
I know double semicolons are a thing, but I’ve never had to use them. I forget what they’re for, but yeah it’s supposed to be an escape hatch for something that shouldn’t be happening iirc.
The curried snd uncurried functions… Maybe you are confusing with SML, because everything in ocaml is curried by default. Though admittedly the standard library could be more complete, but I personally am happy to use third party dependencies for less common things.
I’ve recently been trying to learn OCaml and find it really nice. The major pain points are
Is
Printf.printfnot a good generic print function? It’s even variadic!When you want to print something, you can’t just
Printf.printf x, you have to explicitly give it instructions on how to print a value of that specific type.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.
What are your thoughts on this comparison? https://github.com/sidkshatriya/me/blob/master/007-My-Thoughts-on-OCaml-vs-Haskell-Rust-2023.md
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.