6 ms·

As always, it depends on the job. For some systems, OCaml is superior; for others, Haskell is superior. One big question informing the choice is "do I want to

As always, it depends on the job. For some systems, OCaml is superior; for others, Haskell is superior. One big question informing the choice is "do I want to program primarily lazily or primarily eagerly?" Another is "is time to achieve system performance a big factor in success?" If eager, performance-eager -> Ocaml If lazy, performance-lazy -> Haskell

nousernamesleft 13y ago
Having spent 6 years with ocaml, I can honestly say I both never wrote anything where ocaml offered a benefit haskell does not, and can not even think of such a program. You pose two questions, one of which is effectively irrelevant, and the other I believe is based on an incorrect assumption. Maybe 5% of code the evaluation strategy matters. It makes no difference whether you are adding strictness for 2% of your code or adding laziness for 2% of your code. The performance question I think is a misconception. Do you have any evidence to suggest it is easier to write fast code in ocaml? I've never found a person who has used both languages and felt that was the case. I've only found people without haskell experience believing that via second (or third, or fiftieth) hand rumors. Ocaml offers two things over haskell. One, imperative constructs. This matters for people making a transition to functional programming, but not for people who've finished that transition. Second, the compiler is fast. I don't mean generates fast code, ghc does that too. I mean it generates code quickly. This is an annoyance with ghc, no question. Haskell offers a lot over ocaml. A useful standard library. Cabal and hackage. Parallelism done right, out of the box (super cheap green threads multiplexed over a pool of OS threads). Tons of libraries that don't exist in ocaml, everywhere from attoparsec and aeson, to binary and lenses, pipes-concurrency and STM. A community that is ten times the size of ocaml's. There are good reasons it has gone from ocaml having the larger community to haskell dwarfing ocaml in community size, language usage, library availability, etc. in the last decade.
- deleted 13y ago
  [deleted]
- anaphor 13y ago
  OCaml has camlp4 which is vastly superior to TH for extending the language's syntax.
- danieldk 13y ago
  Do you have any evidence to suggest it is easier to write fast code in ocaml? I find it much easier. To give one example: I recently had to write some code that shuffles arrays based on a PRNG. In OCaml, one can simply use a mutable array and a PRNG that uses a mutable variable. In Haskell, efficient array mutation is possible, but you have to do it in the ST or IO monad. So, in a pure function you'll want to runST an expression in the ST monad. But then you need to thread the 'state' of the random number generator in function calls, or use a State-like monad. If you use a state monad, you have two monads and will probably use a monad transformer. Writing the equivalent Haskell code is much more work. But on the other side, Haskell keeps you more honest. The end result is that in Haskell, it is guaranteed that the end-result is pure (if you don't use unsafePerformIO of course). In OCaml it's only by convention. Which is better depends on what you want, convenience or safety. Personally, if I have to choose between OCaml or Haskell, I'll choose the latter. There are already plenty of languages that are pragmatic and less strongly typed. For me, OCaml provides relatively only advantages over strongly-typed imperative languages that support closures, etc. Haskell on the other hand, provides an amount of type-safety that those languages do not provide, while still being usable (both as a language and in terms of the library ecosystem).
  - nousernamesleft 13y ago
    >I find it much easier Ok, but your anecodes + my anecdotes = still just anecdotes. To support the claim that it is easier to write fast code in ocaml, we need to find evidence. >Writing the equivalent Haskell code is much more work I have not experienced anything like that, despite having much more experience with ocaml than with haskell. You are imposing limitations on yourself when using haskell and then saying haskell is imposing them. Every ocaml function is in IO, it just doesn't provide type information to tell you that. So doing the same thing in haskell is doing it in IO, which requires no special effort at all. Even if you choose to add a purity restriction on yourself, adding "runST $" does not seem like a lot of work to me.
- talex5 13y ago
  "Do you have any evidence to suggest it is easier to write fast code in ocaml? I've never found a person who has used both languages and felt that was the case. I've only found people without haskell experience believing that via second (or third, or fiftieth) hand rumors." The first post in this blog series had a simple test (really just testing start-up time), where Haskell and OCaml were very similar. But in the second post (http://roscidus.com/blog/blog/2013/06/20/replacing-python-round-2/#speed http://roscidus.com/blog/blog/2013/06/20/replacing-python-ro...) with a slightly longer test-case, OCaml was twice as fast as Haskell.
  - nousernamesleft 13y ago
    But both were fast. And if he had enabled optimizations like it was suggested, the difference would be smaller. And if he had used attoparsec instead of a regex it would have been easier, less error prone, and faster. He literally didn't learn haskell and copy and pasted random stuff from stackoverflow and irc.
    - lpw25 13y ago
      > He literally didn't learn haskell and copy and pasted random stuff from stackoverflow and irc But that's the point right. He did the same for OCaml and got faster code. Obviously you can write fast code in Haskell, but that is not the same as it being easy.
      - nousernamesleft 13y ago
        >He did the same for OCaml and got faster code No he didn't. He took the time to learn ocaml. >Obviously you can write fast code in Haskell, but that is not the same as it being easy. The closest thing to evidence I can find suggests that it is no more difficult to write fast code in haskell: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=ghc&lang2=ocaml&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
        lpw25 13y ago
- renox 13y ago
  I thought that lenses where only needed due to deficiencies/limitation in Haskell? (A kind of workaround).
  - nousernamesleft 13y ago
    Nope. Lenses aren't needed at all, they are just helpful. Lenses are just combined getter+setter that are composable. So you can use (lensA . lensB . lensC) to view, update or replace part of a data structure that is part of a data structure that is part of a data structure.
    - renox 13y ago
      Sure but how is that an advantageof Haskell? It seems possible to do the same in any language C++, Java..: a wrapper class which provide an access to a part of another class.
      - codygman 13y ago
        I'm no expert, but I believe it's an advantage of Haskell because of the generality and level of abstraction you are capable of while maintaining type safety. I also think I just described Haskell.
      - nousernamesleft 13y ago
        Because haskell has such a library (a few actually) and ocaml does not. So in ocaml you either have to give up safety, or write a bunch of verbose boilerplate. There's no reason someone couldn't write a lens library for ocaml of course, but the much smaller community makes for far fewer libraries.

nousernamesleft 13y ago

Having spent 6 years with ocaml, I can honestly say I both never wrote anything where ocaml offered a benefit haskell does not, and can not even think of such a program. You pose two questions, one of which is effectively irrelevant, and the other I believe is based on an incorrect assumption. Maybe 5% of code the evaluation strategy matters. It makes no difference whether you are adding strictness for 2% of your code or adding laziness for 2% of your code. The performance question I think is a misconception. Do you have any evidence to suggest it is easier to write fast code in ocaml? I've never found a person who has used both languages and felt that was the case. I've only found people without haskell experience believing that via second (or third, or fiftieth) hand rumors. Ocaml offers two things over haskell. One, imperative constructs. This matters for people making a transition to functional programming, but not for people who've finished that transition. Second, the compiler is fast. I don't mean generates fast code, ghc does that too. I mean it generates code quickly. This is an annoyance with ghc, no question. Haskell offers a lot over ocaml. A useful standard library. Cabal and hackage. Parallelism done right, out of the box (super cheap green threads multiplexed over a pool of OS threads). Tons of libraries that don't exist in ocaml, everywhere from attoparsec and aeson, to binary and lenses, pipes-concurrency and STM. A community that is ten times the size of ocaml's. There are good reasons it has gone from ocaml having the larger community to haskell dwarfing ocaml in community size, language usage, library availability, etc. in the last decade.

deleted 13y ago
[deleted]
anaphor 13y ago
OCaml has camlp4 which is vastly superior to TH for extending the language's syntax.
danieldk 13y ago
Do you have any evidence to suggest it is easier to write fast code in ocaml? I find it much easier. To give one example: I recently had to write some code that shuffles arrays based on a PRNG. In OCaml, one can simply use a mutable array and a PRNG that uses a mutable variable. In Haskell, efficient array mutation is possible, but you have to do it in the ST or IO monad. So, in a pure function you'll want to runST an expression in the ST monad. But then you need to thread the 'state' of the random number generator in function calls, or use a State-like monad. If you use a state monad, you have two monads and will probably use a monad transformer. Writing the equivalent Haskell code is much more work. But on the other side, Haskell keeps you more honest. The end result is that in Haskell, it is guaranteed that the end-result is pure (if you don't use unsafePerformIO of course). In OCaml it's only by convention. Which is better depends on what you want, convenience or safety. Personally, if I have to choose between OCaml or Haskell, I'll choose the latter. There are already plenty of languages that are pragmatic and less strongly typed. For me, OCaml provides relatively only advantages over strongly-typed imperative languages that support closures, etc. Haskell on the other hand, provides an amount of type-safety that those languages do not provide, while still being usable (both as a language and in terms of the library ecosystem).
- nousernamesleft 13y ago
  >I find it much easier Ok, but your anecodes + my anecdotes = still just anecdotes. To support the claim that it is easier to write fast code in ocaml, we need to find evidence. >Writing the equivalent Haskell code is much more work I have not experienced anything like that, despite having much more experience with ocaml than with haskell. You are imposing limitations on yourself when using haskell and then saying haskell is imposing them. Every ocaml function is in IO, it just doesn't provide type information to tell you that. So doing the same thing in haskell is doing it in IO, which requires no special effort at all. Even if you choose to add a purity restriction on yourself, adding "runST $" does not seem like a lot of work to me.
talex5 13y ago
"Do you have any evidence to suggest it is easier to write fast code in ocaml? I've never found a person who has used both languages and felt that was the case. I've only found people without haskell experience believing that via second (or third, or fiftieth) hand rumors." The first post in this blog series had a simple test (really just testing start-up time), where Haskell and OCaml were very similar. But in the second post (http://roscidus.com/blog/blog/2013/06/20/replacing-python-round-2/#speed http://roscidus.com/blog/blog/2013/06/20/replacing-python-ro...) with a slightly longer test-case, OCaml was twice as fast as Haskell.
- nousernamesleft 13y ago
  But both were fast. And if he had enabled optimizations like it was suggested, the difference would be smaller. And if he had used attoparsec instead of a regex it would have been easier, less error prone, and faster. He literally didn't learn haskell and copy and pasted random stuff from stackoverflow and irc.
  - lpw25 13y ago
    > He literally didn't learn haskell and copy and pasted random stuff from stackoverflow and irc But that's the point right. He did the same for OCaml and got faster code. Obviously you can write fast code in Haskell, but that is not the same as it being easy.
    - nousernamesleft 13y ago
      >He did the same for OCaml and got faster code No he didn't. He took the time to learn ocaml. >Obviously you can write fast code in Haskell, but that is not the same as it being easy. The closest thing to evidence I can find suggests that it is no more difficult to write fast code in haskell: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=ghc&lang2=ocaml&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
      - lpw25 13y ago
renox 13y ago
I thought that lenses where only needed due to deficiencies/limitation in Haskell? (A kind of workaround).
- nousernamesleft 13y ago
  Nope. Lenses aren't needed at all, they are just helpful. Lenses are just combined getter+setter that are composable. So you can use (lensA . lensB . lensC) to view, update or replace part of a data structure that is part of a data structure that is part of a data structure.
  - renox 13y ago
    Sure but how is that an advantageof Haskell? It seems possible to do the same in any language C++, Java..: a wrapper class which provide an access to a part of another class.
    - codygman 13y ago
      I'm no expert, but I believe it's an advantage of Haskell because of the generality and level of abstraction you are capable of while maintaining type safety. I also think I just described Haskell.
    - nousernamesleft 13y ago
      Because haskell has such a library (a few actually) and ocaml does not. So in ocaml you either have to give up safety, or write a bunch of verbose boilerplate. There's no reason someone couldn't write a lens library for ocaml of course, but the much smaller community makes for far fewer libraries.