7 ms·

What reasons are there for choosing OCaml over Haskell, either from a learning perspective or a practical one?

by jonahx 8y ago

nv-vn 8y ago
OCaml is more of a multi-paradigm language than Haskell. It's not purely functional, so you can easily fallback into imperative code if you need (you can use mutable variables, I/O, mutable arrays, hashmaps, for loops, while loops, etc.). It's also object-oriented (though this feature is not widely used) and has a very powerful module system that few other languages can compare to. What I like about it from a learning perspective is that it makes a transition into functional programming much simpler than it would be with Haskell, where you have to completely change the way you program from the very beginning.
- moocowtruck 8y ago
  haskell is great at being imperative too look at chris done's work on xml parsing haskell and c; nice example
  - robert_tweed 8y ago
    I'm not sure why you're being downvoted. I don't know Haskell, but I had a look for the parser you mentioned and it does appear at first glance to use a fairly imperative-looking style, with loops and pointers into mutable data: https://github.com/ocramz/xeno/blob/master/src/Xeno/DOM.hs https://github.com/ocramz/xeno/blob/master/src/Xeno/DOM.hs I would be interested in an analysis of this code from anyone who actually does know Haskell in case I'm misreading it.
fiddlerwoaroof 8y ago
I believe OCaml isn’t as strict about side-effects as Haskell, so if you don’t want the side-effect ceremony Haskell sort of forces on you, OCaml might be a good choice. Also, OCaml is strict by default and had a fairly good compiler.
- badfrog 8y ago
  Is there any convention for denoting which functions in OCaml have side effects?
  - fiddlerwoaroof 8y ago
    I don't know, I don't write it very much.
  - yawaramin 8y ago
    Some people append `_exn` to names of functions which can raise exceptions; that's about it.
  - laylomo2 8y ago
    Not really, but the documentation will usually tell you. Also, at least in Jane Street’a libraries, exceptionful functions always end in _exn. So for example there is List.find and List.find_exn
  - craigsmansion 8y ago
    I don't think it's a strict convention, but it's common to see (a block of) imperative statements with side effects enclosed in: begin ... end It's ugly and stands out in its awkwardness, almost as if by design, with the compiler saying: "I will let you do this, but do think about it some more and try and come up with something more elegant."
- JadeNB 8y ago
  > I believe OCaml isn’t as strict about side-effects as Haskell, so if you don’t want the side-effect ceremony Haskell sort of forces on you, OCaml might be a good choice. Also, OCaml is strict by default and had a fairly good compiler. Probably anyone who's interested here knows, but it may be appropriate to point out that you are using the word 'strict' in two different senses, first in the informal sense of being restrictive, and second in the formal sense of strict evaluation (which is why it makes sense to say that OCaml is less strict, and yet strict by default).
  - 8y ago
truncate 8y ago
Considering neither is the language I use for work, but just as a hobby, I often forget how to write code in these languages after a while. The amount of time to get back on track to write idiomatic OCaml is almost instantaneous as opposed to Haskell. Disclaimer: I've written far more OCaml code than Haskell, so maybe my opinion may be biased.
- nv-vn 8y ago
  Yes, writing Haskell definitely takes a mental context switch. You kind of have to abandon the traditional style of programming in order to transition into it. Pretty similar to what writing Prolog feels like for example. In contrast, it seems like there's a more direct line between languages like OCaml/Lisps versus C/Java.
- withthewind 8y ago
  I like to liken it with muscle atrophy. Gotta get my weekly fix of Haskell to maintain it!
yawaramin 8y ago
Beauty: http://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/intro/ocaml.html#beauty http://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/int...
- wk_end 8y ago
  But Haskell is also beautiful, in much the same way ML is, and arguably other ways besides.
pbiggar 8y ago
I had hoped to use Haskell for my company, but found it much too complicated. OCaml skips a great deal of the complexity of Haskell, while still having the advantages of a static functional language. I find it exceptionally practical.
lelf 8y ago
Simplicity. Strict evaluation. Functors (first-class/higher-order modules), although Haskell is trying to get there with Backpack too. Good idea to learn both, anyway :-P Edit: compilation speed too, huge difference
thinkpad20 8y ago
I'm currently developing a web app with a Haskell backend and a ReasonML (OCaml with a different syntax) frontend. I'd been interested in ReasonML for a while and so far it's been a great experience, but overall I wouldn't say I prefer it to Haskell. I've been using Haskell for many years and so the simplicity advantage isn't there for me. I also miss strongly some of the major Haskell conveniences like generic programming, type class derivation, higher kinded types, and yes Monads. I'm not a huge fan of the OCaml record system as it frequently gets confused and requires type annotations. In fact I've generally found OCaml to be substantially worse at type inference than Haskell, requiring frequent type annotations and cluttering up the code. Haskell's learning curve is steeper, but it is simpler in some ways, especially once you're familiar. I think where ReasonML/OCaml wins hands-down is its compiler. Bucklescript (and I've heard similar things about other compilers, but can't vouch for it) is lightning quick, and the community has gone leaps and bounds to make it super easy to bootstrap (including with create-react-app). GHC can do amazing things but it's not the fastest out there, and the compiler for the JS backend is abysmally slow. The code Bucklescript produces is very high quality and performant. The library ecosystem is reasonably strong and I expect (but haven't done much testing) that because of the strictness and relative simplicity of the language, library code would tend to be pretty performant and easy to use. I've never found myself in OCaml wondering what string type I should use, or attempting to parse some absurdly complex type hierarchy in a library. I think for a frontend project, to most programmers I would recommend ReasonML. For one thing, I think even most without experience with FP would find ReasonML to be a giant improvement over Flow (which infuriates me as a type checker), and it doesn't take a ton of time to learn. ReasonReact is a pretty sweet library and I prefer it to React even setting aside language choice. Compared to Haskell, its strictness means it doesn't require a special runtime, generate slow/impenetrable code, or hog tons of resources -- all things that are issues in frontend Haskell. For those who really want to use Haskell on the frontend I'd recommend PureScript instead (also you get the bonus of a kickass record system). For backend, I think OCaml will get you up and running sooner, but in the long run you're going to find yourself missing the type system and language features Haskell has. GHC's speed on the backend is tolerable (especially if you use nix), and I think Haskell is competitive in performance to OCaml (perhaps better with optimization). Most importantly, I think Haskell is second to none when it comes to correct implementations of business types and logic, creating powerful and reliable abstractions, and eliminating boilerplate, and I think that forms a greater advantage in backend code. EDIT: this turned into quite the essay...
darksaints 8y ago
Ocaml has 100% less bikeshedding and no propensity for unending puritanical holy wars. It's a language for getting things done, as opposed to thinking about finding a way to do something that satisfies an obsessive compulsive desire to eliminate 100% of sides effects for no practical reason.
- 59nadir 8y ago
  Except we've been waiting how many years for actual multicore support and ad-hoc polymorphism (or anything approaching it)...? No, OCaml really isn't a language where things move forward; quite the opposite. Also, if you had actually written any Haskell code you'd know it's not about eliminating any side effects, it's about denoting them in the type system. Your comment reeks of someone who hasn't actually used either of these languages.
ernst_klim 8y ago
Modules and parametric modules, subtyping (polymorphic variants [1] and objects), proper records, classes making bindings to OOP APIs natural, strict evaluation, ppx extensions [2]. [1] http://keleshev.com/composable-error-handling-in-ocaml http://keleshev.com/composable-error-handling-in-ocaml [2] https://victor.darvariu.me/jekyll/update/2018/06/19/ppx-tutorial.html https://victor.darvariu.me/jekyll/update/2018/06/19/ppx-tuto...
ms013 8y ago
Ocaml is a bit easier to reason about w.r.t. performance (time/space complexity), and the code is a bit clearer if you're coming in cold after not having seen parts of a codebase for a while. Spent ~10 years at a Haskell shop, and currently at an Ocaml one, and was a Standard ML hacker prior to the Haskell job. Done some F# in there too, although for the most part that just feels like ocaml w/ some cleaned up syntax and a nice interop with the rest of the .net ecosystem. From a nontechnical perspective, some changes in the Haskell community and ecosystem also turned me off on it starting around 2011, and I find the ocaml one to be a bit more up my alley.
yaantc 8y ago
Although it's very brief, they touch this topic in the intro: "OCaml does a great job of clarifying and simplifying the essence of functional programming in a way that other languages that blend functional and imperative programming (like Scala) or take functional programming to the extreme (like Haskell) do not. Having learned OCaml, you'll be well equipped to teach yourself any other functional(-inspired) language." This course is for teaching students who know how to program but are new to functional paradigm. The way I understand the above is that OCaml is impure, so it's easier to have some parts in imperative style to get unstuck and move forward at first. That may reduce frustration for some students. Then over time, as the functional approach sinks in, you move to a purer style (with sometimes imperative parts, but well encapsulated). Haskell would be more like "let's jump at the deep end of the functional pool" --- which can work for some too.
agumonkey 8y ago
strictness by default, and a slightly more pragmatic way of life. Haskell quickly goes into categorical like composition (Traversable . Lens . Foldable). I think for the average population this is too quick. Ocaml feels like solid battle tested fast typescript (pardon the caricature :).

What reasons are there for choosing OCaml over Haskell, either from a learning perspective or a practical one?

by jonahx 8y ago

What reasons are there for choosing OCaml over Haskell, either from a learning perspective or a practical one?

OCaml is more of a multi-paradigm language than Haskell. It's not purely functional, so you can easily fallback into imperative code if you need (you can use mutable variables, I/O, mutable arrays, hashmaps, for loops, while loops, etc.). It's also object-oriented (though this feature is not widely used) and has a very powerful module system that few other languages can compare to. What I like about it from a learning perspective is that it makes a transition into functional programming much simpler than it would be with Haskell, where you have to completely change the way you program from the very beginning.

moocowtruck 8y ago
haskell is great at being imperative too look at chris done's work on xml parsing haskell and c; nice example
- robert_tweed 8y ago
  I'm not sure why you're being downvoted. I don't know Haskell, but I had a look for the parser you mentioned and it does appear at first glance to use a fairly imperative-looking style, with loops and pointers into mutable data: https://github.com/ocramz/xeno/blob/master/src/Xeno/DOM.hs https://github.com/ocramz/xeno/blob/master/src/Xeno/DOM.hs I would be interested in an analysis of this code from anyone who actually does know Haskell in case I'm misreading it.

fiddlerwoaroof 8y ago

I believe OCaml isn’t as strict about side-effects as Haskell, so if you don’t want the side-effect ceremony Haskell sort of forces on you, OCaml might be a good choice. Also, OCaml is strict by default and had a fairly good compiler.

badfrog 8y ago
Is there any convention for denoting which functions in OCaml have side effects?
- fiddlerwoaroof 8y ago
  I don't know, I don't write it very much.
- yawaramin 8y ago
  Some people append `_exn` to names of functions which can raise exceptions; that's about it.
- laylomo2 8y ago
  Not really, but the documentation will usually tell you. Also, at least in Jane Street’a libraries, exceptionful functions always end in _exn. So for example there is List.find and List.find_exn
- craigsmansion 8y ago
  I don't think it's a strict convention, but it's common to see (a block of) imperative statements with side effects enclosed in: begin ... end It's ugly and stands out in its awkwardness, almost as if by design, with the compiler saying: "I will let you do this, but do think about it some more and try and come up with something more elegant."
JadeNB 8y ago
> I believe OCaml isn’t as strict about side-effects as Haskell, so if you don’t want the side-effect ceremony Haskell sort of forces on you, OCaml might be a good choice. Also, OCaml is strict by default and had a fairly good compiler. Probably anyone who's interested here knows, but it may be appropriate to point out that you are using the word 'strict' in two different senses, first in the informal sense of being restrictive, and second in the formal sense of strict evaluation (which is why it makes sense to say that OCaml is less strict, and yet strict by default).
- 8y ago

truncate 8y ago

Considering neither is the language I use for work, but just as a hobby, I often forget how to write code in these languages after a while. The amount of time to get back on track to write idiomatic OCaml is almost instantaneous as opposed to Haskell. Disclaimer: I've written far more OCaml code than Haskell, so maybe my opinion may be biased.

nv-vn 8y ago
Yes, writing Haskell definitely takes a mental context switch. You kind of have to abandon the traditional style of programming in order to transition into it. Pretty similar to what writing Prolog feels like for example. In contrast, it seems like there's a more direct line between languages like OCaml/Lisps versus C/Java.
withthewind 8y ago
I like to liken it with muscle atrophy. Gotta get my weekly fix of Haskell to maintain it!

yawaramin 8y ago

Beauty: http://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/intro/ocaml.html#beauty http://www.cs.cornell.edu/courses/cs3110/2019sp/textbook/int...

wk_end 8y ago
But Haskell is also beautiful, in much the same way ML is, and arguably other ways besides.

pbiggar 8y ago

I had hoped to use Haskell for my company, but found it much too complicated. OCaml skips a great deal of the complexity of Haskell, while still having the advantages of a static functional language. I find it exceptionally practical.

lelf 8y ago

Simplicity. Strict evaluation. Functors (first-class/higher-order modules), although Haskell is trying to get there with Backpack too. Good idea to learn both, anyway :-P Edit: compilation speed too, huge difference

thinkpad20 8y ago

I'm currently developing a web app with a Haskell backend and a ReasonML (OCaml with a different syntax) frontend. I'd been interested in ReasonML for a while and so far it's been a great experience, but overall I wouldn't say I prefer it to Haskell. I've been using Haskell for many years and so the simplicity advantage isn't there for me. I also miss strongly some of the major Haskell conveniences like generic programming, type class derivation, higher kinded types, and yes Monads. I'm not a huge fan of the OCaml record system as it frequently gets confused and requires type annotations. In fact I've generally found OCaml to be substantially worse at type inference than Haskell, requiring frequent type annotations and cluttering up the code. Haskell's learning curve is steeper, but it is simpler in some ways, especially once you're familiar. I think where ReasonML/OCaml wins hands-down is its compiler. Bucklescript (and I've heard similar things about other compilers, but can't vouch for it) is lightning quick, and the community has gone leaps and bounds to make it super easy to bootstrap (including with create-react-app). GHC can do amazing things but it's not the fastest out there, and the compiler for the JS backend is abysmally slow. The code Bucklescript produces is very high quality and performant. The library ecosystem is reasonably strong and I expect (but haven't done much testing) that because of the strictness and relative simplicity of the language, library code would tend to be pretty performant and easy to use. I've never found myself in OCaml wondering what string type I should use, or attempting to parse some absurdly complex type hierarchy in a library. I think for a frontend project, to most programmers I would recommend ReasonML. For one thing, I think even most without experience with FP would find ReasonML to be a giant improvement over Flow (which infuriates me as a type checker), and it doesn't take a ton of time to learn. ReasonReact is a pretty sweet library and I prefer it to React even setting aside language choice. Compared to Haskell, its strictness means it doesn't require a special runtime, generate slow/impenetrable code, or hog tons of resources -- all things that are issues in frontend Haskell. For those who really want to use Haskell on the frontend I'd recommend PureScript instead (also you get the bonus of a kickass record system). For backend, I think OCaml will get you up and running sooner, but in the long run you're going to find yourself missing the type system and language features Haskell has. GHC's speed on the backend is tolerable (especially if you use nix), and I think Haskell is competitive in performance to OCaml (perhaps better with optimization). Most importantly, I think Haskell is second to none when it comes to correct implementations of business types and logic, creating powerful and reliable abstractions, and eliminating boilerplate, and I think that forms a greater advantage in backend code. EDIT: this turned into quite the essay...

darksaints 8y ago

Ocaml has 100% less bikeshedding and no propensity for unending puritanical holy wars. It's a language for getting things done, as opposed to thinking about finding a way to do something that satisfies an obsessive compulsive desire to eliminate 100% of sides effects for no practical reason.

59nadir 8y ago
Except we've been waiting how many years for actual multicore support and ad-hoc polymorphism (or anything approaching it)...? No, OCaml really isn't a language where things move forward; quite the opposite. Also, if you had actually written any Haskell code you'd know it's not about eliminating any side effects, it's about denoting them in the type system. Your comment reeks of someone who hasn't actually used either of these languages.

ernst_klim 8y ago

Modules and parametric modules, subtyping (polymorphic variants [1] and objects), proper records, classes making bindings to OOP APIs natural, strict evaluation, ppx extensions [2]. [1] http://keleshev.com/composable-error-handling-in-ocaml http://keleshev.com/composable-error-handling-in-ocaml [2] https://victor.darvariu.me/jekyll/update/2018/06/19/ppx-tutorial.html https://victor.darvariu.me/jekyll/update/2018/06/19/ppx-tuto...

ms013 8y ago

Ocaml is a bit easier to reason about w.r.t. performance (time/space complexity), and the code is a bit clearer if you're coming in cold after not having seen parts of a codebase for a while. Spent ~10 years at a Haskell shop, and currently at an Ocaml one, and was a Standard ML hacker prior to the Haskell job. Done some F# in there too, although for the most part that just feels like ocaml w/ some cleaned up syntax and a nice interop with the rest of the .net ecosystem. From a nontechnical perspective, some changes in the Haskell community and ecosystem also turned me off on it starting around 2011, and I find the ocaml one to be a bit more up my alley.

yaantc 8y ago

Although it's very brief, they touch this topic in the intro: "OCaml does a great job of clarifying and simplifying the essence of functional programming in a way that other languages that blend functional and imperative programming (like Scala) or take functional programming to the extreme (like Haskell) do not. Having learned OCaml, you'll be well equipped to teach yourself any other functional(-inspired) language." This course is for teaching students who know how to program but are new to functional paradigm. The way I understand the above is that OCaml is impure, so it's easier to have some parts in imperative style to get unstuck and move forward at first. That may reduce frustration for some students. Then over time, as the functional approach sinks in, you move to a purer style (with sometimes imperative parts, but well encapsulated). Haskell would be more like "let's jump at the deep end of the functional pool" --- which can work for some too.

agumonkey 8y ago

strictness by default, and a slightly more pragmatic way of life. Haskell quickly goes into categorical like composition (Traversable . Lens . Foldable). I think for the average population this is too quick. Ocaml feels like solid battle tested fast typescript (pardon the caricature :).