6 ms·

I think there are a couple reason. Haskell is a significant departure from most other languages commonly used by industrial programmers. It's a relatively sha

I think there are a couple reason. Haskell is a significant departure from most other languages commonly used by industrial programmers. It's a relatively shallow learning curve from Java to Python to JavaScript, but making the leap to a pure functional language is very difficult. Path-dependence plays a huge part here. This isn't just a matter of "people being afraid of what's different" as the article suggests; there are very rational reasons for a profit-seeking firm to exploit the fact that their developers (and those available to hire) are already relatively proficient at writing procedural code. Another, more important reason, is that Haskell is too intellectually demanding for most industrial programmers. I consider myself an enthusiast of functional programming, but achieving anything practical using purely functional code remains extremely difficult for me, even though I regularly dabble in it during my free time. The Haskell IRC channel can be helpful, but it's very difficult to square "Haskell is easy enough for anyone to learn" with the inevitable "you are too stupid/impatient/incompetent to use Haskell effectively" taunts you're likely to hear, when you're asking for help to perform a simple task. Many Haskell evangelists don't understand that most developers aren't nearly as smart or dedicated as they are. I'd be curious to know where most Haskell users believe they lie on the distribution of programming ability. I'd estimate most of them lie at the 99% percentile, and that any of them arguing otherwise are doing so out of modesty. (Note that I'd include dedication and curiosity in with intelligence in this metric.) I believe the most likely explanation for this is that Haskell is a particularly difficult language to use effectively.

gaius 16y ago
Another, more important reason, is that Haskell is too intellectually demanding for most industrial programmers. t While that's often stated as a reason, I don't believe it myself, simply on the grounds that anyone smart enough to use C++ "in anger" is smart enough to learn any language. The reason that Haskell isn't popular (IMHO) is that a lot of programming isn't clever algorithms, it's forms (interfaces for getting data into databases) and reports (interfaces for getting data out of databases). A lot more is glue (connecting the output of one program to another). Haskell just isn't a good fit here. I am very excited by F#; here we have an ML dialect that has minimal impedance mismatch with the OO/imperative world (and C# with LINQ has minimal impedance mismatch with the declarative world of relational databases). This is where Haskell types should look for work...
- barrkel 16y ago
  I would argue that most people who use C++ in anger don't fully understand that language, and get by because they do what they know has worked before. The accumulated experience doesn't imply intelligence. That's not to say that I think that it's intelligence that's lacking with respect to Haskell etc. I think the problem there is the mode and style of thinking, and that most programmers are too old to easily pick up the different way of approaching problems that it becomes second nature. That, and functional programming's chosen compositional breakdown of fixed common data with an open-ended set of applicable functions is not always as applicable as object orientation's breakdown of open-ended data with inheritance of fixed sets of functions; you often need to introduce an extra level of indirection (=> abstraction) with functional programming to get access to the dynamism that OO gives you in the box.
- deleted 16y ago
  [deleted]
- jamii 16y ago
  > it's forms (interfaces for getting data into databases) and reports (interfaces for getting data out of databases) Well, with formlets and takusen you're pretty much sorted. http://haskell.org/haskellwiki/Formlets http://haskell.org/haskellwiki/Formlets http://blog.codersbase.com/2010/08/takusen-tutorial-part-1-hello-takusen.html http://blog.codersbase.com/2010/08/takusen-tutorial-part-1-h...
- jrockway 16y ago
  Why is Haskell not a good fit for glue? That's what I use it for, and it works great -- my programs are short, efficient, and easy to write and test. My first Haskell project for work was initially a C++ project, but it was too hard to use C++ as a glue language, so I switched to Haskell. I would have used Perl, but Haskell works better on Windows and has an easier-to-use FFI. I actually ended up spending more time trying to get some old version of Visual Studio to link against my super-old-proprietary-C-library that was the core of my project than I did writing the whole Haskell FFI binding to that library and writing the first version of the Haskell-based program. This turned out to be the most trouble-free program I ever wrote. It had to operate on large datasets, and never died in the middle (like I'm used to with Perl). The only bug that the program ever had was where one of my data validation rules was too strict, and rejected some valid date. (The validation rule said that the dates in the time series had to be increasing. But one series only had one point, and hence wasn't strictly increasing. The bug resulted in "Warning: bad data", though, not "Prelude.(!!): index too large", as the implementation was with fold.) Incidentally, as a result of this project, c2hs supports Windows DLL calling conventions :)
wisty 16y ago
achieving anything practical using purely functional code remains extremely difficult ... Excel is pretty much a functional language (though it is a little disabled), and people do amazing things in it. The problem isn't that functional languages are hard. They are a bit different, but good code is often fairly functional anyway. The problem is that most of the community seems to be obsessed with showing that functional languages are both better, and more difficult, than mere procedural languages. Take monads. The only way to "get" monads is to realize that they are just sections of the program that are imperative. But most Haskell programmers introduce them in the most incredibly obscure double-talk, just to avoid admitting that Haskell needs the ability to do imperative things in order to be useful.
- naradaellis 16y ago
  Perhaps the reason that Haskellers don't describe monads as "just sections of the program that are imperative" is because that statement is _not_ true. A monad is a very nice container abstraction - period. The IO part of Haskell just happens to leverage monads. One of the benefits of which is an explicit marking of impure methods in the type signature, but there are others. Monads are used in plenty of purely functional parts of Haskell. Disclosure: been programming Haskell for only a few months now, so someone pull me up if I'm wrong. However, I have used a lot of monads so far (and they're not hard, its just a higher, more convenient level of abstraction). edit: to address your post further. I honestly don't think that the community is the reason that Haskell isn't taking off. If you were to gather stats on the points at which would-be Haskellers give up, I think most people would leave 1) when they can't grok the syntax easily or 2) when they can't get tools or libraries going easily (it was a problem for me) and long before they get to the point of visiting the news groups and start running up against academic-type people.
  - tkahn6 16y ago
    Can you give an example of where monads are not used to interact with stateful things? That would be helpful to me.
    - 16y ago

gaius 16y ago

Another, more important reason, is that Haskell is too intellectually demanding for most industrial programmers. t While that's often stated as a reason, I don't believe it myself, simply on the grounds that anyone smart enough to use C++ "in anger" is smart enough to learn any language. The reason that Haskell isn't popular (IMHO) is that a lot of programming isn't clever algorithms, it's forms (interfaces for getting data into databases) and reports (interfaces for getting data out of databases). A lot more is glue (connecting the output of one program to another). Haskell just isn't a good fit here. I am very excited by F#; here we have an ML dialect that has minimal impedance mismatch with the OO/imperative world (and C# with LINQ has minimal impedance mismatch with the declarative world of relational databases). This is where Haskell types should look for work...

barrkel 16y ago
I would argue that most people who use C++ in anger don't fully understand that language, and get by because they do what they know has worked before. The accumulated experience doesn't imply intelligence. That's not to say that I think that it's intelligence that's lacking with respect to Haskell etc. I think the problem there is the mode and style of thinking, and that most programmers are too old to easily pick up the different way of approaching problems that it becomes second nature. That, and functional programming's chosen compositional breakdown of fixed common data with an open-ended set of applicable functions is not always as applicable as object orientation's breakdown of open-ended data with inheritance of fixed sets of functions; you often need to introduce an extra level of indirection (=> abstraction) with functional programming to get access to the dynamism that OO gives you in the box.
deleted 16y ago
[deleted]
jamii 16y ago
> it's forms (interfaces for getting data into databases) and reports (interfaces for getting data out of databases) Well, with formlets and takusen you're pretty much sorted. http://haskell.org/haskellwiki/Formlets http://haskell.org/haskellwiki/Formlets http://blog.codersbase.com/2010/08/takusen-tutorial-part-1-hello-takusen.html http://blog.codersbase.com/2010/08/takusen-tutorial-part-1-h...
jrockway 16y ago
Why is Haskell not a good fit for glue? That's what I use it for, and it works great -- my programs are short, efficient, and easy to write and test. My first Haskell project for work was initially a C++ project, but it was too hard to use C++ as a glue language, so I switched to Haskell. I would have used Perl, but Haskell works better on Windows and has an easier-to-use FFI. I actually ended up spending more time trying to get some old version of Visual Studio to link against my super-old-proprietary-C-library that was the core of my project than I did writing the whole Haskell FFI binding to that library and writing the first version of the Haskell-based program. This turned out to be the most trouble-free program I ever wrote. It had to operate on large datasets, and never died in the middle (like I'm used to with Perl). The only bug that the program ever had was where one of my data validation rules was too strict, and rejected some valid date. (The validation rule said that the dates in the time series had to be increasing. But one series only had one point, and hence wasn't strictly increasing. The bug resulted in "Warning: bad data", though, not "Prelude.(!!): index too large", as the implementation was with fold.) Incidentally, as a result of this project, c2hs supports Windows DLL calling conventions :)

wisty 16y ago

achieving anything practical using purely functional code remains extremely difficult ... Excel is pretty much a functional language (though it is a little disabled), and people do amazing things in it. The problem isn't that functional languages are hard. They are a bit different, but good code is often fairly functional anyway. The problem is that most of the community seems to be obsessed with showing that functional languages are both better, and more difficult, than mere procedural languages. Take monads. The only way to "get" monads is to realize that they are just sections of the program that are imperative. But most Haskell programmers introduce them in the most incredibly obscure double-talk, just to avoid admitting that Haskell needs the ability to do imperative things in order to be useful.

naradaellis 16y ago
Perhaps the reason that Haskellers don't describe monads as "just sections of the program that are imperative" is because that statement is _not_ true. A monad is a very nice container abstraction - period. The IO part of Haskell just happens to leverage monads. One of the benefits of which is an explicit marking of impure methods in the type signature, but there are others. Monads are used in plenty of purely functional parts of Haskell. Disclosure: been programming Haskell for only a few months now, so someone pull me up if I'm wrong. However, I have used a lot of monads so far (and they're not hard, its just a higher, more convenient level of abstraction). edit: to address your post further. I honestly don't think that the community is the reason that Haskell isn't taking off. If you were to gather stats on the points at which would-be Haskellers give up, I think most people would leave 1) when they can't grok the syntax easily or 2) when they can't get tools or libraries going easily (it was a problem for me) and long before they get to the point of visiting the news groups and start running up against academic-type people.
- tkahn6 16y ago
  Can you give an example of where monads are not used to interact with stateful things? That would be helpful to me.
  - 16y ago