5 ms·

Haskell is a great language but has plenty of its own warts. The value prop and trade offs between OCaml and Haskell really makes it hard to use one as a drop i

Haskell is a great language but has plenty of its own warts. The value prop and trade offs between OCaml and Haskell really makes it hard to use one as a drop in for the other imo.

wyager 4y ago
Strong disagree; I have thousands of hours with both and I would essentially never recommend ocaml over haskell unless your company already has an ocaml codebase/ocaml expert employees. I'm very conscious of the existence of pareto tradeoffs; I am asserting that, in this case, there is essentially no tradeoff to be made. Haskell is equal or better (sometimes significantly so) in almost every relevant domain. For domains in which ocaml is a better choice, it is not the globally best choice (i.e. both ocaml and haskell are bad in those domains).
- substation13 4y ago
  What about the performance challenges caused by lazy evaluation?
  - belmont_sup 4y ago
    Fresh in both languages. But on studying the Effective Haskell book, there's a whole chapter (chp 14) on learning how to read and write efficient and faster Haskell code. Training that mental model of understanding how IO gets evaluated didn't seem too difficult. It feels akin to remembering how to write fast SQL code - you just practice a bit and measure. In chp 7 on understanding IO, there's also another great section that explains how IO evaluation is often confused. I share an example from the book that reads, writes, and prints files. Memory intensive func because it attempts to read _all_ files at once because the execution of reading and writing actually only happens when the print fn is called (putStrLn files). makeAndReadFile is actually doing both reading and writing - a normal task in all other languages. slow = let files = mapM makeAndReadFile [1..500] :: IO [ String ] in files >>= (putStrLn . show) Efficent version. Here we force reads and writes to actually occur per file instead of waiting til the print. Seems like a pretty easy step to misunderstand. safe :: IO () safe = foldl ( \ io id -> io >> makeAndShow id ) (return ()) [1..500]
  - wyager 4y ago
    People fixate on this, and all I can say is * it has never been an issue for me * I don't think the performance implications are nearly as hard to understand as often implied * in the extreme you can just enable the STRICT language pragma in your project and forget about it :)
    - abathologist 4y ago
      That's funny. This has been a problem for every experienced Haskell programmer I've known who works in Haskell professionally. I wonder what domain you work in where performance and space leaks haven't been a concern?
      - wyager 4y ago
        It's not that space leaks are not a concern; it's that it's actually quite easy to avoid creating them, and if you manage to do so and it becomes a problem, it's usually easy to track down. I don't know any experienced haskell programmer who would even mention this in a list of complaints about the language (which they are sure to have, but they will likely be more abstract).
  - marcosdumay 4y ago
    Most people don't even get to see those challenges. But make wide use of the many performance opportunities created by lazy evaluation. Anyway, when any problem appears, it is obvious, so if it was a large problem, it would be fixed by now. The only reason people keep talking about it is because it nearly never appears. Really, lazy IO is a much larger source of problems, and even there, after a week or two writing IO people just learn to write code that doesn't break due to it.
- abathologist 4y ago
  >Haskell is equal or better (sometimes significantly so) in almost every relevant domain. For domains in which ocaml is a better choice, it is not the globally best choice (i.e. both ocaml and haskell are bad in those domains). I think this assertion is false, but it would take a lot of careful evaluation to prove it one way or the other. The most salient counterexample that comes to mind is modularity and namespacing. Of course it's possible I'm wrong, and Haskell is objectively superior in every regard. But the OCaml language and ecosystem has [a decades long track record of stable and evident success stories](https://ocaml.org/industrial-users https://ocaml.org/industrial-users) and I find it well suited for the kinds of problems I like to tackle. I also like the prevailing vibe in the (still) small community. This exchange reminds of a difference I've observed in the cultural tendencies in the OCaml and Haskell ecosystems: in my experience, OCamlers tend to not be very invested in arguing for the supremacy of OCaml.
  - wyager 4y ago
    > but it would take a lot of careful evaluation This is what I was doing for a number of years. > The most salient counterexample that comes to mind is modularity and namespacing. Polymorphic variants and ocaml namespacing are nice, granted. These are the two ocaml features I've ever missed while using haskell. Minor details overall though. Namespacing is not as useful with typeclasses and PVs have typing problems. > in my experience, OCamlers tend to not be very invested in arguing for the supremacy of OCaml Yeah, this is mostly because it's not as much of a marginal improvement, so it doesn't have as many people interested in shilling it.
- yawaramin 4y ago
  Compile times and architecture astronomy are obvious counterarguments to the 'Haskell is always superior' delusion ;-)

Haskell is a great language but has plenty of its own warts. The value prop and trade offs between OCaml and Haskell really makes it hard to use one as a drop in for the other imo.

wyager 4y ago

Strong disagree; I have thousands of hours with both and I would essentially never recommend ocaml over haskell unless your company already has an ocaml codebase/ocaml expert employees. I'm very conscious of the existence of pareto tradeoffs; I am asserting that, in this case, there is essentially no tradeoff to be made. Haskell is equal or better (sometimes significantly so) in almost every relevant domain. For domains in which ocaml is a better choice, it is not the globally best choice (i.e. both ocaml and haskell are bad in those domains).

substation13 4y ago
What about the performance challenges caused by lazy evaluation?
- belmont_sup 4y ago
  Fresh in both languages. But on studying the Effective Haskell book, there's a whole chapter (chp 14) on learning how to read and write efficient and faster Haskell code. Training that mental model of understanding how IO gets evaluated didn't seem too difficult. It feels akin to remembering how to write fast SQL code - you just practice a bit and measure. In chp 7 on understanding IO, there's also another great section that explains how IO evaluation is often confused. I share an example from the book that reads, writes, and prints files. Memory intensive func because it attempts to read _all_ files at once because the execution of reading and writing actually only happens when the print fn is called (putStrLn files). makeAndReadFile is actually doing both reading and writing - a normal task in all other languages. slow = let files = mapM makeAndReadFile [1..500] :: IO [ String ] in files >>= (putStrLn . show) Efficent version. Here we force reads and writes to actually occur per file instead of waiting til the print. Seems like a pretty easy step to misunderstand. safe :: IO () safe = foldl ( \ io id -> io >> makeAndShow id ) (return ()) [1..500]
- wyager 4y ago
  People fixate on this, and all I can say is * it has never been an issue for me * I don't think the performance implications are nearly as hard to understand as often implied * in the extreme you can just enable the STRICT language pragma in your project and forget about it :)
  - abathologist 4y ago
    That's funny. This has been a problem for every experienced Haskell programmer I've known who works in Haskell professionally. I wonder what domain you work in where performance and space leaks haven't been a concern?
    - wyager 4y ago
      It's not that space leaks are not a concern; it's that it's actually quite easy to avoid creating them, and if you manage to do so and it becomes a problem, it's usually easy to track down. I don't know any experienced haskell programmer who would even mention this in a list of complaints about the language (which they are sure to have, but they will likely be more abstract).
- marcosdumay 4y ago
  Most people don't even get to see those challenges. But make wide use of the many performance opportunities created by lazy evaluation. Anyway, when any problem appears, it is obvious, so if it was a large problem, it would be fixed by now. The only reason people keep talking about it is because it nearly never appears. Really, lazy IO is a much larger source of problems, and even there, after a week or two writing IO people just learn to write code that doesn't break due to it.
abathologist 4y ago
>Haskell is equal or better (sometimes significantly so) in almost every relevant domain. For domains in which ocaml is a better choice, it is not the globally best choice (i.e. both ocaml and haskell are bad in those domains). I think this assertion is false, but it would take a lot of careful evaluation to prove it one way or the other. The most salient counterexample that comes to mind is modularity and namespacing. Of course it's possible I'm wrong, and Haskell is objectively superior in every regard. But the OCaml language and ecosystem has [a decades long track record of stable and evident success stories](https://ocaml.org/industrial-users https://ocaml.org/industrial-users) and I find it well suited for the kinds of problems I like to tackle. I also like the prevailing vibe in the (still) small community. This exchange reminds of a difference I've observed in the cultural tendencies in the OCaml and Haskell ecosystems: in my experience, OCamlers tend to not be very invested in arguing for the supremacy of OCaml.
- wyager 4y ago
  > but it would take a lot of careful evaluation This is what I was doing for a number of years. > The most salient counterexample that comes to mind is modularity and namespacing. Polymorphic variants and ocaml namespacing are nice, granted. These are the two ocaml features I've ever missed while using haskell. Minor details overall though. Namespacing is not as useful with typeclasses and PVs have typing problems. > in my experience, OCamlers tend to not be very invested in arguing for the supremacy of OCaml Yeah, this is mostly because it's not as much of a marginal improvement, so it doesn't have as many people interested in shilling it.
yawaramin 4y ago
Compile times and architecture astronomy are obvious counterarguments to the 'Haskell is always superior' delusion ;-)