Why is Haskell used so little in the industry?(flyingfrogblog.blogspot.com)
flyingfrogblog.blogspot.com
Why is Haskell used so little in the industry?
http://flyingfrogblog.blogspot.com/2010/05/why-is-haskell-used-so-little-in.html
6 comments
I remember this post from a couple of years ago. I also remember thinking that it reflected more poorly on this guy than it did Haskell, and I think it still does today.
Additionally, one of the more important criticisms that I actually shared with the OP is that it took me a few evenings to get up and running with Haskell around 2008-2009 on Mac OS X. However that problem has been just about completely solved by the Haskell platform (http://hackage.haskell.org/platform/) these days.
Also, recent activity in the Snap and Yesod web frameworks makes me more optimistic for Haskell adoption in industry, although it still has to clear a lot of adoption hurdles before it becomes more common.
Additionally, one of the more important criticisms that I actually shared with the OP is that it took me a few evenings to get up and running with Haskell around 2008-2009 on Mac OS X. However that problem has been just about completely solved by the Haskell platform (http://hackage.haskell.org/platform/) these days.
Also, recent activity in the Snap and Yesod web frameworks makes me more optimistic for Haskell adoption in industry, although it still has to clear a lot of adoption hurdles before it becomes more common.
I'd like to throw in there that, even in 2010, it took me all of 20 minutes to get GHC going on a fresh machine. Perhaps he's using hyperbole?
The OP is clearly a troll. The question remains interesting, though.
My theory is that Haskell has a lot of usability problems. A programming language is a UI for programmers. Usability issues are always a sufficient explanation for market disappointments in any product or field.
Most notably, Haskell is rooted in a theoretical foundation that's essentially a major subfield of 20th-century mathematics, using concepts and notations which most programmers (a) do not understand, (b) do not want to understand, (c) do not need to understand, and (d) in many cases are not physically capable of understanding (eg, they have IQs < 140, or other sorts of subtle congenital damage to the math lobes).
As "LYAH" demonstrates, it's possible to teach programmers (or at least a certain subset thereof) to use Haskell without fully understanding it. But this approach has serious UI problems of its own. It's not very comfortable to use a platform whose semantics you don't understand. There's no comparable hidden complexity in Ruby, Python, Perl, JS, etc.
Laziness is also a significant UI problem, inasmuch as it becomes cognitively very difficult to understand and/or control the performance of your program. Typically in UI, when you find one UI disaster you find more - it shows that usability was not a principal goal of the project.
One of the difficulties in diagnosing usability problems of this type is that people rarely complain about them directly, because their complaint would typically be of the form "Haskell made me feel stupid." My guess is that for everyone who's succeeded in learning them a Haskell, there are four or five who tried it and came away feeling stupid. Not a very pleasant sensation.
My theory is that Haskell has a lot of usability problems. A programming language is a UI for programmers. Usability issues are always a sufficient explanation for market disappointments in any product or field.
Most notably, Haskell is rooted in a theoretical foundation that's essentially a major subfield of 20th-century mathematics, using concepts and notations which most programmers (a) do not understand, (b) do not want to understand, (c) do not need to understand, and (d) in many cases are not physically capable of understanding (eg, they have IQs < 140, or other sorts of subtle congenital damage to the math lobes).
As "LYAH" demonstrates, it's possible to teach programmers (or at least a certain subset thereof) to use Haskell without fully understanding it. But this approach has serious UI problems of its own. It's not very comfortable to use a platform whose semantics you don't understand. There's no comparable hidden complexity in Ruby, Python, Perl, JS, etc.
Laziness is also a significant UI problem, inasmuch as it becomes cognitively very difficult to understand and/or control the performance of your program. Typically in UI, when you find one UI disaster you find more - it shows that usability was not a principal goal of the project.
One of the difficulties in diagnosing usability problems of this type is that people rarely complain about them directly, because their complaint would typically be of the form "Haskell made me feel stupid." My guess is that for everyone who's succeeded in learning them a Haskell, there are four or five who tried it and came away feeling stupid. Not a very pleasant sensation.
>I hate to ad hominem, but this guy is a known troll of the Haskell community.
I could not care less. The post is well-written, and makes a case. You can criticize his case, or even the facts he mentions or you could ignore them, but calling him a troll is totally unproductive (essentially it means: "his arguments are BS because he is a bad person, but I won't say what's specifically bad about them").
I also find that (to keep with Sturgeon's Law perhaps) 90% of uses of the accusation "troll" are misuses, mostly translating too "the guy makes arguments we don't like, and he won't go away".
Also, to everyone: he doesn't say that installing Haskell takes too days. He says it took 2 days to HIM --and AT THE TIME. Perhaps he wasn't using the all-too-might distribution you are using where it's one apt-get away...
I could not care less. The post is well-written, and makes a case. You can criticize his case, or even the facts he mentions or you could ignore them, but calling him a troll is totally unproductive (essentially it means: "his arguments are BS because he is a bad person, but I won't say what's specifically bad about them").
I also find that (to keep with Sturgeon's Law perhaps) 90% of uses of the accusation "troll" are misuses, mostly translating too "the guy makes arguments we don't like, and he won't go away".
Also, to everyone: he doesn't say that installing Haskell takes too days. He says it took 2 days to HIM --and AT THE TIME. Perhaps he wasn't using the all-too-might distribution you are using where it's one apt-get away...
I think Simon Marlow's comment sums it up. "Welcome to Jon Harrop's magic world where everything is not as it seems!"
Last time this was posted, this is what happened: http://news.ycombinator.com/item?id=1396532
It's full of nasty, personal attacks that have no place on this forum.
It's full of nasty, personal attacks that have no place on this forum.
I've been using an awesome haskell app (xmonad http://xmonad.org/) for a long time and haven't had any issues with it. It is quite popular. It's a neat tiling manager which helps me immensely. I am sure there are other haskell success stories.
This article is very scary as the guy is throwing a lot of numbers, would love to see someone from Haskell post a rebuttal.
This article is very scary as the guy is throwing a lot of numbers, would love to see someone from Haskell post a rebuttal.
I think the problem is very simple. We don't like to admit it, but the largest amount of programming is not done solving hard problems, but instead writing around other peoples code, facilitating the use of other peoples systems and specifications.
The programmers job is to facilitate the flow of information to get some desirable end result.
The programmers job is to facilitate the flow of information to get some desirable end result.
I don't mean to be cruel, but Haskell is simply not a good language for 2012. It feels like I'm programming for 1983, with the poor syntax and silly idioms.
There's a reason that eight out of the ten top programming languages in use today are C or C descendants - C is a great language to read and write, and for 90% of programming tasks (and 99.9% of business programming tasks), how easy it is for the programmer to comprehend and express himself in the language is the biggest factor in productivity.
There's a reason that eight out of the ten top programming languages in use today are C or C descendants - C is a great language to read and write, and for 90% of programming tasks (and 99.9% of business programming tasks), how easy it is for the programmer to comprehend and express himself in the language is the biggest factor in productivity.
C and C descendants happen to be the primary reason we have not really moved forward any further than where we are right now. To build a mildly succesful C application, you needs lots and lots of code. The question is: Does it necessarily have to be so?
Haskell as a language is far more advanced and your "feel" might actually be right: You are now programming in the 80'es rather than the 70'es which most C-descendants really are programming in :)
Haskell as a language is far more advanced and your "feel" might actually be right: You are now programming in the 80'es rather than the 70'es which most C-descendants really are programming in :)
You need to write lots and lots of code to write a successful application in any language, really...
To build a mildly successful C#, JavaScript, Java, Perl, or PHP application, you need very little code, and all of these languages are vastly more popular than Haskell because it is orders of magnitude easier to get things done in those languages compared to Haskell.
>C and C descendants happen to be the primary reason we have not really moved forward any further than where we are right now.
Really? This implies you have some knowledge of what would have happen if C/C-descendants did not exist.
It also implies that C/C-desc adoption was a historical accident, or an idiotic move, instead of something based on very pragmatic decisions. To write a performant program until at least 1990, from a word processor to a game, you needed not only C-level speed but also lots of tricks and twists to your code (ingenuity), most of which were only possible because of the low-level access C provides and the programmer's knowledge of the program's state (so a higher level compiler couldn't easily derive and do the same optimizations for generic programs). And sometimes you even have to drop in assembly. Remember all those 80's games (like Prince of Persia) written in assembly?
So, even if C didn't exist, it would have to be invented (or something much like it). Worse case scenario, we would be using assembly.
After the 90's, with 486's etc, the situation got better, in the sense that we could even afford garbage collection. Still, our expectations got bigger too. Whereas 256 graphics and SID sound on a largely uni-tasking system was good for the eighties (at best you have some expensive Unix workstation and you run X with 4-5 programs loaded, X-eyes included), we now want millions of color, multiple CD-quality sound streams playing, 10-20 heavy programs loaded at once, GPU compositors, streaming audio and video, anti-aliased fonts, etc etc.
So, still, a high level solution feels slow compared to C/C++ when it does today's state of the art (for 10-years ago or yesterday's state of the art, even Python or Javascript is sufficient). Same for UIs (where waiting for the user's actions is the largest slowdown).
As long as you get into the "cpu intensive" or "memory bound" issue, anything but C/C++ seems slow.
(C descendant's like Java/C#/Go etc are also slow --not arguing that. Any multimedia app done in Java, for example, is like a relic from the 90's).
Really? This implies you have some knowledge of what would have happen if C/C-descendants did not exist.
It also implies that C/C-desc adoption was a historical accident, or an idiotic move, instead of something based on very pragmatic decisions. To write a performant program until at least 1990, from a word processor to a game, you needed not only C-level speed but also lots of tricks and twists to your code (ingenuity), most of which were only possible because of the low-level access C provides and the programmer's knowledge of the program's state (so a higher level compiler couldn't easily derive and do the same optimizations for generic programs). And sometimes you even have to drop in assembly. Remember all those 80's games (like Prince of Persia) written in assembly?
So, even if C didn't exist, it would have to be invented (or something much like it). Worse case scenario, we would be using assembly.
After the 90's, with 486's etc, the situation got better, in the sense that we could even afford garbage collection. Still, our expectations got bigger too. Whereas 256 graphics and SID sound on a largely uni-tasking system was good for the eighties (at best you have some expensive Unix workstation and you run X with 4-5 programs loaded, X-eyes included), we now want millions of color, multiple CD-quality sound streams playing, 10-20 heavy programs loaded at once, GPU compositors, streaming audio and video, anti-aliased fonts, etc etc.
So, still, a high level solution feels slow compared to C/C++ when it does today's state of the art (for 10-years ago or yesterday's state of the art, even Python or Javascript is sufficient). Same for UIs (where waiting for the user's actions is the largest slowdown).
As long as you get into the "cpu intensive" or "memory bound" issue, anything but C/C++ seems slow.
(C descendant's like Java/C#/Go etc are also slow --not arguing that. Any multimedia app done in Java, for example, is like a relic from the 90's).
There's a lot of hand-waving here. Do you realize that C syntax predates 1983? Can you explain what it is about Haskell syntax that irks you? Can you provide examples of silly idioms?
The C syntax predates 1983, but it works.
Haskell's operators are wonk:
[0,1,2,3]!!2
versus:
[0,1,2,3][2]
Clearly !! is a logical array indexing operator.
Haskell's operators are wonk:
[0,1,2,3]!!2
versus:
[0,1,2,3][2]
Clearly !! is a logical array indexing operator.
You can define your own operator, if you want to.
There are legitimate gripes you can have about Haskell syntax, but this is just trolling.
There are legitimate gripes you can have about Haskell syntax, but this is just trolling.
Calling someone a troll because they disagree with you is pretty offensive.
And I don't want to define my own operator. I can define my own words in English as well, but I'd rather use the same words everyone else is using so it will be easier to communicate with them.
If Haskell were as great of a language as you say, it would be more popular.
And I don't want to define my own operator. I can define my own words in English as well, but I'd rather use the same words everyone else is using so it will be easier to communicate with them.
If Haskell were as great of a language as you say, it would be more popular.
What you're saying is that you don't like Haskell's syntax because it's not C's syntax. The unfamiliarity card is not a legitimate card in the game of criticism.
> I'd rather use the same words everyone else is using so it will be easier to communicate with them.
Would you be happier if C was the only language, and everyone just had to use C?
> If Haskell were as great of a language as you say, it would be more popular.
This is completely non sequitur. Popularity has little to do with the advantages offered by a language. At one time, C was not so popular.
> I'd rather use the same words everyone else is using so it will be easier to communicate with them.
Would you be happier if C was the only language, and everyone just had to use C?
> If Haskell were as great of a language as you say, it would be more popular.
This is completely non sequitur. Popularity has little to do with the advantages offered by a language. At one time, C was not so popular.
What I'm saying is that C is ubiquitous because it has strong syntax, and Haskell is not because it doesn't.
I like C's syntax, but I also like Lisp's and Scala's and SQL's.
> Would you be happier if C was the only language, and everyone just had to use C?
If C were as powerful as a modern programming language (JavaScript) and had the standardization of a libraries that Perl or PHP has, then I'd be okay with writing C. The only reason I don't is because C has been improved upon. Haskell is a step back.
> This is completely non sequitur.
Of course it isn't. Popularity has a huge amount to do with the advantages offered by a language. If a language was crap, no one would use it.
At one time, C was not very popular, but in the last 20 years almost all of the most popular languages, year after year, have been C or its descendants.
I like C's syntax, but I also like Lisp's and Scala's and SQL's.
> Would you be happier if C was the only language, and everyone just had to use C?
If C were as powerful as a modern programming language (JavaScript) and had the standardization of a libraries that Perl or PHP has, then I'd be okay with writing C. The only reason I don't is because C has been improved upon. Haskell is a step back.
> This is completely non sequitur.
Of course it isn't. Popularity has a huge amount to do with the advantages offered by a language. If a language was crap, no one would use it.
At one time, C was not very popular, but in the last 20 years almost all of the most popular languages, year after year, have been C or its descendants.
By now it's clear to me that your argument has reduced to "I personally don't like Haskell's syntax, therefore Haskell cannot generally be a good language."
If you don't want to use Haskell, that's fine. Don't use it. If you have legitimate criticism, I'd like to hear it.
If you don't want to use Haskell, that's fine. Don't use it. If you have legitimate criticism, I'd like to hear it.
Can you explain what you dislike about it? It's a different operator, certainly.
I'm pretty sure that it has an "odd" shape, because indexing a list in Haskell is potentially O(n). The operator itself is essentially a warning...
I'm pretty sure that it has an "odd" shape, because indexing a list in Haskell is potentially O(n). The operator itself is essentially a warning...
This is the first time I see someone seriously dismiss, and choose, a programming language based solely on its syntax. Also the first time I see one to pretend Haskell makes it more difficult to express oneself because of the syntax.
Surely, you were talking about the comments syntax. They really make it horrible to express anything.
Surely, you were talking about the comments syntax. They really make it horrible to express anything.
> This is the first time I see someone seriously dismiss, and choose, a programming language based solely on its syntax.
You've never read a Lisp thread with non-Lispers, have you? :-) The amount of whining about parentheses is incredible.
You've never read a Lisp thread with non-Lispers, have you? :-) The amount of whining about parentheses is incredible.
To be fair, as a non-Lisper that knows Lisp, it's all about the libraries and the language-as-a-platform.
If WordPress was written in Lisp, I'm sure many more people would use it. It's sort of a chicken and egg problem, I guess.
If WordPress was written in Lisp, I'm sure many more people would use it. It's sort of a chicken and egg problem, I guess.
I've also seen an incredible amount of judgmentalism applied to Objective-C's message passing syntax. Does it look foreign to a speaker of classical C? Absolutely. But I found that pressing through the initial shock, I've come to realize that it's just another language syntax, and not particularly hard to either understand or type.
I choose every language I use based on the expressiveness of the syntax. What other reason is there to choose a language?
Usually, expressivity in a programming language is not really a matter of syntactic constructs but a matter of semantic constructs. But choosing a programming language involves much more than semantic (or syntax). Depending on the situation, community, compilers and tools, libraries, consultancy houses, documentation and books, are all reasons to choose or not a language.
Some even says that the number of programmers available on the market for a language is important. I don't think it is a good reason but a related one is: your existing user base is composed of companies and consultancies with their own programmers; you can't abruptly choose a different programming language than the one they know.
Some even says that the number of programmers available on the market for a language is important. I don't think it is a good reason but a related one is: your existing user base is composed of companies and consultancies with their own programmers; you can't abruptly choose a different programming language than the one they know.
I would disagree. Semantically, we're reaching a point where most popular languages have a similar feature set (semantically speaking), and as new semantic constructs are created, they're quickly ported to other languages.
I agree with you about the 'platform' of a language, though. That's one of those things that you can't get away from.
I agree with you about the 'platform' of a language, though. That's one of those things that you can't get away from.
Semantics.
Why choose a language with good semantics if the syntax is awful?
Most languages today offer the same semantics - first class functions, objects, namespacing. Apart from that core, there isn't really a huge variance except for fringe languages that, generally, have severe syntactical limitations as a result.
Most languages today offer the same semantics - first class functions, objects, namespacing. Apart from that core, there isn't really a huge variance except for fringe languages that, generally, have severe syntactical limitations as a result.
Disagree. Haskell is one of the only truly next-gen languages there is, primarily due to its ambitious design goal of software assurance - basically, it was designed from the ground up to better enable programmers to write error-free code.
The Haskell designers identified the main sources of errors in code as mutable state and side effects (network communication, writing to disk, etc), and then constructed a language that enforced isolation of that code into specific containers, monads.
All code outside monads is guaranteed to be purely functional, referentially transparent, immutable, and side-effect free. It's an idea that seems simple in hindsight, but is rather brilliant.
Add to that Haskell's green-thread concurrency and multicore/cpu parallelism is probably one of the best kept secrets in programming these days, and you've got an amazing language and platform for anyone who takes the time to shift to its paradigm.
The Haskell designers identified the main sources of errors in code as mutable state and side effects (network communication, writing to disk, etc), and then constructed a language that enforced isolation of that code into specific containers, monads.
All code outside monads is guaranteed to be purely functional, referentially transparent, immutable, and side-effect free. It's an idea that seems simple in hindsight, but is rather brilliant.
Add to that Haskell's green-thread concurrency and multicore/cpu parallelism is probably one of the best kept secrets in programming these days, and you've got an amazing language and platform for anyone who takes the time to shift to its paradigm.
Really? I've found Haskell's syntax and overall design to be the most elegant of anything I've tried. I really appreciate the lack of unnecessary punctuation which litters other languages.
I can understand the sentiment. I was a Lisper before I came to Haskell, and initially, the syntax seemed verbose and unnecessary. As it turns out though, the syntax is very simple and well designed. There's just a lot of optional sugar, which also happens to be well designed.
Rather than downvote his posts or comments to oblivion, I recommend reading it all with a lot of skepticism.
For one example, he claims it takes two days to install the Haskell compiler. I can refute that from personal experience, or you could just consider that it's really implausible anyone would ever try out such a language. (And then visit their downloads page and see it's the same as Ruby or whatever: apt-get install or download an installer and run it: http://hackage.haskell.org/platform/ )
Edit: the post is from 2010. Present tense in the above is all wrong.