> if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero?

The young economist looks down and sees a $20 bill on the street and says, “Hey, look a twenty-dollar bill!”

Without even looking, his older and wiser colleague replies, “Nonsense. If there had been a twenty-dollar lying on the street, someone would have already picked it up by now.”

Industry makes collective bad engineering decisions all the time, usually driven by secondary factors like institutional momentum or hiring constraints. Did you read the article? It talked about a bunch of things like that.

If you equate market cap with quality, then Java is probably the best language of all time.

> wrote a book on OCaml

I find it hard to believe that anyone who’s really used both prefers OCaml over Haskell. OCaml is nice compared to most crap, but as someone who’s spent years working with both, Haskell wins almost every time.

It’s interesting, actually - I don’t know anyone who’s used Haskell and doesn’t like it. Almost everyone who vocally complains about it hasn’t really used it.

Reading that guy’s reddit posts, I have to conclude he’s some kind of troll - most of the things he criticizes Haskell for are way worse in OCaml, or just completely disconnected from reality.

> I find it hard to believe that anyone who’s really used both prefers OCaml over Haskell.

I've actually used Haskell, Ocaml and Purescript for several years and a lot of locs, and I actually like Ocaml better. Reasons:

- The module system -- a very intuitive way to structure code

- Poly variants

- Strictness -- predictable performance and easy debugging

- Allowing side effects

- Private types -- better than newtypes imo since you can upcast to it's structural counterpart

- Really good type inference -- you never have to write type signatures. Haskell and Purescript type inference is ok-ish and sometimes craps out, which is part of why type signatures for each function is recommended.

- Stupidly fast compiler -- yes it matters, try contributing to the Idris codebase. It's like trying to contribute to the linux kernel, you'll wait 30+ minutes for it to compile.

- Very fast programs

- An actual package manager (stack uninstall?)

It is an overall better experience for me. And the language features that are coming down the pipeline are looking great:

- Modular implicits - a more sound ad hoc polymorphism system than typeclasses. Typeclasses can't handle simple things like if half of the Haskell ecosystem uses one Filterable typeclass and the other half uses a different Filterable.

- Algebraic effects - a strongly typed system for writing effects that will be part of multicore -- delimited continuations / conditions and restarts

These days I'm more interested in Erlang/Elixir though. I just don't think static typing is all that after having spent so much time with Haskell/Purescript/Idris/Ocaml. There are really nice benefits you get with dynamic typing that you don't with static, and there are better ways to deal with those problems that won't be noticeably worse in most business applications with just a little bit of coding discipline, such as good testing habits and having good fault tolerance built into the language.

I do like Haskell though, it's definitely really fun to program in. It's just not something I'd use for anything. If I really needed something with strong static typing I'd either go with Ocaml or Idris.

Idris barely made it out of experimental status and was dog-slow. Not sure when you'd choose that over Haskell for production software.

I probably wouldn't until/unless Idris 2 gained some steam, it would probably be Ocaml.

I was thinking more along the lines of dependent types, because the kinds of problems where you'd really really need strong static types overlap with the need for dependent types, which Haskell has some support for (and Ocaml but less so).

But if I needed to prove something I'd probably do it in Coq since it interops with Ocaml fairly well.

Thanks for the detailed reply.

- The module system -- a very intuitive way to structure code

I see the module system used two ways in production - one is for trivial code-sharing, like to generate Map submodules. The other is for completely incomprehensible nonsense that makes it nearly impossible to find the actual definition of the thing you want. I find typeclasses easier and more ergonomic to use for both the trivial cases (like maps) and complex cases (like json codec generation, for which OCaml still uses the rough equivalent of the basically-deprecated Template Haskell).

- Poly variants

I agree, this is nice.

- Strictness -- predictable performance and easy debugging

I’ve always found this complaint overrated. Sure, it’s slightly annoying sometimes, but surely worth the language-wide discipline that comes with it.

- Allowing side effects

This substantially lowers the quality of production OCaml code compared to Haskell. Tons more spaghetti code, tons of global variables, etc etc.

Obviously purity is kind of a religious argument at this point, but in practice I have observed that it’s a liability.

- Private types -- better than newtypes imo since you can upcast to it's structural counterpart

I’ve never seen this in production. I had to look it up. Indeed, the first article is a blog post along the lines of “why is this useful”?

Haskell also supports casting newtypes via Coercible.

- Really good type inference -- you never have to write type signatures. Haskell and Purescript type inference is ok-ish and sometimes craps out, which is part of why type signatures for each function is recommended.

Haskell type declarations are usually only required with extensions. All OCaml style guides recommend writing type declarations in mli files anyway. The OCaml type system can occasionally infer things more easily because it’s so much weaker - cf the value restriction, no HKTs, etc.

- Stupidly fast compiler -- yes it matters, try contributing to the Idris codebase. It's like trying to contribute to the linux kernel, you'll wait 30+ minutes for it to compile.

Based on my coworkers who do performance optimization on OCaml code, it’s probably because the compiler isn’t optimizing much. But I don’t know much about that first hand. Also, have you tried GHCID or similar? Makes Haskell compilation very fast while developing.

- Very fast programs

Not an advantage over Haskell. They fare similarly in contrived competitions, and I have some suspicions that it’s easier to make Haskell code faster in practice. Some of the shit we do for speed in OCaml is very ugly. OCaml also suffers from very poor GC latencies compared to Haskell. I’ve seen multiple-minute(!) GC pauses in OCaml programs with a few dozen gigs of allocated memory. Never seen anything even close to that with Haskell.

- An actual package manager (stack uninstall?)

I guess I don’t appreciate the benefit of this over the stack model of tightly versioned automatic dependency resolution. Can you expand on some benefits?

- Modular implicits - a more sound ad hoc polymorphism system than typeclasses. Typeclasses can't handle simple things like if half of the Haskell ecosystem uses one Filterable typeclass and the other half uses a different Filterable.

That is by design and seems good to me. Why the hell would I want there to be two different Filterable typeclasses?

The ergonomics of MI remain to be seen but I suspect they will still be more annoying than compiler-resolved typeclasses.

- Algebraic effects - a strongly typed system for writing effects that will be part of multicore -- delimited continuations / conditions and restarts

This is basically vaporware at the moment. I agree it sounds nice, but I have no reason to believe we’ll see it in production in the next decade, and if we do it will probably look a lot more constrained than the idealized model people talk about.

> If you equate market cap with quality, then Java is probably the best language of all time.

Haskell proponents vastly underestimate the importance of stability to industrial users. Java provides some very strict promises about backwards compatibility that make it very attractive if you’re going to write a service and maintain it for decades.

Also, unlike Haskell, I can hire a huge number of Java devs, at a reasonable rate. My company alone would probably double industrial Haskell usage if we were to use it, making hiring a serious challenge.

So yes, for metrics that businesses care about, Java might be the best language around.

> if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero?

Well, one reason we might get stuck on a “suboptimal” language is network effects outside of the criteria we use to compare languages: what language does an organization already have experience with, does the (only) current compiler support the target hardware and system, it’s to late now to write the Linux kernel in Haskell, etc.

However, I agree with you. Despite the time I’ve invested in learning Haskell, I’ve personally decided to spend my time developing in other languages. If Haskell is the magic wand right there in front of us that will give us programs without flaws, how come almost nobody has picked it up and shown us working programs that took less development effort and fewer flaws.

We could compare John Wiegley’s ledger (C++) to the similar hledger (Haskell), but hledger isn’t the same program as ledger it has different features, I have no idea how long it took to write, how many flaws it has versus the original, how different the developer skills were, how much time and defects were saved by it being a redesign, etc. And these are small single developer efforts (now with numerous contributors). From everything I can gather, they are both excellent. So in this case there is no compelling advantage demonstrated for Haskell, and this supports your point.

> We could compare John Wiegley’s ledger (C++) to the similar hledger (Haskell)

I'm confused. Do you know he is a prolific Haskeller and maintains many libs?

I don't understand how that's relevant to the point.

I'm confused. Do you know that he wrote ledger in C++?

Sorry, I thought you were making a point I did not get citing him in comparison with a haskell project. Apologies, I misunderstood.

No worries, I probably wasn't very clear. I wish that someone like John Wiegley would give us his thoughts on Haskell/Lisp/C++. I have a lot of respect for him; he's made big contributions to Emacs and wrote a Common Lisp version of ledger in addition to his C++ version.

Following links in your 1), I liked https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf 'The Genuine Sieve of Eratosthenes' by Melissa E. O’Neill. Somewhat damning and to your point.

Are there any theoretical barriers to writing algorithms in a pure and lazy language with the same space/time complexity as a side-effectful and strict language? I suppose quicksort (also mentioned) is an obvious candidate for study in this regard.

Thanks for linking this. I just read it, and that is some DAMN fine writing.

Sometimes when I complain about jargon and bad writing in scientific papers, people argue back that the author has to be precise. This paper makes it clear that these are orthogonal issues. Writing is a skill, too.

The author is being extremely technical and rigorous, but she is also CLEAR.

Quite the badass.

There's also hash tables. IIRC, Haskell didn't have a good hash table implementation until relatively recently because people religiously avoided mutable data structures. (And the implementation I'm thinking of is not purely functional.)

Haskell has had good HAMTs for quite some time. There isn’t really any benefit to using a mutable hash table over that. In fact, it would probably be slower given the way copying GC works with mutable values.

Yes, there is a benefit: correctly implemented hash tables are faster. Haskell's GC may prevent a good implementation, but that's a problem with Haskell, not with hash tables.

Writing the fastest possible implementation of something is rarely a valid business goal.

The ideal is the midpoint on a Venn diagram of 1) fast enough for our purposes, 2) logically robust, 3) cheap to implement.

Besides, if something absolutely must be the fastest implementation possible and this can’t be done in Haskell, then there’s no reason why one couldn’t drop to the FFI at that point. You could even use template Haskell and write inline-C. It works.

A marginally faster mutable hash table is not really useful for much. If that 30% speedup or whatever is going to make or break your application, a single hash table was the wrong choice anyway.

If this is the kind of thing that keeps you up at night, you should just be using C.

FTI, HAMT = hash array mapped trie

FTI? FYI? At any rate, thanks for the clarification.

"For their information". It's not for centimeter's information, he/she clearly already knows. It's not for mine either; I discovered the answer by DuckDuckGoing!

"Thy"?

Sacrebleu, how can this be? The Haskell one-liner compiles so it must be the genuine sieve of Eratosthenes.

I read those two links. If I ignore some of the points that were valid 10 years ago but not anymore (e.g., there's now stack), and if I ignore some of the personal anecdotes, I come away feeling like much of what is said is not necessarily wrong but is nevertheless an exceptionally negative take. I think you can make almost any tool sound broken and unusable if you use nasty enough and strong enough language about a few examples.

Also, there really is very little substance behind the actual language criticism. It's hard to make a blanket statement that typeclasses are "overkill"; they seem to be showing up all over the place in new languages. Similarly, type annotations are incredibly useful and are also showing up all over the place these days outside of Haskell-land. The point on non-strict evaluation is by far the strongest and most legitimate.

jdh30, the author of both comments, is a massive OCaml fanboy and Haskell hater. I've seen him try to take Haskell performance numbers and interpret them using the wrong units to make them look worse. I'd take anything that he says about Haskell with a big, big grain of salt!

The comments I've just read of his, are at least, all heavily referenced.

After spending nearly a decade thinking about haskell, everything here rings very true.

It's a language whose sales pitch begins by assuming you are using the language: here are all these solutions to problems you now have.

Laziness is the wrong default; it's a catastrophe for writing programs. It requires the whole category-theoretic infrastructure of haskell to solve, and then, imparts insurmountable complexity on writing anything real world.

> Haskell is best at solving problems that Haskell invented and other languages do not have.

That is the most succinct explanation I've ever seen of Haskell.