I programmed Haskell professionally for about a year and a half. My last company has been trying to hire Haskell engineers for over 2 years and we've only managed to hire at least 2. "Hiring Haskell developers is not hard", is extremely subjective and naive to say the least. Obviously, YMMV, but the front-end devs that the last company was hiring was running laps around the Haskell team. Honestly, finding a Haskell engineer is not always a winner either. I've found that the ones we hired are very smart but not very decent engineers (i.e. defining requirements, shipping a product on time, understand tradeoffs, etc.).<p>There were quite a few things about Haskell that I truly love and miss, such as the type system, but the tradeoffs just weren't worth it to me and I honestly don't think it's mature enough to be considered "enterprise ready". Aside from the learning curve, there were several bugs in one of the Haskell libraries that caused frequent outages (until we were able to pinpoint what was wrong), lazy evaluation caused excessive memory bloat when used incorrectly, and my all-time favorite: needing to switch on profiling in order to get stack traces (this is suppose to change in future GHC versions) which defeated the whole purpose of "haskell is fast". I don't know, perhaps we were using Haskell wrong. From a business perspective, it just wasn't making that much sense given how difficult it was to hire, getting engineers excited to learn it, and having the features needed to monitor a production system.
I fall in a weird bucket: very advanced understanding of some other languages and good work experience, education, etc., but even though I love Haskell and practice it all the time, I think I am just somewhere on the boundary between beginner and intermediate, and even with focused daily effort I would remain on that boundary for a long time before there is a phase transition to solid intermediate.<p>Because of this, the only kinds of FP shops that would hire me want to hire me at a junior or low-paying level, but my market value in lots of other skill areas (machine learning, Python, database stuff, etc.) is much higher, so I'm not willing to take a salary anywhere close to what they think fits the position.<p>As a result, even though I would love to get industry experience with functional programming, there is a market wage energy barrier preventing me from considering it. I was burned once early in my career with malarkey about how you should accept a lower salary for some alleged other benefit (like cool functional programming, or working with a team of awesome people, or getting in on the ground floor on something, etc.) -- I won't make that mistake again.<p>So I basically had to learn to divorce myself from real world Haskell practically just as soon as I learned how much I really love it.<p>Plus, and this should not be discounted, the professional tooling with Haskell is still extremely immature with lots of esoteric corners duct taped together in unsatisfying ways. It's getting better, but if you work with Haskell for real there are likely to be as many, if not many more, extremely frustrating painpoints of the language tooling as with any other language, enough to amortize away all the warm fuzzy happiness you'd get from the status effects of being able to say you do pure functional programming for a job.
Nice article. Although at some points I disagree with the author.<p>The part on errors is mostly "some guys use error but don't mention it". Partial functions are not nice, that's true. In some cases tools like hlint may help. Actually I'm wondering there's no tool / hackage functionality around, that flags modules / (pure) functions that are partial.<p>For documentation: Starting with Haskell I felt the same, some more examples and more documentation would be nice. But in the meantime I've come to like the concise documentation most often used. When searching for a certain function I don't want to read screenpages of text, but find that function fast. If, however, I need more detail or want to be really sure what the function does I need to read the source anyway.<p>However, true is that some libraries lack _any_ documentation and it seems you should be grateful to have the typesignatures.<p>Also, I think more libraries should have examples/ directories so one can get at quick glance how the library is designed to be used. Perhaps even have hackage emphasize the existence of these examples more.
Here is the part where I want to update my data point about how many applications I can run for doing something other than writing code where the program was written in Haskell. This data point is useful because hackers gotta hack. If there's still not much here then I'm forced to assume that haskell still has problems that aren't being talked about.<p>Off the top of my head I've got:<p>pandoc - translates from one document format to another<p>ion - a window manager<p>git-annex - store stuff in git without it being in git.<p>If we can get to 50 useful "apt-get install"-able programs Haskell will be worth looking closely at again.<p>This is not trolling, this is useful data. We know FP is fun, cool, funky and all that. It's a different discussion as to what problems remain (if any) and how to solve them (if needed). I just want to see where we're up to in mid 2016.
I totally agree with the downsides. Ban synchronous exceptions now!<p>Thank goodness everything else is library/ecosystem, rather than language, problems. I think those are easier to fix :).
I'm not a Haskell programmer, but I wish more languages had Newtypes.<p>Most of the time I'm too lazy (or consider it too much boilerplate) to wrap strings in classes. But on more than one occasion I've spent too much time tracking down a bug because I passed the wrong string to the wrong argument in a method.