Hacker News Reader

Comment by wyager | Hacker News Reader

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).

View on HN

>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) 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.

> 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.

What about the performance challenges caused by lazy evaluation?

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]

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 :)

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?

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).

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.

Compile times and architecture astronomy are obvious counterarguments to the 'Haskell is always superior' delusion ;-)

Reply on news.ycombinator.com