This question was recently posed (and closed!) on stackoverflow. The top voted reply is so good I thought I'd replicate it here! I'm afraid all I know of the original author is their "Orphi" posting name.
It's tongue-in-cheek and broadly true, although I'd argue the details of a few points. I think it's interesting that it doesn't contain the main reason blocking me from using it on a daily basis. More on that in a moment.
First, here's Orphi's response:
- Nobody's ever heard of it. No one's going to use something they don't know exists.
- It's unpopular. People assume that the most popular language is the best language, because if it wasn't good, it wouldn't be popular. This is actually untrue; as you can see, the most popular language is the most popular language. To put it another way, Haskell is unpopular because it's unpopular. This is what Haskell programmers refer to as "recursion", and despite what imperative programmers tell you, it's extremely common in The Real World.
- It's different. People are always afraid of what's different.
- It's difficult. People think that Haskell is difficult to understand or difficult to learn. This is almost certainly related to point #3. It's also related to the fact that the Haskell community is populated by people who casually remark "a monad is just a monoid in the category of endofunctors, what's the problem?" and expect normal human beings to comprehend this.
- It's risky. Most companies don't want to be the first to use something. Haskell isn't being used by many people, so not many people want to try it. (See this recursive unpopularity argument again?)
- Can't hire programmers. First, by #2, there aren't many programmers who already know Haskell. Second, most people believe #4, which means you can't train programmers to use Haskell. (At least, it would if it were actually true.) A language that you can't hire programmers for is a very, very risky proposition indeed. (Which leads us back to #5.)
- Libraries. This is probably the big one, so I'm going to spend some time on it.
- Quality. We have the quantity. We do not yet have the quality. Most of Hackage is one-man hobby projects with little to no documentation. Some of it is incomplete, some of it has long since bit-rotted, some of it malfunctions if used in certain ways.
- The Outside World. If you want a binary heap tree, Hackage probably provides a dozen implementations. If you want to connect to an RPC server and fire off a few procedure calls... good luck with that. Same deal for talking to databases, accessing OS resources, manipulating binary file formats... You'll basically have to write everything yourself from scratch. This is a big deal for commercial work.
- Multiple incompatible libraries. You can, in fact, connect to a database in Haskell. Trouble is, at the last count there's about a dozen libraries for doing this, and it's bewildering trying to figure out which ones are actively supported and which ones are zombie projects that stopped working years ago. It's also not as simple as hooking up an ODBC connection; there are different backends for each library and each DB target. Yay. :-/
- Windows. Almost all the important libraries (for cryptography, binary file formats, network protocols, data compression, talking to databases, etc.) are Haskell wrappers around C libraries. And these all fail to build on Windows. Given that Windows is
the single biggest target platform on the market, this is a big deal.
- Unpredictable performance. This is way, way down at #8. Most people don't know enough about Haskell to even know this. Most people just assume that "Haskell is slow". This is demonstrably untrue. What is true is that it can be hard to predict the performance of a Haskell program. Subtle, apparently irrelevant changes can sometimes make big performance differences.
- Correctness. Most companies don't give a **** about correctness. They don't care about quality. They just want to shovel code out the door as fast as possible and earn wads of cash. If there are bugs, they'll charge the customer money to fix them. Getting code right is of no interest; getting code fast is what counts. Haskell is a language that rewards those who sit back and deeply analyse the problem, and then produce a beautiful solution. Most companies don't care for this approach; let's just hack something together as fast as possible, and worry about fixing it later (i.e., never).
There are a few places where correctness matters. These are either safety-critical systems, or financial systems, generally. I gather Haskell tends to be quite popular here.
One final pair of data points:
- I can still remember not so long ago hearing people cry "C++ is a toy language for n00bs! You should use a proper programming language like C." Now take a look around you and see how many large-scale C++ programs there are.
- People have been claiming that Lisp is "the next big thing" for, what, 40 years now? Lisp is older than almost every programming language in mainstream use. And now many large-scale Lisp programs are there?
Which fate awaits Haskell, I don't know. I rather suspect all the good ideas of Haskell will be stolen by the likes of C# and hybrids like F# or OCaml,and people still won't ever use Haskell itself. It's just too different.
But anyway, as to why industry doesn't use Haskell, see the points above. It's too rare, too unpopular, too weird, and has incomplete libraries. That's basically it, in a nutshell.
The missing item for me is how hard it is to embed. For my purposes, I need to embed Haskell within an existing C++ framework, not dissimilar to how you might embed Lua. I need to do so in a compiler agnostic manner, where I retain control over how the embedding occurs (i.e. compilation and linking) and have significant influence over the operation of the runtime. In short, Haskell must fit in to my existing C++ environment, not the other way round.
An interesting aspect of an "Embedded Haskell" would be you could remove most (if not all) of Haskell's IO support if it made the job of embedding Haskell significantly easier. The ability to efficiently embed 'pure' Haskell would be a very interesting and useful tool in it's own right 1. It's a simple idea, and therefore doesn't take many words to state, but I'm keen to not understate how significant this could be.
Playing the counter argument, it could be argued that my needs are rather domain specific and an Embedded Haskell is not likely to be important enough to aid mainstream adoption of Haskell. This attitude does appear to be reflected in some parts of the Haskell community.
To start anecdotally, when I hear people propose writing something in Haskell, they generally imply the only option on the table is to write it in Haskell wholesale. Most arguments about use of Haskell I have read online focus on this either-or situation. For nearly all the reasons made in the quote above, this polarised position doesn't appeal unless you have very tailored circumstances and considerable resources.
There is also evidence of a lack of emphasis at a more fundamental level. GHC and the tools and libraries ecosystem that surround it are not designed with embedding as a goal. GHC is primarily focused on producing stand alone executables, which it does very well. Interoperability tools like Greencard immediately sideline the ability to call Haskell from C as having "little demand". Most emphasis is placed on wrapping C libraries for use in Haskell. The best I can find online are some open student projects such as the ageing GSoC ticket #1555, or the Embedded Haskell thesis topic in the PLS group. I believe this situation might be starting to change though, as the desire to remove the implementation obstacles surrounding much of Haskell's inspiring research builds, and new developments such as the LLVM backend present additional options.
Wholesale adoption of Haskell is undeniably risky and definitely not the only way. Incremental adoption is where it's at, and in a nutshell, that's what Haskell is currently missing the most.
- As an interesting historical aside, when Haskell first took up its purity banner, monadic IO did not exist and Haskell programs were pure functions of type [Response] -> [Request], where these types provided a limited set of options such as ReadFile, WriteFile, RequestFailed, ReadSucceeded for the side-effecting wrapper program to interpret. (See the Awkward Squad tutorial for further details.) Generalise this to a pure iteratee and you are probably in the right ballpark. [↩]