3 ms·

Don't want to start a flamewar but... why choose OCaml over Haskell nowadays? Want purity, elegance and best community resources? Go with Haskell. Want Functio

by nnq 11y ago

Don't want to start a flamewar but... why choose OCaml over Haskell nowadays? Want purity, elegance and best community resources? Go with Haskell. Want Functional+OOP+kitchensink? Go with Scala. Want .NET? Go with F#. Want a strict/eager Haskell? Apply for a job at Standard Chartered (they say they have an in-house strict and better optimizing Haskell compiler). What would X be, so that you would be able to say "Want X? Go with OCaml"?

ufo 11y ago
On a practical level, I'm very fond of the strict evaluation and the lack of purity. Its easier to write "traditional" imperative algorithms when you don't need to use monads or monad transformers everywhere. When it comes to resources, I don't think Haskell is strictly superior. opam, merlin, and utop are pretty nice... I'm also very fond of the menhir parser generator. On a theoretical level, Ocaml does have some neat things missing from Haskell, like its module system (with functors), polymorphic variants, etc... --- BTW, I wouldn't dump Ocaml in the "object oriented" side of things together with Scala. Nowadays the OO infrastructure is more commonly used for polymorphic variants than for OO, to be honest.
- pauldirac137 11y ago
  I would hesitate to call polymorphic variants "part of the OO infrastructure". They are really orthogonal to OO, but they do make OO less necessary. Ironically, OCaml has a really nice OO system but it's rarely used because with modules and functors there is little need for it. Put differently, a lot of the conventional use for OO is as a poor man's module system, and when you have a really good module system, you only use OO when you absolutely need the OO kind of polymorphism, and those cases are surprisingly rare (like existential types in Haskell).
  - ufo 11y ago
    I was thinking about how both those features use row-polymorphism.
willtim 11y ago
Mirage?
lpw25 11y ago
Modularity
pauldirac137 11y ago
Well, maybe "writing a compiler"? or "building a multimillion-dollar Wall Street financial services firm"? :-) In fact, I love and use both Haskell and Ocaml, and I view the two languages as cousins. Both are functional. Both have features the other doesn't. Ocaml has the best module system in the business, with functors for module abstraction (unbelievably useful). This is much better than the current Haskell module system, though Backpack may narrow the gap. Ocaml also has polymorphic variants, which are surprisingly useful. Ocaml has some convenience features like named/optional arguments that Haskell doesn't. And oddly enough, the lack of purity in Ocaml (if used judiciously) can be a real win. You can do imperative programming without jumping through a lot of hoops. You can have code which is purely functional from the outside but which uses imperative idioms internally for efficiency (yes, I know about unsafePerformIO in Haskell, but it's much easier to do this sort of thing in Ocaml). And Ocaml is usually faster both in compilation time and run time. My overall take on it is that I prefer Haskell for small-scale programming but I prefer Ocaml for large-scale programming. YMMV.
- willtim 11y ago
  Minor nitpick: Haskell has the ST monad for using "imperative idioms internally". There is no need for unsafePerformIO.
  - pauldirac137 11y ago
    You're right, but ST is also implemented using unsafePerformIO. The larger point is that you don't need to dress up a type signature with ST or IO just to use imperative code internally which can't leak out to the user level. Whether this is good or bad is a matter for debate, but used judiciously I think it's good.

by nnq 11y ago

ufo 11y ago

On a practical level, I'm very fond of the strict evaluation and the lack of purity. Its easier to write "traditional" imperative algorithms when you don't need to use monads or monad transformers everywhere. When it comes to resources, I don't think Haskell is strictly superior. opam, merlin, and utop are pretty nice... I'm also very fond of the menhir parser generator. On a theoretical level, Ocaml does have some neat things missing from Haskell, like its module system (with functors), polymorphic variants, etc... --- BTW, I wouldn't dump Ocaml in the "object oriented" side of things together with Scala. Nowadays the OO infrastructure is more commonly used for polymorphic variants than for OO, to be honest.

pauldirac137 11y ago
I would hesitate to call polymorphic variants "part of the OO infrastructure". They are really orthogonal to OO, but they do make OO less necessary. Ironically, OCaml has a really nice OO system but it's rarely used because with modules and functors there is little need for it. Put differently, a lot of the conventional use for OO is as a poor man's module system, and when you have a really good module system, you only use OO when you absolutely need the OO kind of polymorphism, and those cases are surprisingly rare (like existential types in Haskell).
- ufo 11y ago
  I was thinking about how both those features use row-polymorphism.

willtim 11y ago

Mirage?

lpw25 11y ago

Modularity

pauldirac137 11y ago

Well, maybe "writing a compiler"? or "building a multimillion-dollar Wall Street financial services firm"? :-) In fact, I love and use both Haskell and Ocaml, and I view the two languages as cousins. Both are functional. Both have features the other doesn't. Ocaml has the best module system in the business, with functors for module abstraction (unbelievably useful). This is much better than the current Haskell module system, though Backpack may narrow the gap. Ocaml also has polymorphic variants, which are surprisingly useful. Ocaml has some convenience features like named/optional arguments that Haskell doesn't. And oddly enough, the lack of purity in Ocaml (if used judiciously) can be a real win. You can do imperative programming without jumping through a lot of hoops. You can have code which is purely functional from the outside but which uses imperative idioms internally for efficiency (yes, I know about unsafePerformIO in Haskell, but it's much easier to do this sort of thing in Ocaml). And Ocaml is usually faster both in compilation time and run time. My overall take on it is that I prefer Haskell for small-scale programming but I prefer Ocaml for large-scale programming. YMMV.

willtim 11y ago
Minor nitpick: Haskell has the ST monad for using "imperative idioms internally". There is no need for unsafePerformIO.
- pauldirac137 11y ago
  You're right, but ST is also implemented using unsafePerformIO. The larger point is that you don't need to dress up a type signature with ST or IO just to use imperative code internally which can't leak out to the user level. Whether this is good or bad is a matter for debate, but used judiciously I think it's good.