Stack OverflowWhy is Haskell used so little in the industry?
[+248] [26] GabiMe
[2010-02-17 22:26:15]
[ haskell functional-programming ]

It is a wonderful, very fast, mature and complete language. It exists for a very long time and has a big set of libraries. Yet, it appears not to be widely used. Why ? I suspect it is because it is pretty rough and unforgiving for beginners, and maybe because its lazy execution makes it even harder

(35) Common guys, please reopen this question. I honestly think it is a very important question (even if somewhat subjective) - GabiMe
(17) I don't see how it's subjective--"why do many people not use Haskell" is a question with (multiple) objectively correct answers. The problem is that the only people who know the answers are people who didn't choose Haskell for a real project and something tells me those aren't the same people who answer questions on SO tagged with "haskell". - C. A. McCann
(1) it's not really that fast: - Claudiu
(3) As a person who has worked on GHC's code generator, I have to agree with Neil Mitchell's assessment that it is very immature. - Norman Ramsey
@Norman Who cares about GHC's assembly code generator ? I thought that -O2 makes GHC to use gcc anyway to produce the binary - GabiMe
(2) You do realise that for every Haskell library there are at least 100x more java libs. The same is true if one counts developers and every other important metric. - mP. regarding Haskell through gcc, that is so 2003 :) Seriously, the gcc path has now been deprecated to the point where it is going to be supported only in ways that perform very badly relative to the native code generators. The native codegens are the future. - Norman Ramsey
(21) Closed again ?? Seriously, almost every question can be regarded as subjective. This is obviously an interesting and important question. Why do you insist closing it every time ? What bothers you ? Please reopen - GabiMe
(40) Some people on here need to get off their power trip and let us discuss what we want. When a topic becomes a problem then that is the time to close, not before - there is clear interest here and it's being handled maturely by the participants. - Ryall
(8) @Nat: SO is not a site for discussion. It is a Q&A site. - gnovice
(10) @gnovice Then maybe you should tell that to the top person on this site, Jon Skeet. Just go check his top three questions: - Ryall
(5) @Nat: Those questions were asked well over a year ago when SO was still in its infancy. Many top users have questions like that, and many people (myself included) think that old cruft like that no longer belongs. Unfortunately, the powers that be have decided to give those old questions a stay of execution and keep them around for posterity. But that doesn't mean we should allow more questions like that now that the rules for SO have become more crystallized than they were back then. - gnovice
(1) SO isn't a "discussion" board! - Jarrod Roberson
(12) I think Jeff abused his mod power by closing this question. - titaniumdecoy
(3) Absurd that this is closed; voting to reopen. It's got many objective answers. - John Feminella
(2) @John: I don't think it is absurd. It also has many subjective answers, e.g. from academics. - Jon Harrop
[+415] [2010-02-20 12:56:03] Orphi [ACCEPTED]
  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.


(42) That's a really complete answer! +1! - Paul Nathan
Yes. A really good and complete answer +1 - GabiMe
nitpick: "People have been claiming that Lisp..." Which people? Seriously, Lisp? I can't think of a single example but perhaps we're both suffering from selection bias. - wds
Although I voted up, I think #9 is not really fair about SW industry; there are companies out there that do strive to release good quality SW (I know some), and try to reduce the cost of maintenance (for customers and for themselves). - jfpoilpret
(13) > 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. This has sort of been the fate of Smalltalk - it's been strip mined for good ideas without ever being widely adopted. Which I guess is slightly better than being ignored :) - teapot7
(2) I agree that Haskell will probably be mined for ideas rather than widely used, but this is actually sort of by design. According to…, one of the informal slogans of Haskell is to "avoid success at all costs"--i.e., parts of the community prefer it to be not so widely used so it can be more flexible with experimental stuff (not necessarily a bad thing). - shosti
one of the best answers I have seen here so far. - user172818
"Nobody's ever heard of it." So true! +1 - fastcodejava
(9) "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." ---- Please look more closely at -- there are more than 2000 libraries, 50+ database bindings, 100s of System libraries , many for binary parsing, and by my count a dozen RPC libraries - Don Stewart
(13) Don, you're going to have to take the rose glasses off and stop defending Haskell so vociferously. I like Haskell myself, but you have to admit that it lacks a lot in terms of coherence, consistency and support in its libraries -- and these days it's the library and not the language that makes or breaks a language. A perfect example is your "50+ database bindings". That was already referred to in the answer above: lots of bindings, very little cross-compatibility and many left in unusable states because they're hobby hacker projects, not professional grade. - JUST MY correct OPINION
(2) Like CPAN, Haskell's library set is at the whim of open source developers. We have breadth of libraries, if not depth. - Don Stewart
(6) I've written some more on the state of the Hackage libraries, and what we're doing about it. Better than complaining about too much Haskell code, IMO.… - Don Stewart
(1) It's unfortunate that @Orphi didn't get any points for this excellent answer... - Judge Maygarden
+1 for point #9. Dayum, you nailed it! - Synesso
(1) +1 I did my homework assignment in Haskell but before doing so, I needed to explain my teacher what Haskell was because he never heard of it before. - WTP'--
For the record, C++ is still a toy language. - Matt Joiner
I have heard comments from industrial users who /do/ use Haskell and do it very enthuastically, that they keep hurting due to #8. - Joachim Breitner
For the record, Lisp is the second-oldest programming language, full stop. Only Fortran is older. - greyfade
[+114] [2010-02-17 23:59:45] Norman Ramsey

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.


(4) +1 excellent answer... One thing that prob should be mentioned along with your comments is that it's fairly obvious that Haskell is gaining traction... & with multicore putting the thumbscrews to the imperative paradigm will probably along with all other functional languages gain a healthy & larger group of users in industry. - Kevin Won
(9) @Norman Ramsey: your comparison is right on spot regarding "industry" acceptance... Paul Graham wrote Viaweb in Lisp and sold it for $50m or so, but what is less often emphasized is that latter on Lisp proved inadequate and it got all rewritten... In Java. That's the thing: it's great for startups, but good luck finding a team big enough that has the functional knowledge. It's a bit like the Twitter Scala/Java SNAFU. "We use Scala everywhere at Twitter... uh, oh, except for the part where performances are needed, that is 100% Java because Scala is less predictable". - SyntaxT3rr0r
(14) I sometimes think that if we can name most of the corporations using a language X in a single post, then language X is likely not used that much. I can certainly agree with your post, though. - I GIVE TERRIBLE ADVICE
(3) @WizardOfOdds: Interesting. I heard similar stories from people at AT&T where Tim Griffin had written some fantastic software for talking to the 5ESS phone switch (in ML) and eventually it was done over in C++ (ballooning to 10x the size) because middle management at AT&T didn't want to gamble on being able to hire people to maintain something in a "research language". More recently I think AT&T has managed to get better use out of the products of its own labs... - Norman Ramsey
(5) WizardOfOdds: From my memories of what Paul Graham has said about Viaweb being rewritten, it was more because a C/C++ solution was mandated from above than any performance issues with the Lisp solution. - Vatine
@Vatine: Yup sorry I wasn't clear... The perfs issue was related to Scala @ Twitter (where Java performed better), not to Viaweb. For Viaweb it got rewritten because basically they couldn't find enough Lisp wizards to maintain it IIRC. It's typical in this industry: see the interesting Norman Ramsey story. We know that for many tasks, for example, Erlang is just so much better, but we have to be pragmatic and think about maintainability. So you balloon to 5x or 10x the size, but weirdly it ends up being more maintainable, simply due to manpower availability. - SyntaxT3rr0r
(2) I find it a little ironic that the evidence you cite to prove Haskell has a substantive presence in industry is a committee geared toward finding if Haskell has a substantive presense in industry :) - San Jacinto
@San Jacinto: I think the case I'm trying to make is that Haskell has a small presence in industry, and to try to explain why the presence is (a) nonzero and (b) small. What you think is 'substantive' is up to you... - Norman Ramsey
@Norman Yes, I was just making a joke. Your point is well taken (at least by me). - San Jacinto
You know the quote "It has never gained mass in real projects." still stands if you read it as "not enough real-world projects have used it", which is how I read it. I think the person saying that (question asker?) meant to say "critical mass". - wds
(1) "Haskell offers the highest payoff". What gave you that impression? - Jon Harrop
@Jon Harrop: laziness is the one extra powerful feature - of course, any such judgement can't be anything else than an opinion. To find out why laziness is important, this link is useful: - Blaisorblade
(2) Number of Haskell programmers at Credit Suisse falls to zero:… - krawyoti
(1) @krawyoti: that might be true (or not), but there is no further link from there to a reputable source, say from Credit Suisse. That blog is run by Jon Harrop, who is not surely a Haskell fan. This claim is also present in…;, and it seems to be acknowledged by Haskell users which worked in Credit Suisse (I'm not sure), but I can't find a link about that. - Blaisorblade
@Blaisorblade: Ganesh Sittampalam told me that in a pub at an F# meet. I'm sure he'd tell anyone interested enough to ask him. - Jon Harrop
Can't get a reason behind this 2.Once that time is invested, Haskell programmers can be extraordinarily productive relative to counterparts using, e.g, C#, Java, PHP, Python, Ruby., why you think so? - sll
[+53] [2010-02-19 12:17:10] Alberto Gömez Corona

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.

(13) +1 For this interesting answer - GabiMe
(5) If the industry likes arrogant self confident people, the ability to spout unsubstantiated/subjective claims that your language "is more widely used than most / all FP languages", has "excellent support and performance [for multicore]", the most expressive type-system, and superior FFI, should definitely be an advantage, if anything. - Pascal Cuoq
(4) If you think you can learn every trick conceivable in C in a year, I don't want you touching any of my C programs. Ditto for Java. - JUST MY correct OPINION
(3) I liked almost everything of the answer except the "arrogance" part. Maybe you can't learn all of C in one year (I actually think you can), but I know most language corners, including preprocessor, enough to program the Linux kernel - same for the Java language (not platform of course). Whenever there's a language problem with those, I can solve it easily, while in day-to-day Haskell usage, I never know what's happening (yet), and even more so than C++. Many people reject C++ exactly because of this complexity - that's one reason why C is still widely used (by the Linux kernel people for one). - Blaisorblade
I'd agree, you could learn C quite quickly, libc no, but C yes. You might think you know more than you do if you came from a language without const, static, etc. though. Haskell itself takes considerably longer even if you're coming from another functional language. C++ takes considerably longer than C though, way way longer, probably longer than Haskell. C's const isn't complicated, but C++'s const method require slightly more thought. And C++ offers four different casts, custom allocators, template meta-programming, etc. - Jeff Burdges
[+24] [2010-05-31 18:09:13] Rishiyur Nikhil

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.


Rishiyur Nikhil (Bluespec, Inc.)


(2) "It's an unusual experience publicly to be called a fake" After Bluespec referred me to those customer testimonials I asked for verifiable testimonials and was referred to someone who turned out to be a former flatmate of one of the founders... - Jon Harrop
[+23] [2010-02-18 04:31:29] Kevin Won

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.


(5) It doesn't matter that it's imperative at heart because all modern computers are imperative at heart. Even Haskell compiles to imperative code. IL is an implementation detail and is not something you should have to care about as a developer. - Billy ONeal
(3) just to clarify--I mean that the CLR is object oriented and impure. those were design decisions that are at odds with pure functional languages. - Kevin Won
"significant interest by industry regarding Haskell". You're talking about three people at Microsoft (Simon Peyton-Jones, Simon Marlow and Erik Meijer). They do not represent industry. Indeed, none of them have ever even worked in industry. - Jon Harrop
[+19] [2010-02-18 04:11:18] Don Stewart

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.

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.


(1) Are you sure ? That Haskell is more widely used than the other FP languages ? Any statistics? - GabiMe
Lisp is probably the most widely used FP language for the same reason Cobol is the most widely used programming language. I do not think Haskell even comes second, but I do not have any argument for that. - Pascal Cuoq
I have a feeling that Scheme beats Haskell in terms of popularity - GabiMe
@bugspy only based on attendance at the CUFP workshop, and on the size of the various communities. The fact is that we don't have good statistics. - Don Stewart
(3) According to TIOBE, the top 5 most popular FP languages are Lisp, Scala, Erlang, Logo and Alice. The next in the list is "OCaml/F#," followed by Haskell, so I'm not sure if either of those Caml languages is actually more popular than Haskell or if they just win because it's two against one. At any rate, that's at least one measure that doesn't make Haskell look so popular. - Chuck
(5) TIOBE's reasonable, but I'm not sure I quite believe that Logo and Alice are FP languages in wide use... :-) I can point out that 500 different developers have produced nearly 2000 libraries for Haskell in 2 years. I'd be surprised if any other FP language is close in the scope of the libraries or developer team. - Don Stewart
(1) Come to think of it, TIOBE counts use in schools, which would explain the popularity of Logo and Alice. - Chuck
(1) Why is Lisp/Scheme counted as a "functional language"? It's hospitable to functional programming, sure, but so can Python or Lua be. Most Scheme code I see is imperative. - dubiousjim
(1) @profjim: That would better be asked as a question rather than a comment IMO. - Chuck
(1) OK, done: - dubiousjim
(4) @Don: "Haskell, if anything, is more widely used than most / all FP languages". Mathematica has millions of users and dozens of commercial libraries. The F# Hub has over 20,000 registered members and F# has several commercial libraries. The Haskell-Cafe has 715 subscribers and Haskell has no commercial libraries. - Jon Harrop
(1) @Chuck Be careful of TIOBE - it oscillates pretty crazily. May 30, 2010: the top 5 most popular FP languages are: 1. "Lisp/Scheme/Clojure" (one language!), 2. Haskell. 3. Alice 4. Caml/F# (1 language?) 5. Scala 6. Erlang. 7. ML. - Don Stewart
Javascript and Matlab allow FP and are both pretty popular... - Josh
Matlab? It allows for function handles, but as a functional language it is very primitive, and also unsuitable as a general purpose language because of its embarassing performance. And its official documentation does not lead you through the path of functional programming. Javascript is more interesting, but it's still more of an imperative language with functional features (actually, technically in this regard it seems similar as Lisp, it's just the usage pattern which differs). - Blaisorblade
[+16] [2010-02-17 22:32:05] dubiousjim

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.

(14) +1 unfortunately, there is a shortage of geniuses in the world - Gabe Moothart
(3) I wonder if Oleg is ever on SO... - dubiousjim
(4) "Because it turns your brain inside out. " & upside down and backwards. - Kevin Won
Quantitative analysts at financial organizations may use functional programming, and maybe even some algorithmic traders, but for the core systems, C++ and Java are used for pushing data through trading systems and around the market. - Dr. Watson
(11) You don't need to be a genius to use Haskell, just a competent programmer that isn't afraid of mathematical terminology. Oleg has also done work in other languages, and it's just as mind-bending as his Haskell stuff. - C. A. McCann
(1) I think part of the problem is the vast majority has started programming on a procedural language (basic, java, python, ...). It's much easier to learn a new language that allows basic procedural coding, if you're already used to it. - wds
A very interesting case about OCaml in the financial industry: It's worth reading. - Vitor Braga
[+14] [2010-02-17 22:43:56] patros

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

(2) Come on, man. We all know your favourite show is Teletubbies. - f100
(5) The Teletubbies are so vulgar. A certain purple dinosaur will always have my heart. - patros
[+12] [2010-02-17 22:47:08] Dan Dyer

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

(5) My Linux distro has 1326 Haskell libraries, and that's not even all of Cabal. Now how much coverage they give, and how many useful alternatives, I can't say. But newcomers to the language (like me) quail at trying to keep track of what libraries do what. - dubiousjim
(1) agree on the comparitive lack of libraries. Also: it's weak specifically on the 'hottest' part of computing if by part we can include anything to do with the web. There just isn't much 1st class libraries for web dev. (I think that's sort of cool actually). - Kevin Won
(5) The first question you have to ask about libraries isn't coverage, it's quality. How many of them are in alpha? How many are abandoned? How many are direct wrappers around C libraries (i.e. not very Haskelly in appearance, losing the benefits the language gives), and of those, how many are lagging significantly behind upstream? - Pavel Minaev
[+10] [2010-02-17 22:50:07] David Thornley

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.

[+10] [2010-02-19 02:15:26] Ganesh Shankar

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

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


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

Seriously though, I understand WHY they thought us Haskell but it IS a difficult language for beginners. And programmers do tend to follow the languages which they enjoyed learning/coding in... (You can penalize me for this, but I believe it is a valid opinion) - Ganesh Shankar
(2) I think this answer is more correct than people are giving it credit for. - Coxy
For a "subjective" topic, people don't seem to be very tolerant of opinions... - Ganesh Shankar
(8) Recursion is a fundamental concept used in many areas of computer science. That an admittedly harder language was taught in a way that was hard for first year students is unfortunate, but probably doesn't shed light on why it isn't used in industry. C++ templates are not particularly easy, and probably aren't taught to first year students, and yet are extensively used in industry. - MtnViewMark
(1) Thanks for the clarification. I removed my down-vote. Your clarification brings to mind two thoughts: 1) Indeed, the state of teaching or even talking about Haskell is too fraught with the abstract mathematics behind it. Fortunately, books like "Real World Haskell" are starting to provide more practical alternatives. 2) As our industry advances so rapidly, we have to view our university experiences as initial exposure, consciously seek out new understanding all the time. I hope over time, you'll learn new truths about recursion that won't make you cringe! - MtnViewMark
The same happened with (VisualAge for) SmallTalk at my uni, about 10 years ago. We all hated it, and it left such deep emotional scars that I haven't touched it since. Not sure whether the language or the interface was to blame. - kibibu
@MtnViewMark: I disagree. The fact that recursion is a universally-used principle in CS is true. The fact that Haskell is likely the worst language to consider in introducing programming to new programmers is also undoubtedly true. And if a concept is taught in a bad, unenjoyable, confusing way that concept will not be used later in life barring some really big changes. C++ introductory courses tend to avoid the hairier aspects of templates, so C++ isn't avoided by people who learned that way. - JUST MY correct OPINION
[+8] [2010-03-29 23:33:12] MSN

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

This is a good point; and reading through the Haskell tutorial I'm pleasantly surprised at how much of it I understand thanks to bits of Haskell being scattered around inside Python. - kibibu
[+8] [2011-12-12 01:12:25] Popsi

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.

[+7] [2010-02-19 23:38:05] dsimcha

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.

Haskell is a pretty great imperative language, so it is a multi-paradigm language in practice. - Peaker
Java is extremely popular (probably as popular or more popular than the languages you list) without being multi-paradigm. In my experience, Python is only vaguely so in practice--I don't think any "pythonic" code I've seen is anything but imperative OOP. Ruby and C# (thanks to LINQ) are good examples. I don't know much about D :( - Tikhon Jelvis
[+6] [2010-02-19 15:44:11] Anthony

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.

What about the risk of rewriting a working program? I thought that this was usually considered a bad idea. - Noah Lavine
(2) It is a risk, but the idea is to explore a really large design space (i.e. all possible programs) to find a solution to the problem, then do the rewrite in a much smaller design space (i.e. programs that are observationally equivalent to your exemplar). - Anthony
[+6] [2010-02-19 16:04:37] gerryLowry

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

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.

Gerry (Lowry)

(1) When did J go free? Last I looked at it (which is about fifteen seconds ago) the critical bits (VM and GUI code) were still proprietary binary blobs which can be opened as source only through extensive licensing fees and NDS signings. - JUST MY correct OPINION
(2) Oh, +1, incidentally, for "I doubt there's one best language". - JUST MY correct OPINION
@ JUST MY correct OPINION -- J as a tool/language is free but is NOT open source. It's possible that some/ALL J source may be available for free for much earlier versions of J. Cheers - gerryLowry
[+5] [2010-02-19 23:24:35] shura

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.

(8) "Maintaining state is very simple in imperative languages." Which is why maintaining state is the cause of such a huge number of bugs. - Justin Smith
(11) When I was first learning object oriented programming, it sure didn't feel like "the way people think". Then I learned to love it and was happy with Java for a while. However, after having programmed in Haskell for a couple of years, it again feels strange to me, having to shoehorn everything into objects. I think programming in a particular language shapes the way you think, more than the other way around. - Tom Lokhorst
(12) The way people think naturally is disorganized and imprecise, because people are smart enough to "do what it means, not what it says". Computers are stupid, deterministic machines, so programming requires structured, abstract thinking, which is inherently unnatural. It's also what math is all about. Anyone who can't learn enough math to use Haskell (even if it takes a while) really isn't cut out for programming. - C. A. McCann
(2) @camccann Exactly! In general; I'd say that someone who isn't capable of the correct level of abstract, structured thinking, isn't cut out for any kind of programming. That includes object oriented programming, they probably can't create the correct object abstractions and class hierarchies. The difference is that they can't get even the most basic programs to work in Haskell, but somehow seem to be able to muddle through in Java... - Tom Lokhorst
Computers are deterministic? I wish someone would tell my laptop that so it stops randomly freezing up. :D (Note: all digital components are made up of analogue components.) - JUST MY correct OPINION
@camccann, Tom Lokhorst: good programmers are able to abstract, but mathematics (and Haskell) very much requires you to abstract over abstractions (over abstractions). Most mathematicians I talked with about category theory were surprised that it could be used at all, exactly because it felt over-abstract to them (and they were students of abstract algebra!). One example are these valid comments about the potential problems of point-free style: - Blaisorblade
@Blaisorblade: Yes, but it's not just Haskell. References and indirection in imperative languages with mutable state can be just as challenging. Where Haskell has pointless code, C has three-star programmers. Some of the more convoluted OOP design patterns start veering into the same territory as well. - C. A. McCann
The prototype of signal() is difficult to write, but you never do that. I don't claim being a Haskell expert, but I knew what to expect from the C compiler and could fix any error easily in 99% of cases, and anticipate most of them, while in Haskell that'd require manual type inference in many cases (especially in the few cases it doesn't work, including type families, for instance in the Vector package). Given how unhelpful are GHC's messages, I think I'll have to learn doing type inference as fast as counting before being a Haskell programmer :-(. - Blaisorblade
(2) @Blaisorblade: Stuff using GHC extensions can get arcane, yeah. But if you want some quick general advice: 1) undefined has any type, use it as a placeholder to get things to type check so you can see what other stuff comes out as. 2) Add type annotations (including inline) for what you expect the type to be, this gives better errors than two inferred types conflicting. 3) Split large functions into smaller pieces bound at top level, then recombine them in GHCi and see what breaks when. - C. A. McCann
[+5] [2010-02-19 23:30:25] Paul Nathan

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.

(4) +1: And interoperability. Popular new languages are either JVM- or CLR-based. - Jon Harrop
Real world Haskell or Learn You a Haskell for Great Good are two excellent tutorials from differet viewpoints. And with EclipseFP just finishing being polished from a Google Summer Of Code, it looks great. - Tyr
[+4] [2010-02-19 22:49:58] Paul Johnson

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

[+4] [2011-08-29 16:11:31] Stefan Petrov

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

For what it's worth, both Scala and Clojure are getting far more market growth than F#. - missingfaktor
[+4] [2011-10-22 19:54:50] hdq

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.

[+2] [2010-03-29 23:18:16] SHiNKiROU

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.

[+1] [2010-05-17 12:55:01] Andrew

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.

[+1] [2012-04-27 12:30:46] Denis Shevchenko

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.

[0] [2012-05-27 07:15:40] Gabor de Mooij

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.

[-2] [2012-06-03 21:05:39] Alberto G. Corona

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