1. Nobody's ever heard of it. No one's going to use something they don't know exists.

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

3. It's different. People are always afraid of what's different.

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

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

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

7. Libraries. This is probably the big one, so I'm going to spend some time on it.

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

   B. 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 ^[1], 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. :-/ That said, there is good breadth of databases, including new things like Mongo or Cassandra -- the open source aspect gives breadth if not depth.

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

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

9. 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 them 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 how 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.

It has never gained mass in real projects.

Don't tell that to Credit Suisse ^[1] or Standard Chartered ^[2], two banks which have made great use of Haskell. And don't tell Peerium or Galois ^[3] or any of the other successful startups that use Haskell. Don't tell any Commercial Users of Functional Programming ^[4]. And especially don't tell their customers!

What is true is that we don't see large masses of industry shifting to Haskell, for which I think there are good reasons:

• The cost of entry is high.

  • It is very difficult to predict the time and space behavior of lazy functional programs.

  • You can't do anything serious without understanding monads and type classes.

  • Interfacing with the world beyond Haskell is hard enough that Simon PJ felt a need for the famous Awkward Squad ^[5] paper.

• Haskell is not taught much in US schools.

• Related: people believe it's hard to hire Haskell programmers.

• Industry rewards getting products out quickly, even if the products are barely adequate. Some ways to get things out quickly include

  • Stick with technology that the developers already know.

  • Throw lots of teams at the problem; first one with a successful approach wins.

Haskell is still at a stage where

1. Each individual must invest substantial time and effort before he or she is productive.

2. Once that time is invested, Haskell programmers can be extraordinarily productive relative to counterparts using, e.g, C#, Java, PHP, Python, Ruby.

Until there is a major shift in these factors, I think we will continue to see Haskell used in industry exactly as it is today: either by small programming teams inside big companies, or by small, elite teams in startups. These people will continue to use Haskell for competitive advantage in much the same way that Paul Graham advocates the use of Lisp ^[6].

Why is Haskell used so little in industry?

Because Haskell offers the highest payoff in situations where relatively fearless programmers can invest time up front developing new skills, then apply those skills in small teams. At present, finding this combination of programmers and context in a typical industry setting is still unusual.

I think that the problem is that haskell is not a closed box. You ever feel that you are learning it, no matter the number of years dealing with the language, despite the fact that you can do real programming after a few weeks. The code look clean and understandable. You don´t need to know how to define a new monad nor any else strange, but you feel uncomfortable at this level because there are lots of things to learn.

With Java and C, you can learn every trick conceivable in one year for example. Tou can look at other java code and you are sure you will understand it. You even feel yourself as an "Expert". you sell yourself as such and the confidence translates to your work, your self esteem and whatever.

A Haskell programmer never feel he knows enough. For this reason every newbie is treated so well by Haskell hackers, because they feel newbies in the deep. They know that a world of computational abstractions are there to discover. In a Java discussion group there are people that think that they know everything and has a sense of superiority.

Simply, The industry likes arrogant self confident people.

Regarding what you said:

... I was horrified to discover that almost all of the "success stories" listed on the Haskell in Industry page ... were fakes: ... Bluespec were advertising their product but their customer testimonials were from "Elvis Lives", "Chicken Man", "Painful Eliminations", "Mr. Bigglesworth" ...

While it might make good theater to cite these names as customer testimonials for Bluespec, you might inform your readers that:

1. These are not customer testimonials, but posts on John Coooley's EDA blog, Deep Chip ^[1]
2. John Cooley promises anonymity to his correspondents, and John, as moderator, deliberately invents names like the ones you cite to deliver that anonymity.

Even though I work for Bluespec, I had no idea what you meant by "our customer testimonials" until I Googled the above. It's an unusual experience publicly to be called a fake, based on such thin evidence; I enjoy your sense of humor!

In case anyone is interested, Bluespec is actually doing quite well, and is being used productively by customers that make components that are, I'll wager, in the very computer on which you wrote your post. And, yes, Haskell is the main implementation vehicle for Bluespec's tools.

Cheers,

Rishiyur Nikhil (Bluespec, Inc.)

The advent of multicore is a serious problem for imperative languages and I believe bodes very well for Haskell in particular but also for all functional languages. I think that looking back in 10 years we will see Haskell a still uncommon but not fringe/academic language. Simon Peyton Jones shows graphs of Haskell adoption which have like a 45 degree angle to them--even taken with a grain of salt I think it is clear that Haskell is being looked at much more seriously than in the past. Erik Meijer did a 13 (!!) hour presentation on Haskell on channel 9 ^[1] just recently which is like the biggest web presentation of the language I've come across. I believe this indicates the significant interest by industry regarding Haskell.

Oh... and Simon Peyton Jones is a researcher for Microsoft if you didn't know... and Microsoft (whatever else you might think of them) certainly tends to think in terms of industry... LINQ (part of .NET 3.5) is essentially chunks of Haskell grafted into C# by Meijer who has written/contributed much in the Haskell community, which, again, indicates to me the great respect and influence of Haskell at least in Redmond by folks involved with making .NET.

That said, I also believe that Haskell will need to add a lot of things that imperative lang folks (.NET, Java, Python, etc) take for granted: e.g. standard first class web libraries. There is a lot that is just plain expected as far as plumbing libraries are concerned that Haskell does not have, um, 100% Haskell-certified. The Haskell Platform is an effort to make that so, but there is a long way to go there compared to Java or .NET as far as tooling and standard libraries are concerned.

I think that .NET/Mono with LINQ and the new RX framework is an illustration of the general trend: to be relevant and vibrant, platforms will need to embrace and support functional as well as imperative styles. It's just unfortunate that with .NET it is imperative at core (i.e. the IL) instead of the functional at heart--it seems that it is becoming clear that in order to handle multicore that the platform is better off 'safe (pure) by default'-- and that's that is nearly the tagline for Haskell. To me, that indicates the most significant reason why I believe Haskell will grow--it's pure by default.

Join the Industrial Haskell Group, or come to the Commercial Users of Functional Programming, and find out why groups do use Haskell for commercial projects.

• http://haskell.org/haskellwiki/Haskell_in_industry

Your question would be better phrased as: what holds functional languages back from widespread use, in general, as Haskell, if anything, is more widely used than most / all FP languages*.

Postscript: To justify the above claim, here's what informed it. Community data compared with similar functional languages: Scheme, Erlang, OCaml. I don't have data for F# as they don't seem to use traditional open source community tools.

• Ranked higher on TIOBE ^[1] (July 2010) than all but the hybrid Lisp/Scheme/Clojure coalition (?)
• More libraries ^[2] on Hackage ( 2666 ^[3]+) than for OCaml, Erlang, Scheme
• Larger community: bigger IRC channel ^[4] (several times over), reddit ^[5] forum, more SO questions ^[6], and annual workshop ^[7] than other FP languages.
• More hackathons ^[8] (and larger ^[9]) and user groups ^[10], in more places, than other FP languages.
• Larger documented industrial presence ^[11].
• More active writing ^[12]/teaching community.
• More Google Summer of Code ^[13] slots, for more years (based on number of student requests).
• Haskell jobs growth in the UK ^[14], ahead or equivalent with other FP languages.

Because it turns your brain inside out. Not that there's anything wrong with that.

Seriously, I understand that functional languages are more prevalent than you'd think in the financial industry. (Because of massive parallelization?) But when I asked a programmer I know at Goldman Sachs about it, he didn't know much about functional languages.

Why aren't my favorite shows as popular as the reality show du jour? The lowest common denominator is accessible to everyone.

"Big set of libraries" is subjective. Compared to Java, .Net, Python or PHP it's pretty small with few alternatives if a particular library doesn't quite do what you want. That said, the set of available libraries is increasing all the time and there's been a lot of progress in the last couple of years.

One reason why Haskell has not taken off so much in commercial development is that the focus of the Haskell community has tended to be more academic. They work on things that are important to them, not necessarily what is important to commercial software developers.

The community also have (had?) the unofficial motto of "avoid success at all costs". I take this to mean that if there were lots of people using Haskell and GHC this would likely result in a more conservative approach to progress, which is something they want to avoid.

Partly because it never gained mass in real projects, I guess, and that is intended to be circular reasoning. Popularity feeds on itself. There are network effects.

It's also different. Looking at the Next Big Things that I've seen for personal computers, there's BASIC, Pascal, C, C++, Java, and C#. These are all very similar in terms of how you'd write a function, although program organization varies wildly. Scripting languages also seem to follow this rule; Tcl isn't very popular any more.

Because it was taught as part of first year uni programming and made everyone cry :(

The words Haskell and Recursion still make me cringe...

Edit:

I think I need to clarify this as people seem to be getting the wrong idea. I don't think Haskell is a BAD language. However, I had a bad experience when I was first introduced to it and I'm pretty sure that a lot of other programmers who did it as a core subject in first year university had a similar experience.

If you have a bad experience with a language, you're less likely to pursue it and to want to use it. Therefore as you progress through industry you'll probably not choose to implement such a language if there are alternatives available. This is the point I'm trying to make and I do think it's valid.

Perhaps you don't agree but that's the point of a subjective topic right? I'm more than happy to debate the point but blindly penalizing me for not sharing your opinion seems a bit harsh...

Who cares? Is it more important that a language is widely used or that the ideas that it is built upon spread far and wide?

(Obviously someone cares. But to me, it seems as though it's more important that the ideas behind Haskell get popular and not necessarily the language itself.)

I'm in the unusual position of having learnt Haskell, as an experiment, before I knew anything about programming. At the moment I'm finding learning C# extremely unsatisfying, and thinking 'imperatively' rather difficult! Functional styles just seem more natural to me.

Haskell is a very strictly single-paradigm language and an academic experiment in programming in a purely functional way. Occasionally (such as when dealing with massive concurrency) this restrictiveness does more good than harm, but the future of real-world programming is in multi-paradigm languages like Python, C#, Ruby and D that recognize that no one paradigm most clearly expresses every problem or even every small subproblem within a single module.

For real-world programming you need to be able to mix and match paradigms at a fine granularity and choose the right tool for the subproblem, not be forced into a strict one size fits all paradigm. I personally find all single-paradigm languages extremely restrictive, whether they are OO, procedural or functional. Using multiple languages is not the answer because it forces the blending of paradigms to be too coarse-grained.

It's just too different.

Valuable, experienced employees aren't going to be able to switch over from Java to Haskell overnight, so the switching cost is both high and a hard sell. We can argue that it's a more productive language, but it's not a 100% guaranteed home run. A company considering a switch is going to have a wizard C++ programmer who is possibly more productive than the person agitating for more Haskell usage, which makes the sales pitch less convincing.

If you are a small company, and your staff already knows Haskell (its popularity is increasing, after all), then you will still get pressure from large companies because it will be harder for them to integrate your components in the event of a buyout, merger, or working arrangement.

I have experience using FP languages in the research and prototyping phases of technology R&D, but I need to work in a way that will allow for a gradual rewrite to a more mainstream language. This is productive for me, but, admittedly, a burden for the production engineers. The rewrite is needed due to immature tool support on more exotic hardware platforms and the specific expertise of the folks who are taking ownership of the product. Once you have a working Haskell program that demonstrates a concept, risk management can dictate that you now eliminate the risk of working in an obscure language that has less collective wisdom about it and for which there are fewer available practitioners.

Your question applies to a number of languages, not just Haskell.

PL/I is a great language. Many hated it because it came from IBM.

APL is a fantastic language ... it did not get very far because it used mathematical symbols and initially required a Selectric typewriter terminal with an APL type ball. Ken Iverson, ACM Turing award winner created APL and later J. J is free and ASCII based and very powerful. See http://jsoftware.com

Why are powerful languages not well accepted? Blame the educators. Many stick with what they know. Also, there is a lot of vendor influence. c got off to a good start because it came with UNIX and UNIX was more or less provided to universities for free.

Government is also to blame ... government sales are a huge part of the global IT budget. Many vendors often cater to governments rather than focusing on relatively unproven technologies.

So part of the answer to your question is there is that part of human nature that wants to play it safe. For many years with respect to hardware choices, there was a well known saying: "no one ever got fired for buying from IBM"; whether that saying is true or not, it shows that many decision makers are not willing to be part of the leading edge of technology.

BTW, Haskell is not necessarily the best language ... I doubt there's one best language.

If you look at FORTH, LISP, assembler, et cetera, there are many "best" languages. Some languages are terrible for some tasks and excel in others. That's why we have the saying that if your only tool is a hammer, then all of your problems will tend to look like nails.

The best that a programmer can do if her/his company does not use the language the she/he prefers is to attempt to influence her/his company and/or find another company that uses that language.

Regardless the language that one uses most frequently, it's a good idea to learn other languages, including ones that have significantly different paradigms.

Regards,
Gerry (Lowry)

Object oriented programming appeared as an attempt to adopt computers to the way people think.

Functional programming appeared as an attempt to make computers manipulate mathematical objects.

Not that many people are good at math. Hence object oriented programming is much easier for most people. Functional programming can be beautiful and intellectually satisfying, but it is hard and not too natural for humans.

Pure functional languages are not very good at handling state. It obviously can be done but in a rather convoluted way. Maintaining state is very simple in imperative languages.

The basic answer is that Haskell is very difficult to Get Things Done in.

Reasons include:

• Lack of good libraries
• Very stringent type system
• Very few good tutorials that get you beyond mathematics
• Inability to conform to standard paradigms
• Lack of a very good IDE

Further, other languages provide exactly as much computational power with a far shallower learning curve.

While Haskell might be 'The Future', Lisp has been the future for 50 years, for exactly the same reasons as Haskell postulates now, and still isn't widely used.

Broadly speaking, there are two kinds of software company.

Most software houses have a product or two that they sell. This product line is their chief asset; it embodies everything they know about their customers requirements and also represents several years of work for their programming staff. All development effort is spent maintaining and extending the existing products in a race to stay ahead of the competition. Rewriting any part of this is out of the question because that would mean their product would stand still in the market place for a year or two, at which point they would be out of business anyway.

Bespoke developers produce specialist software to order, in response to a specification produced by a customer. At the small end these are a mix of web development companies who build apps on top of an existing framework like Rails, and bands of code-monkeys-for-hire who use whatever technology their customer specifies. Neither can use Haskell. At the big end market forces cease to work because the apps they build are strategic investments for their customers, so when the software house tells the customer it will take twice as long and cost three times as much as the contract says, the customer can either agree or else abandon the project and return to square one. In practice the latter is usually not a viable option. Hence these companies bid whatever they think will win the business, even if it is substantially less than the likely cost. Then once the customer is locked in they can jack the price up at their leisure. Because there is no real connection between bid price and actual cost, there is no business case for investing in improved technology like Haskell.

This is an over-simplification of course. At the big end many companies have a hybrid model in which they sell a base product which is then customised. But the basic reasoning remains the same. It also applies to in-house software development; mostly this is aimed at maintaining whatever critical business apps already exist.

For an example of a big bespoke project where the client didn't just roll over when the contractor told them the price was going up, Google for "bskyb eds". This is an extremely unusual case because EDS were actually found to have been deceptive, but note just how far EDS had to go to lose even one count. If the divisional MD had a real degree, or had bothered to get an engineer to draw up a schedule (no matter how ridiculous) they would probably have won the case.

As people have pointed out, there are companies out there using Haskell to do real things. In time the competitive advantage provided by Haskell will mean that these companies will win out. See http://www.paulgraham.com/avg.html for a story along these lines. But this will take time. Haskell use seems to be doubling about every year, but since it also has less than 0.1% market share, at that rate its still going to take it several years to become a major language.

I am quite new to Haskell ,but I think it would take major industry support for Haskell to become mainstream, and that industry support will be the reason that F# would likely be the major FP language in the next years.

Now,strictly as a language , I see a problem(ignoring the stuff like network effects, etc) that I’m not sure has been fully addressed yet- it’s (natural) “backwards to the industry” approach to “doing stuff” and the requirement of “too many specialities”,compared to other languages.Of course, that is a problem of the educational system.

So, one would be able from the get-go to do easily stuff that would be more difficult and verbose in other languages (solving mathematical problems e.g. writing functions f:A->B), including using the power of the type system,fixed points,zippers etc to solve them in very beautiful way(and here we’re not even starting to think about performance). It is also be very easy to understand stuff like design patterns and why they are important.

However, to do something that can be easily seen as “real world”, such as manipulating state or IO, or basic Web development,we quickly reach the point where if I have to channel my inner Topologist and jump seamlessly up and down algebras across three categories , and imagine pointed functors (and actually I really enjoy doing that and don’t say it ironically) in order to track state while reading data ; and then profile to see if I need to be lazy or strict.

It’s expressive power and clear and provable semantics, are ahead of everything I know of. However, people like to clearly understand the semantics of what they are doing. Not that you need to necessarily know any Category theory to be productive in Haskell (I don’t know, since I am not too good in either), but how much is too much? Natural transformations?Monads?

A big problem in learning Haskell is that these concepts have to be studied way too early who is the natural Haskell programmer? First, to be productive ,they should be interested in doing real things and solving real problems quickly and efficiently. Second, they should have at least decent (i.e. better than me) “engineering skills”, e.g. willingness to use Emacs or Vim,willingness to go trough C code (and some understanding of the preprocessor) to write appropriate FFI calls- with even C++ bindings beign difficult, as far as I understand, and the associated skills, since there is no industry-level IDE and toolchain (I use Leksah, and I know that proper set-up makes it good to use, but still).As mentioned, some knowledge of (and perhaps passion for) pure mathematics is preferred so that one knows what’s happening when they generate random numbers, and of course. And of course, computer science and engineering knowledge (for example for tasks like in the profiler chapter of RWH). And of course ,development under windows is difficult sometimes (for me) due to the C bindings.

So, it seems much harder to find such people.

F# ,I think, although I like it less than Haskell in the “language” department (exactly because of the lack of purity), seems better for the industry ,due to the .NET support,and might make FP more popular and boost the usage of Haskell as well in certain domains, though..

Here is an answer based on real experience, seeking to solve a real "industrial" problem within, as always in industry, a limited time.
The problem involved use of HTTPS (ssl) libraries. There are some in the Hackage, but they work only with "Examples", for real use I was faced with a choice of re-writing the libraries or turning to a different language. I tried Python, it worked straight away, and enabled me to solve the problem within the restricted time scale.
I spent some time trying out the different Haskell libraries, most of them are still at the "experimental" stage. In other languages they are "ready for industrial use".
And in "industry", unlike "hobbyism" or "academia" it is all a matter of time - time == money.

It is just a catch-22, if something is unpopular, then it is very hard (can be rationally accepted as "impossible") to get popular.

Haskell requires so much learning curve and mathematics knowledge, plus, you must change the way you are thinking.

I am able to understand programming languages that I did not learn, except Haskell or Prolog, until I learned it later.

It is growing in popularity and almost getting popular in the investment banking industry but it is fair to say that problems recruiting suitable developers are holding back its adoption further.

So if you want a highly paid and challenging development job (albeit in London or NYC) then learn it.

If you are happy bashing out acres of boilerplate in programs that have a less than 50% chance of making it through the first cycle of testing then you'd best stick with Java or C#.

Libraries are getting richer, I abandoned Scheme (another functional language) in favour of Haskell for the sole reason that there are rich libraries to choose from. As with most other languages, you can always glue in C libraries if necessary so you shouldn't find yourself at a complete dead end.

Popularity is relative and changes over time. Java was niche and risky at one point, then it was the best thing since sliced bread and now is in decline.

I think one of the main reasons of low popularity of Haskell is "a spirit of academism" that surrounds this language. What we see at Wikipedia's page of Haskell? Factorial and Fibonacci numbers?? WTF?!! Where are real, practical examples of usage??

Yes, we know about very good books "Real World Haskell" and "Learn You a Haskell for Great Good", but very many developers NEVER heard about it. And they continue to think about Haskell as about "some academical bullshit". So I think Haskell's users must to debunk this myth.

These people all come up with 'global reasons'. Some may be true, others may not be true. It's difficult to say. I prefer to share just my personal experience. I tried to learn Haskell but somewhere along the tutorial I realized I just liked object oriented programming too much.

For me objects reduce complexity. By simulating a physical problem using objects I find solutions. This is an evolutionary process. Together with clients I try to build my software around a landscape of objects until, together we discover a good solution. It's a very natural way of thinking and working. I miss the objects.

Functional programming is too much like Math. It may be perfect, but I am not.

Sooner or later, the technology that triumph in industry is the one that the best programmers use for enjoyment in its spare time. It happened with whole operating systems such is Unix/C. What drives industry is what drives everything: Beauty. A beatiful tool is the one that achieve power trough simplicity and has many discovered and undiscovered useful gems to play with. Most programming languages are closed. They have nothing left to discover. You can learn Java in a month. As a consequence , just to differentiate themselves, java programers spend time in doing simple things in complicated ways. Java verbosity and the architectures that Java world promotes make me feel sometimes that I´m in front of exhibitions of nothingness. Most industrial sofware is plagued with buggy hierarchies of classes and unnecessary interfaces. But most haskell programmers spend time doing complex thing in simple ways, by hiding the complexity in elegant abstract libraries. The best minds are now thinking in haskell. Is a matter of time for Haskell to triumph in industry