Any professional programmers care to weigh in here? I have always been under the impression that, while Haskell/Scala/insert super awesome programming language may be the "best" language, you should really be using the right tool for the job, which should mean different languages for different tasks. All of this assumes an equal supply of talented programmers for every language, by the way, something that I am aware is far from true.
The article DOES recommend using different languages for different tasks. A large part of it was about Ruby and Python shops that added Haskell to their toolbox in order to clean up overly complex parts of their codebase.
As far as the supply of programmers is concerned, if a software developer is TRULY talented, then they will be able to learn a new language in a couple of days, and learn a new paradigm (such as functional programming) in a couple of weeks. I say this as a person who has moved from imperative programming to object-oriented programming to functional programming over my career. And I have used so many languages that I have difficulty even enumerating all of them. They range from machine language, to various assembly languages to FORTRAN, COBOL, C, Visual BASIC, Java, Python, Ruby, Scala. The hard part of programming is not the coding. It is the DESIGNING. If you do the design part well, then the code flows from your fingers naturally, and you end up doing very little debugging, especially if you practice TDD which forces you to debug problems within 15 minutes of creating them.
Well, I don't know about a couple of days for learning a new language, but I agree with the sentiment. Learning a new language is more than figuring out the syntax for a loop. It's the library(s) that takes time.
Most languages are general purpose languages. The often repeated notion that languages are tools in a toolbox, where one is a hammer and another is a saw is really a very terrible analogy. For the vast majority of software projects, there is no "right tool" language, you can literally just use the best language. The issue is more than people do not agree on what is the best language. I would say it is more often the case that the availability of a particular library or framework pushes one language as being preferable for a task than anything about the language itself being especially suited for that task.
Long time self supporting programmer here. With a company around it supporting a bunch of other programmers. We write in C so that may cloud your opinion of my opinion :)
My opinion rarely resonates with HN because HN is full of programmers who are well into the top 5% of programmers. The last thing any of those fine folks want to hear is anything bad about their favorite language, be it Lisp or Haskell or Clojure or $SOME_OTHER_LANGUAGE_IM_TOO_DUMB_TO_USE.
I'm the dumbest guy on our programming team. I'm also the lead. My main service to the company is to try and keep the code base debuggable. I do that by limiting clever things as much as I can.
Haskell strikes me as very clever. It's sold as if it will produce less buggy code; I've not seen real world evidence that that is so and I highly doubt it is impossible to write bad Fortran in Haskell.
So perhaps the reason that Haskell hasn't taken over the world is that it seems to be something that "smart" people like and more average people don't understand. Any business that doesn't worry about how they are going to support their products (and hence their source base) down the road isn't going to survive very long. The rockstar leaves and everyone else starts rewriting his code.
This story is as old as the hills, it's been the same way ever since there have been programmers. A really great programmer can get the job done in any language and a true rockstar will write code that even I could understand.
It is not. You should check it out some time. For purposes of this post I will pretend haskell and ghc are one in the same (ghc is the most popular haskell compiler). Haskell is built around a very simple, straightforward core language (shockingly enough called "core"). There is massive resistance to adding anything to haskell that can not be expressed in core and would require changing it. Haskell values simple, powerful abstractions that can be widely re-used. Haskell has not taken over the world because it doesn't want to. Python has not taken over the world either, I doubt many people would claim it is because python is too hard or too complex. Taking over the world does not appear to have any correlation with being a good language.
A lot of what HN perceives as good I perceive as a problem that I will be left to solve.
I'm old, I'm over 50, got kids, spend a fair amount of my pile of ability each week trying
to coach those kids in hockey.
Still working on the company, still trying to make money, still trying to keep it going.
Every time someone shows up with something like Haskell I either beat it out of them
or I fire them.
I'm sorry but I don't have the energy to deal with your new cool language. I've got a
company to keep going, a life to live, I just want to take care of our customers and
do it in a way that the next guy can understand and support.
Haskell might be God's gift to programming, I don't care. My job has nothing to do with
making people like you happy. I've got customers I need to take care of, Haskell doesn't
help. I've got employees I need to take care of, Haskell doesn't help (we are weird in that
we've been around for 15 years and most of my guys are still here, we're all getting
old and when you get old all that clever shit starts to look like stuff you can't
support).
We recently added some pretty complex stuff to BitKeeper, basically a file system
and a VM system. For a frigging source management system. In user space. Life is hard
enough in C, you want to toss Haskell into that mix? Really? Come interview with us and
you'll run screaming from Haskell and everything like it.
I'm old and I fire people who try to innovate in my company with new technical ideas seems like a weak argument.
If you don't care about new technology and would rather focus on your owns hockey, that is fine, but please don't go on the attack(1). It demotivates people who want to innovate with new "clever shit"
1. It was not a direct attack, but I would consider making a point against something then purposely ignoring an experts defense in at least the same category
You said it seems clever. I explained that it is the opposite. Why did you feel the appropriate response to that information was a random crazy rant about how old and cranky you are? If the idea of learning something offends you then don't learn, that's fine. But don't pitch a fit when someone corrects a misconception you are repeating.
Unfortunately many companies let themselves be led into a complex mess by so-called "rockstar" developers who usually are just people who have mastered a particular language and its libraries, and perhaps one common framework in that language. This allows them to churn out masses of poorly written code and bamboozle management into thinking that they are 10X productive. They are like the sales guy who makes some big sales, collects his commission checks, and then leaves the company before everyone finds out that the product was not suitable for that customer, and the contracts are cancelled. Then, working for another company, he does the same thing again. Some companies now withold part of their commission payments for a period of time to be sure that the product was sold correctly, that it gets delivered to the customer properly, and that the customer begins using it and gaining some value from the product.
However, in software, we let rockstars create a big mess, and then over the next few years we spend many man-years of effort into maintaining that software, fixing bugs, attempting to shoehorn new features into a system that is rigid, inflexible and even fragile. This is what rockstars bring us, momentary euphoria until the concert is over and we are stuck in a traffic jam trying to get home. This is not scalable and not sustainable. If you see a job ad that asks for rockstars, run away. Their management are fools and they are busing building a complex mess that will destroy their business.
>This is like telling Chefs they should not use pointed and sharp knives as they are dangerous in the wrong hands.
How is it like that at all? It is telling people to use a tool that does the job better. If you don't believe the tool is better then that is certainly a debate you could start. But making bad analogies doesn't seem to be a good way to do that.
I think it makes perfectly good sense. You gain a lot of fine tuned control with some of these languages that, without care and thoughtfulness, can lead to bugs.
It would only make sense if some languages were dangerous but allowed you to do your job, and others were safe but did not allow you to do you job. That is not the case. If we really need a bad analogy to be able to discuss our profession, it is more like telling chefs to stop using knives coated in grease, and start using knives with good grips.
Which is why I suggested we not use terrible analogies as though we are incapable of speaking about our profession directly. My point was that if you insist on using a bad analogy, it has to at least parallel the situation you are analogizing. Pretending "everything but haskell" is a sharp knife and using haskell is some unspecified thing that isn't a sharp knife is just plain ridiculous. General purpose programming languages are all general purpose programming languages, you can't just arbitrarily split one off because you don't like it.
What it's like is telling everybody who does any cutting at all that they're doing it wrong because they're not using a sawzall. You are wasting time, and your clients money, by doing your cutting any other way!
But I'm a sushi chef. And my friend here is a child working on a cutting-and-sticking project.
Never mind that! The sawzall would cut 90% quicker and the blade would last five times longer!
No, it isn't like that. At all. It isn't even remotely close. Making bad analogies is not productive. It is like someone saying "haskell is safer than python, but just as productive, you should give it a try". So lets discuss that, instead of bizarre kitchen powertool fantasies.
I very much enjoy coding in Haskell, and would definitely say that it changes the way I think about code. In particular, it's taught me that strong static typing, no null references, and avoiding side-effects wherever possible are all great things and IMO, those who don't use these are doing themselves a disservice most of the time. I also think that type classes are an excellent way to handle polymorphism, really quite beautiful. Immutable data is also (in many cases) a great thing. And the syntax is gorgeous.
However, I hate articles like this; they really don't help their cause, they sound driven as much by ideology as anything else, and in this case, there's even a financial motivation. It plays into the stereotype that Haskellers tend to find their language superior to any other, almost by definition. For example, many the benefits that the article touts would also be found in dialects of ML, or in Scala. However, many Haskellers I've talked to poo-poo these other languages because "they're not pure," or some other vague criticism. I don't mean to generalize, of course; many Haskellers probably embrace other languages as well, but it's certainly not uncommon.
Furthermore, Haskell is not at all without its warts: aside from its steep learning curve, it has package management issues and spotty documentation. Moreover because of its bizarre IO system (which mostly seems to exist for academic reasons, not for any practical purpose -- there are other, easier ways to disallow IO outside of sanctioned functions), it demands the use of Monads everywhere, and generally insists on a particular style which can be very restrictive. Last but certainly not least, its default laziness (once again, done mostly for academic reasons) can lead to bizarre performance issues, bugs which are hard to debug. The amount of hoops to be jumped through to accommodate laziness in Haskell is significant, to say the least.
Haskell has a number of great things in it. Functional programming on the whole is a blast to write and leads to very stable, readable code. But Haskell is far from the only answer. That said, it is a lot of fun to write, and its recent upswing in popularity is a very good thing, IMO, aside from the often pretentiousness of its users. At the least, it's raising the profile of functional languages in general, and opening the door for new languages which take the good parts from Haskell and leave behind the not-so-good.
>It plays into the stereotype that Haskellers tend to find their language superior to any other
So does everyone else. Ruby users don't advocate for ruby because they think ruby sucks. Replace ruby with any other language and the statement holds true.
>it has package management issues
No more so than other languages.
>Moreover because of its bizarre IO system (which mostly seems to exist for academic reasons, not for any practical purpose
What on earth are you talking about? Why is it that everyone I see posting "I totally like haskell but..." on HN displays a very basic ignorance of haskell? What is bizarre about the "IO system" in haskell? The fact that IO actions have a type? That is entirely for practical purposes.
>it demands the use of Monads everywhere
It most certainly does not. People use monads frequently because they are incredibly useful. You do not need to know what a monad is or how it works to use one.
>Last but certainly not least, its default laziness (once again, done mostly for academic reasons) can lead to bizarre performance issues, bugs which are hard to debug
The only criticism in your list that is actually loosely based on reality, and you still managed to get pretty far off-base. Haskell is not lazy for "academic reasons" (what does that even mean? Do you think they hand out phds for making a language "acadamic-y" enough or something?). Laziness was a choice, just as strictness is. It has pros and cons, just as strictness does. Being unfamiliar with laziness does not make laziness bad. For 90% of code, it doesn't matter. For 10%, you want to ensure strict or lazy evaluation. Regardless of which one is the default in your language, you want the other to be an easy to use option. This is the case in haskell.
>The amount of hoops to be jumped through to accommodate laziness in Haskell is significant, to say the least.
I have ~100k lines of haskell code in production. I have never even thought about having to "accommodate" laziness in any of that code. I have exploited laziness in a couple of spots as a free optimization, but otherwise it didn't even come up.
So does everyone else. Ruby users don't advocate for ruby because they think ruby sucks. Replace ruby with any other language and the statement holds true.
I think thinkpad20 is referring to the notion of Haskellers as similar to the idea of Smug Lisp Weenies [1]. Justified or not, it's a perception that has been built up around the language and its users. Unfortunately, perception is important. D came up earlier today, does anyone else recall its terrible reception on /. from about 10 years back when it's creator was pushing for it there?
Sure, and I agree lisp, clojure, ml, haskell, etc get that reputation more than others. I am just pointing out that they get that reputation by doing the same thing everyone else does, so it isn't really a valid criticism.
As a cultural note, PHP users don't claim that using other languages makes one's programs inherently dangerous. Or that using their language makes the programs bug-free. etc. (as we see in headlines of blog posts linked here.) One does not come in for scolding and condescension by PHP programmers merely for using other languages.
Whatever the faults of PHP might be, PHP programmers are distinctly more pleasant in this respect. And actually the same is largely true of Lisp, which emphasizes things like homoiconicity and expressiveness but doesn't make the actually absurd claim that it eliminates bugs or is the only way anyone should write code.
Really there aren't any other languages which can compare with Haskell in regard to the aggressiveness of their advocacy.
It's cooled down by now, but I recall far more aggressive advocacy for Python even just a few years ago. Everyone was pushing it as the best language ever and a healthy breath of fresh air from whatever else they happen to be using. After all, all those other languages are not Pythonic! Of course, look where that got them.
PHP users do not talk about other languages as being inherently dangerous because they simply do not have a leg to stand on. They're perfectly happy talking about how all other languages are impossible to set up and completely impractical for beginner web programmers though--just look at any recent PHP thread on HN. They essentially push PHP as a language for "Joe the plumber", which I personally find rather more condescending.
And, before my time, OOP was getting pushed far harder than functional programming is now. I've read plenty of old articles and whole books about how OOP (in its C++ or Java guide) is essentially the second coming, here to liberate you from your horrible procedural C/Perl ways. Hell, design patters practically became a religion with the gang of four as its prophet. Good times. But hey, with all that crazy proselytization, there's no way that cult or Java would ever catch on, happily.
Don't even get me started about Go, the language whose designers dismiss practically every recent PL advancement as academic nonsense and have reinvented a bunch of wheels. And yet it's "just in a league of its own for concurrency", to quote a recent HN post.
I'm not a big fan of condescension and being spoken to like a half-wit. I'm sure you're much smarter than me. You've certainly demonstrated all of my favorite characteristics of Haskellers. Like I said, I love Haskell, have written a good amount of it, and am excited to keep learning more. Unfortunately, one of the big downsides of Haskell is having to learn it from people like you.
I was not condescending nor did I speak to you like a half-wit. Unfortunately it is quite difficult to call someone out on making statements that demonstrate ignorance without causing offense. Haskell has many problems, but the things you listed are misconceptions and misunderstands spread around by people who have heard about haskell but not used it. I'd certainly like it if you are able to be more specific about what you think the "weird IO system" problem is.
In some sense, it is condescending to insist that you were not. You may be certain that was not your intent, but you can't really know how your words come across.
How about that what? I don't understand why you are posting a completely obvious and completely irrelevant statement, nor what you are trying to ask me about that non-sequitur.
If the advantages of using Haskell (or any other language) are so clear cut, wouldn't the market automatically switch to Haskell?
Clearly the fact that the most of software is not written in Haskell shows that Haskell is not the silver bullet for all software development as this article and other FP pundits claim it to be.
If the advantages of using Haskell (or any other language) are so clear cut, wouldn't the market automatically switch to Haskell?
That's a specious argument, you're assuming that "the market" is infallible, which is far from evident. I'm not going to say that Haskell is great for all or even half of all applications out there, but market acceptance is not a valid argument against it.
The idea that Python is a low-level language and that this is why software costs money to maintain is stupid. There isn't a better word to describe this. It's just stupid nonsense.
Can someone address the actual usefulness/fit of Haskell as a general purpose programming language for development of complex systems?
Most of my career (roughly 30 years), I've been a Unix server-side engineer, writing code in C and C++ with a smattering of Java every now and then. With my latest job, I've picked up Ruby, Javascript (including Node.js) and Go. Of the three, I tend to prefer Ruby for small utility code and Go for serious server code.
In addition to the relatively clean syntax of these languages (and Go's awesome concurrency paradigm), one of the things I really like about the modern crop of languages is the library and 3rd-party support. Need to talk to mysql? There's a gem/package/module for that. Redis? Same. Pubnub? Same. Stuff like http is baked into the standard libraries. Need to implement a high-performance logging subsystem with file rotation based on age or size? These languages all provide library access to the necessary OS fundamentals to do that. In short, I haven't found very many problems that I could solve in C++ that I can't in Ruby or Go (or probably in Node). And with a lot less effort and (at least in Go or Node) at close to the same performance.
I hear the whole "functional programming is better" pitch, and I have very limited knowledge/experience in that area. What negatives does a paradigm shift from "imperative" to "functional" programming introduce? Are there some classes of problems that aren't appropriate for a language like Haskell? Are there real-world examples of high-traffic services where the entire backend is built in Haskell?
Most of what you describe applies to haskell just as it does to everything else. It is a general purpose programming language. If you want to see what packages are available look here: http://hackage.haskell.org/ Yes, simple http support is in the standard library, more full featured http libs are on hackage.
As for the functional programming question: I haven't found any negatives. I went from imperative programming to ocaml specifically because I thought the whole functional programming thing was just hype and wouldn't really be suitable for everything, so I wanted to be able to fall back on imperative and OO styles as needed. After a few years of never needing to fall back, I decided to take a closer look at haskell.
The places haskell isn't ideal are basically the same as other high level languages. If you are doing bit twiddling or need precise control over how data is laid out in memory, you pretty much want C. I also still use shell scripts for little sysadmin stuff. Other than that I pretty much do everything in haskell now: web development, random utilities that are bigger than I want a shell script to be, network services, etc.
43 comments
[ 4.0 ms ] story [ 94.0 ms ] threadAs far as the supply of programmers is concerned, if a software developer is TRULY talented, then they will be able to learn a new language in a couple of days, and learn a new paradigm (such as functional programming) in a couple of weeks. I say this as a person who has moved from imperative programming to object-oriented programming to functional programming over my career. And I have used so many languages that I have difficulty even enumerating all of them. They range from machine language, to various assembly languages to FORTRAN, COBOL, C, Visual BASIC, Java, Python, Ruby, Scala. The hard part of programming is not the coding. It is the DESIGNING. If you do the design part well, then the code flows from your fingers naturally, and you end up doing very little debugging, especially if you practice TDD which forces you to debug problems within 15 minutes of creating them.
My opinion rarely resonates with HN because HN is full of programmers who are well into the top 5% of programmers. The last thing any of those fine folks want to hear is anything bad about their favorite language, be it Lisp or Haskell or Clojure or $SOME_OTHER_LANGUAGE_IM_TOO_DUMB_TO_USE.
I'm the dumbest guy on our programming team. I'm also the lead. My main service to the company is to try and keep the code base debuggable. I do that by limiting clever things as much as I can.
Haskell strikes me as very clever. It's sold as if it will produce less buggy code; I've not seen real world evidence that that is so and I highly doubt it is impossible to write bad Fortran in Haskell.
So perhaps the reason that Haskell hasn't taken over the world is that it seems to be something that "smart" people like and more average people don't understand. Any business that doesn't worry about how they are going to support their products (and hence their source base) down the road isn't going to survive very long. The rockstar leaves and everyone else starts rewriting his code.
This story is as old as the hills, it's been the same way ever since there have been programmers. A really great programmer can get the job done in any language and a true rockstar will write code that even I could understand.
It is not. You should check it out some time. For purposes of this post I will pretend haskell and ghc are one in the same (ghc is the most popular haskell compiler). Haskell is built around a very simple, straightforward core language (shockingly enough called "core"). There is massive resistance to adding anything to haskell that can not be expressed in core and would require changing it. Haskell values simple, powerful abstractions that can be widely re-used. Haskell has not taken over the world because it doesn't want to. Python has not taken over the world either, I doubt many people would claim it is because python is too hard or too complex. Taking over the world does not appear to have any correlation with being a good language.
A lot of what HN perceives as good I perceive as a problem that I will be left to solve.
I'm old, I'm over 50, got kids, spend a fair amount of my pile of ability each week trying to coach those kids in hockey.
Still working on the company, still trying to make money, still trying to keep it going. Every time someone shows up with something like Haskell I either beat it out of them or I fire them.
I'm sorry but I don't have the energy to deal with your new cool language. I've got a company to keep going, a life to live, I just want to take care of our customers and do it in a way that the next guy can understand and support.
Haskell might be God's gift to programming, I don't care. My job has nothing to do with making people like you happy. I've got customers I need to take care of, Haskell doesn't help. I've got employees I need to take care of, Haskell doesn't help (we are weird in that we've been around for 15 years and most of my guys are still here, we're all getting old and when you get old all that clever shit starts to look like stuff you can't support).
We recently added some pretty complex stuff to BitKeeper, basically a file system and a VM system. For a frigging source management system. In user space. Life is hard enough in C, you want to toss Haskell into that mix? Really? Come interview with us and you'll run screaming from Haskell and everything like it.
If you don't care about new technology and would rather focus on your owns hockey, that is fine, but please don't go on the attack(1). It demotivates people who want to innovate with new "clever shit"
1. It was not a direct attack, but I would consider making a point against something then purposely ignoring an experts defense in at least the same category
However, in software, we let rockstars create a big mess, and then over the next few years we spend many man-years of effort into maintaining that software, fixing bugs, attempting to shoehorn new features into a system that is rigid, inflexible and even fragile. This is what rockstars bring us, momentary euphoria until the concert is over and we are stuck in a traffic jam trying to get home. This is not scalable and not sustainable. If you see a job ad that asks for rockstars, run away. Their management are fools and they are busing building a complex mess that will destroy their business.
This is like telling Chefs they should not use pointed and sharp knives as they are dangerous in the wrong hands.
We use Haskell when we need it. Useful for some works, totally inappropriate for others.
How is it like that at all? It is telling people to use a tool that does the job better. If you don't believe the tool is better then that is certainly a debate you could start. But making bad analogies doesn't seem to be a good way to do that.
But I'm a sushi chef. And my friend here is a child working on a cutting-and-sticking project.
Never mind that! The sawzall would cut 90% quicker and the blade would last five times longer!
This argument is not going to end well.
However, I hate articles like this; they really don't help their cause, they sound driven as much by ideology as anything else, and in this case, there's even a financial motivation. It plays into the stereotype that Haskellers tend to find their language superior to any other, almost by definition. For example, many the benefits that the article touts would also be found in dialects of ML, or in Scala. However, many Haskellers I've talked to poo-poo these other languages because "they're not pure," or some other vague criticism. I don't mean to generalize, of course; many Haskellers probably embrace other languages as well, but it's certainly not uncommon.
Furthermore, Haskell is not at all without its warts: aside from its steep learning curve, it has package management issues and spotty documentation. Moreover because of its bizarre IO system (which mostly seems to exist for academic reasons, not for any practical purpose -- there are other, easier ways to disallow IO outside of sanctioned functions), it demands the use of Monads everywhere, and generally insists on a particular style which can be very restrictive. Last but certainly not least, its default laziness (once again, done mostly for academic reasons) can lead to bizarre performance issues, bugs which are hard to debug. The amount of hoops to be jumped through to accommodate laziness in Haskell is significant, to say the least.
Haskell has a number of great things in it. Functional programming on the whole is a blast to write and leads to very stable, readable code. But Haskell is far from the only answer. That said, it is a lot of fun to write, and its recent upswing in popularity is a very good thing, IMO, aside from the often pretentiousness of its users. At the least, it's raising the profile of functional languages in general, and opening the door for new languages which take the good parts from Haskell and leave behind the not-so-good.
So does everyone else. Ruby users don't advocate for ruby because they think ruby sucks. Replace ruby with any other language and the statement holds true.
>it has package management issues
No more so than other languages.
>Moreover because of its bizarre IO system (which mostly seems to exist for academic reasons, not for any practical purpose
What on earth are you talking about? Why is it that everyone I see posting "I totally like haskell but..." on HN displays a very basic ignorance of haskell? What is bizarre about the "IO system" in haskell? The fact that IO actions have a type? That is entirely for practical purposes.
>it demands the use of Monads everywhere
It most certainly does not. People use monads frequently because they are incredibly useful. You do not need to know what a monad is or how it works to use one.
>Last but certainly not least, its default laziness (once again, done mostly for academic reasons) can lead to bizarre performance issues, bugs which are hard to debug
The only criticism in your list that is actually loosely based on reality, and you still managed to get pretty far off-base. Haskell is not lazy for "academic reasons" (what does that even mean? Do you think they hand out phds for making a language "acadamic-y" enough or something?). Laziness was a choice, just as strictness is. It has pros and cons, just as strictness does. Being unfamiliar with laziness does not make laziness bad. For 90% of code, it doesn't matter. For 10%, you want to ensure strict or lazy evaluation. Regardless of which one is the default in your language, you want the other to be an easy to use option. This is the case in haskell.
>The amount of hoops to be jumped through to accommodate laziness in Haskell is significant, to say the least.
I have ~100k lines of haskell code in production. I have never even thought about having to "accommodate" laziness in any of that code. I have exploited laziness in a couple of spots as a free optimization, but otherwise it didn't even come up.
I think thinkpad20 is referring to the notion of Haskellers as similar to the idea of Smug Lisp Weenies [1]. Justified or not, it's a perception that has been built up around the language and its users. Unfortunately, perception is important. D came up earlier today, does anyone else recall its terrible reception on /. from about 10 years back when it's creator was pushing for it there?
[1] http://c2.com/cgi/wiki?SmugLispWeenie
Whatever the faults of PHP might be, PHP programmers are distinctly more pleasant in this respect. And actually the same is largely true of Lisp, which emphasizes things like homoiconicity and expressiveness but doesn't make the actually absurd claim that it eliminates bugs or is the only way anyone should write code.
Really there aren't any other languages which can compare with Haskell in regard to the aggressiveness of their advocacy.
PHP users do not talk about other languages as being inherently dangerous because they simply do not have a leg to stand on. They're perfectly happy talking about how all other languages are impossible to set up and completely impractical for beginner web programmers though--just look at any recent PHP thread on HN. They essentially push PHP as a language for "Joe the plumber", which I personally find rather more condescending.
And, before my time, OOP was getting pushed far harder than functional programming is now. I've read plenty of old articles and whole books about how OOP (in its C++ or Java guide) is essentially the second coming, here to liberate you from your horrible procedural C/Perl ways. Hell, design patters practically became a religion with the gang of four as its prophet. Good times. But hey, with all that crazy proselytization, there's no way that cult or Java would ever catch on, happily.
Don't even get me started about Go, the language whose designers dismiss practically every recent PL advancement as academic nonsense and have reinvented a bunch of wheels. And yet it's "just in a league of its own for concurrency", to quote a recent HN post.
But yes, Haskell is unique in this regard.
"People use conventional programming languages frequently because they are incredibly useful." How about that?
Clearly the fact that the most of software is not written in Haskell shows that Haskell is not the silver bullet for all software development as this article and other FP pundits claim it to be.
That's a specious argument, you're assuming that "the market" is infallible, which is far from evident. I'm not going to say that Haskell is great for all or even half of all applications out there, but market acceptance is not a valid argument against it.
Most of my career (roughly 30 years), I've been a Unix server-side engineer, writing code in C and C++ with a smattering of Java every now and then. With my latest job, I've picked up Ruby, Javascript (including Node.js) and Go. Of the three, I tend to prefer Ruby for small utility code and Go for serious server code.
In addition to the relatively clean syntax of these languages (and Go's awesome concurrency paradigm), one of the things I really like about the modern crop of languages is the library and 3rd-party support. Need to talk to mysql? There's a gem/package/module for that. Redis? Same. Pubnub? Same. Stuff like http is baked into the standard libraries. Need to implement a high-performance logging subsystem with file rotation based on age or size? These languages all provide library access to the necessary OS fundamentals to do that. In short, I haven't found very many problems that I could solve in C++ that I can't in Ruby or Go (or probably in Node). And with a lot less effort and (at least in Go or Node) at close to the same performance.
I hear the whole "functional programming is better" pitch, and I have very limited knowledge/experience in that area. What negatives does a paradigm shift from "imperative" to "functional" programming introduce? Are there some classes of problems that aren't appropriate for a language like Haskell? Are there real-world examples of high-traffic services where the entire backend is built in Haskell?
As for the functional programming question: I haven't found any negatives. I went from imperative programming to ocaml specifically because I thought the whole functional programming thing was just hype and wouldn't really be suitable for everything, so I wanted to be able to fall back on imperative and OO styles as needed. After a few years of never needing to fall back, I decided to take a closer look at haskell.
The places haskell isn't ideal are basically the same as other high level languages. If you are doing bit twiddling or need precise control over how data is laid out in memory, you pretty much want C. I also still use shell scripts for little sysadmin stuff. Other than that I pretty much do everything in haskell now: web development, random utilities that are bigger than I want a shell script to be, network services, etc.