7 ms·

If I were already sold on using Haskell or OCaml for a new project, what would be the big seller for OCaml being the choice? I haven't dug into SML or OCaml and

If I were already sold on using Haskell or OCaml for a new project, what would be the big seller for OCaml being the choice? I haven't dug into SML or OCaml and I'm not expert with Haskell yet but from looking at them they don't look substantially distant from Haskell.

semisight 11y ago
Can't speak for OCaml yet; I've wanted to learn for a while but decided to go with Haskell first. On the Haskell side of things--it's biggest seller (functional purity) is also the biggest downside. To give you an idea, papers have been written about the best way to implement common data structures purely functionally. From what I've seen, OCaml has less "abstraction overhead" because it can dip into imperative code. While Haskell is really fun, it definitely has moments where you want to beat your head against your desk.
- catnaroek 11y ago
  The real downside isn't purity - purity is a good thing! What Haskell suffers from is a lack of flexibility w.r.t. the evaluation strategy of pure functions. More precisely: (0) Haskell starts with a bad default - laziness. (1) Haskell uses special annotations to introduce strictness. The presence of these annotations isn't tracked by the type system, which reduces the usefulness of the type system as a tool for understanding your program. (2) More sophisticated evaluation strategies (e.g., memoizing functions, which can be seen as a generalization of laziness) are difficult to achieve in Haskell, even though it's completely straightforward in ML.
seagreen 11y ago
I've only written Haskell, but I'll try to give a fair shakedown from my perspective: + OCaml is eagerly evaluated while Haskell is lazily evaluated. This makes it easier to reason about things like memory use in OCaml. + IO is reflected in the type signature of Haskell functions. You may find this annoying because it stinks to have to change a lot of type signatures just because, e.g., you want one of your utility functions to make a log entry when called. On the other hand, IO is often a huge deal either semantically or from a performance perspective. For big projects having IO reflected in the type system can be a huge help. + The ecosystems are different. Haskell's is bigger, though I've heard the quality of OCaml libraries tends to be very high.
- mercurial 11y ago
  > IO is reflected in the type signature of Haskell functions. What you mean is, "effects are reflected". Haskell has a monadic effect system (IO is very rough-grained part of it), which can be combined via monadic transformers. Situations where you don't want to use OCaml: - you need good parallelism and using multiple processes are not enough (concurrency is fine, though) - you want a large pool of developers (also applies to Haskell, but less so) - you like monadic effect systems - you need a number of libraries which are not present in the OCaml ecosystem - you want a build system that doesn't suck - you want a good standard library - you want typeclasses Why you'd want to use OCaml over Haskell: - fast compilation (especially if you compile to bytecode) - no monadic effect system - no awful, ridiculous record field name collisions (OCaml lets you have two distinct types with an "id" field, imagine that) - best-in-class package manager - faster than Haskell (I think?) - eagerly evaluated (Haskell's informal motto is "if it compiles it works", complemented by "until you get a memory leak") and therefore makes it much easier to reason about performance - high-quality ecosystem (though not always very well documented) - labeled arguments (many Haskell libraries have these functions with lots of arguments which are quite confusing in the absence of labeled arguments) - great support for Vim/Emacs (IMHO, the Haskell equivalent to Merlin/ocp-indent are not nearly as good, or at least were not as a few years ago) - great REPL via utop (just don't use the standard one, it's terrible) - an object system if you really need one - functors - pleasant "printf debugging" option, with a possibility of using a real debugger if you need
  - fsloth 11y ago
    "- you want a build system that doesn't suck" This is a very surprising claim. Do you have any examples how Ocaml specifically induces systems built on it to suck?
    - samwgoldman 11y ago
      I don't think that's what was meant, but rather that ocamlbuild sucks. It's not the best.
wyager 11y ago
OCaml is a bit more traditional. Strict evaluation and mutability may be more friendly to programmers with an imperative background. My general experience with OCaml hasn't been great. To be blunt, it seems sort of like a less-well-thought-out version of Haskell. The biggest downsides that I remember were: * IO sequencing via (;) : () -> () -> (). This is sort of a relic from before we had monads, and is relatively pretty clumsy. * No type classes. "Generic" operators like (<) work by binary comparison (!!!). This is terrible and leads to nonsensical ordering semantics for non-trivial data. There's also no generic (+), (), etc. There are separate functions for ints and floats. Again, clumsy. Questionable unboxing techniques. On a 64 bit processor, ints are 63 bits because ocaml has to use a bit to tag them as non-pointers. On the other hand, Haskell differentiates boxed/unboxed values statically at the kind level, so there are no weird pointer tagging tricks or related overhead. I have limited experience with OCaml, so take this with a grain of salt. I also think OCaml has valid use cases. In Jane street's case, I can see OCaml being a better choice than Haskell for the reasons I mentioned. The people there definitely know the advantages and disadvantages of both. One of the hardest interview questions of my life was a very interesting Haskell question from Jane Street!
- catnaroek 11y ago
  Speaking as someone who went from Haskell to ML, I don't see the loss of type classes as a terribly big deal. The implicitness of type classes is useful “in the small”, but the global benefits of a real module system in terms of type abstraction and separation of concerns outweigh the local benefits of the occasional shorter definition using type classes. In addition, ML modules have structural signatures, which makes it easier to retrofit existing modules to new hierarchies. For comparison, try making Haskell's existing Monoid class a subclass of Semigroup, without recompiling any code. :-p
truncate 11y ago
Its easy to write imperative code in OCaml. OCaml also has a class system. These two points make transition from languages such as Python, Java... easier.
- catnaroek 11y ago
  On the contrary, I think OCaml's class system is potentially very confusing to someone coming from mainstream object-oriented languages. Java programmers would be confused the most, because they would have to unlearn the most. In Java, a class is a type on its own right. An object of class (and, hence, type) `Foo` has a very specific data structure, even if this data structure is unknown to the user. On the other hand, in OCaml, a class is just a constructor for objects of a particular structural type. Two objects with the same structural type can have completely different underlying data structures. Making things even more confusing, inheritance doesn't entail subtyping - a class `foo` can inherit from a class `bar`, without `foo`'s type being a subtype of `bar`'s type. This happens if `bar`'s type contains negative occurences of its self-type. As a result, few intuitions about Java's class system carry over to OCaml. Python programmers would be somewhat less surprised, but if their idea of a typed object-oriented language is “something that looks like Java”, they could encounter all the difficulties mentioned in the preceding paragraph. On the other hand, if they have no experience at all with typed languages, OCaml's class system can still be a source of pain, in that inferred object types can be utterly incomprehensible for someone not familiar with how the type checker works. By contrast, the inferred type signatures for the non-object-oriented subset of OCaml are usually very tame. --- Sorry, e_d_g_a_r, I can't reply to you directly, because the website says I'm “submitting too fast”, but here is an example: http://pastebin.com/yUmNnFD5 http://pastebin.com/yUmNnFD5 . By the way, this isn't a bug in OCaml's type checker - it's the way it's supposed to work.
  - e_d_g_a_r 11y ago
    Can you provide an example of " This happens if `bar`'s type contains negative occurences of its self-type"
    - 11y ago
technomancy 11y ago
You can learn OCaml in a couple weeks.
- woodcut 11y ago
  Provided you had prior experience with functional languages then yes.
  - nv-vn 11y ago
    Not even, it was my first functional language (other than about an hour I had spent playing with F# a few months before) and I managed to be proficient enough to read real-world code and able to write my own code in it. Overall, OCaml doesn't have any very difficult concepts that stop you from using it. Can't get currying? Just pass args explicitly, even use tuples for them. Don't get monads? Ignore Lwt/Async. Don't know about functors? Just don't write module-heavy code, etc. Overtime you can sort of start to grasp the other features, but it's not a language that takes months just to be able to use.
baldfat 11y ago
I would strongly recommend looking at Racket and/or Closure. I tried the Haskell world and what a hassle to get it working on more then one machine the same way. The package management in Haskell is still more painful then other systems and is overly taxing. I work at two locations both using the same exact Dell machine with OpenSUSE and both gave problems. I also tried it on two windows machines and ugh. OCamal also suffers from portability issues but haven't tried that hard. I love the idea of OCamal but the practical/pragmatic side of me gets rubbed the wrong way. Personally Racket has a ton to offer and has been growing its user base a lot recently. I love this language and you can amke it whatever you want to do. Racket is a progamming language for programming languages. Clojure gives you a more pragmatic functional language and running on the jvm with a very large community.
- oldmanmike 11y ago
  Have you tried Stack yet?
- BWStearns 11y ago
  I'm messing with Clojure now and really enjoying it. Haskell was fun but hassle is definitely the right word for pretty much everything other than writing individual functions in it. Package management was really the thing that drove me to say "this is really cool, I'm going to come back when it's more friendly or I have more time."

semisight 11y ago

Can't speak for OCaml yet; I've wanted to learn for a while but decided to go with Haskell first. On the Haskell side of things--it's biggest seller (functional purity) is also the biggest downside. To give you an idea, papers have been written about the best way to implement common data structures purely functionally. From what I've seen, OCaml has less "abstraction overhead" because it can dip into imperative code. While Haskell is really fun, it definitely has moments where you want to beat your head against your desk.

catnaroek 11y ago
The real downside isn't purity - purity is a good thing! What Haskell suffers from is a lack of flexibility w.r.t. the evaluation strategy of pure functions. More precisely: (0) Haskell starts with a bad default - laziness. (1) Haskell uses special annotations to introduce strictness. The presence of these annotations isn't tracked by the type system, which reduces the usefulness of the type system as a tool for understanding your program. (2) More sophisticated evaluation strategies (e.g., memoizing functions, which can be seen as a generalization of laziness) are difficult to achieve in Haskell, even though it's completely straightforward in ML.

seagreen 11y ago

I've only written Haskell, but I'll try to give a fair shakedown from my perspective: + OCaml is eagerly evaluated while Haskell is lazily evaluated. This makes it easier to reason about things like memory use in OCaml. + IO is reflected in the type signature of Haskell functions. You may find this annoying because it stinks to have to change a lot of type signatures just because, e.g., you want one of your utility functions to make a log entry when called. On the other hand, IO is often a huge deal either semantically or from a performance perspective. For big projects having IO reflected in the type system can be a huge help. + The ecosystems are different. Haskell's is bigger, though I've heard the quality of OCaml libraries tends to be very high.

mercurial 11y ago
> IO is reflected in the type signature of Haskell functions. What you mean is, "effects are reflected". Haskell has a monadic effect system (IO is very rough-grained part of it), which can be combined via monadic transformers. Situations where you don't want to use OCaml: - you need good parallelism and using multiple processes are not enough (concurrency is fine, though) - you want a large pool of developers (also applies to Haskell, but less so) - you like monadic effect systems - you need a number of libraries which are not present in the OCaml ecosystem - you want a build system that doesn't suck - you want a good standard library - you want typeclasses Why you'd want to use OCaml over Haskell: - fast compilation (especially if you compile to bytecode) - no monadic effect system - no awful, ridiculous record field name collisions (OCaml lets you have two distinct types with an "id" field, imagine that) - best-in-class package manager - faster than Haskell (I think?) - eagerly evaluated (Haskell's informal motto is "if it compiles it works", complemented by "until you get a memory leak") and therefore makes it much easier to reason about performance - high-quality ecosystem (though not always very well documented) - labeled arguments (many Haskell libraries have these functions with lots of arguments which are quite confusing in the absence of labeled arguments) - great support for Vim/Emacs (IMHO, the Haskell equivalent to Merlin/ocp-indent are not nearly as good, or at least were not as a few years ago) - great REPL via utop (just don't use the standard one, it's terrible) - an object system if you really need one - functors - pleasant "printf debugging" option, with a possibility of using a real debugger if you need
- fsloth 11y ago
  "- you want a build system that doesn't suck" This is a very surprising claim. Do you have any examples how Ocaml specifically induces systems built on it to suck?
  - samwgoldman 11y ago
    I don't think that's what was meant, but rather that ocamlbuild sucks. It's not the best.

wyager 11y ago

OCaml is a bit more traditional. Strict evaluation and mutability may be more friendly to programmers with an imperative background. My general experience with OCaml hasn't been great. To be blunt, it seems sort of like a less-well-thought-out version of Haskell. The biggest downsides that I remember were: * IO sequencing via (;) : () -> () -> (). This is sort of a relic from before we had monads, and is relatively pretty clumsy. * No type classes. "Generic" operators like (<) work by binary comparison (!!!). This is terrible and leads to nonsensical ordering semantics for non-trivial data. There's also no generic (+), (), etc. There are separate functions for ints and floats. Again, clumsy. Questionable unboxing techniques. On a 64 bit processor, ints are 63 bits because ocaml has to use a bit to tag them as non-pointers. On the other hand, Haskell differentiates boxed/unboxed values statically at the kind level, so there are no weird pointer tagging tricks or related overhead. I have limited experience with OCaml, so take this with a grain of salt. I also think OCaml has valid use cases. In Jane street's case, I can see OCaml being a better choice than Haskell for the reasons I mentioned. The people there definitely know the advantages and disadvantages of both. One of the hardest interview questions of my life was a very interesting Haskell question from Jane Street!

catnaroek 11y ago
Speaking as someone who went from Haskell to ML, I don't see the loss of type classes as a terribly big deal. The implicitness of type classes is useful “in the small”, but the global benefits of a real module system in terms of type abstraction and separation of concerns outweigh the local benefits of the occasional shorter definition using type classes. In addition, ML modules have structural signatures, which makes it easier to retrofit existing modules to new hierarchies. For comparison, try making Haskell's existing Monoid class a subclass of Semigroup, without recompiling any code. :-p

truncate 11y ago

Its easy to write imperative code in OCaml. OCaml also has a class system. These two points make transition from languages such as Python, Java... easier.

catnaroek 11y ago
On the contrary, I think OCaml's class system is potentially very confusing to someone coming from mainstream object-oriented languages. Java programmers would be confused the most, because they would have to unlearn the most. In Java, a class is a type on its own right. An object of class (and, hence, type) `Foo` has a very specific data structure, even if this data structure is unknown to the user. On the other hand, in OCaml, a class is just a constructor for objects of a particular structural type. Two objects with the same structural type can have completely different underlying data structures. Making things even more confusing, inheritance doesn't entail subtyping - a class `foo` can inherit from a class `bar`, without `foo`'s type being a subtype of `bar`'s type. This happens if `bar`'s type contains negative occurences of its self-type. As a result, few intuitions about Java's class system carry over to OCaml. Python programmers would be somewhat less surprised, but if their idea of a typed object-oriented language is “something that looks like Java”, they could encounter all the difficulties mentioned in the preceding paragraph. On the other hand, if they have no experience at all with typed languages, OCaml's class system can still be a source of pain, in that inferred object types can be utterly incomprehensible for someone not familiar with how the type checker works. By contrast, the inferred type signatures for the non-object-oriented subset of OCaml are usually very tame. --- Sorry, e_d_g_a_r, I can't reply to you directly, because the website says I'm “submitting too fast”, but here is an example: http://pastebin.com/yUmNnFD5 http://pastebin.com/yUmNnFD5 . By the way, this isn't a bug in OCaml's type checker - it's the way it's supposed to work.
- e_d_g_a_r 11y ago
  Can you provide an example of " This happens if `bar`'s type contains negative occurences of its self-type"
  - 11y ago

technomancy 11y ago

You can learn OCaml in a couple weeks.

woodcut 11y ago
Provided you had prior experience with functional languages then yes.
- nv-vn 11y ago
  Not even, it was my first functional language (other than about an hour I had spent playing with F# a few months before) and I managed to be proficient enough to read real-world code and able to write my own code in it. Overall, OCaml doesn't have any very difficult concepts that stop you from using it. Can't get currying? Just pass args explicitly, even use tuples for them. Don't get monads? Ignore Lwt/Async. Don't know about functors? Just don't write module-heavy code, etc. Overtime you can sort of start to grasp the other features, but it's not a language that takes months just to be able to use.

baldfat 11y ago

I would strongly recommend looking at Racket and/or Closure. I tried the Haskell world and what a hassle to get it working on more then one machine the same way. The package management in Haskell is still more painful then other systems and is overly taxing. I work at two locations both using the same exact Dell machine with OpenSUSE and both gave problems. I also tried it on two windows machines and ugh. OCamal also suffers from portability issues but haven't tried that hard. I love the idea of OCamal but the practical/pragmatic side of me gets rubbed the wrong way. Personally Racket has a ton to offer and has been growing its user base a lot recently. I love this language and you can amke it whatever you want to do. Racket is a progamming language for programming languages. Clojure gives you a more pragmatic functional language and running on the jvm with a very large community.

oldmanmike 11y ago
Have you tried Stack yet?
BWStearns 11y ago
I'm messing with Clojure now and really enjoying it. Haskell was fun but hassle is definitely the right word for pretty much everything other than writing individual functions in it. Package management was really the thing that drove me to say "this is really cool, I'm going to come back when it's more friendly or I have more time."