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.).
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 happened to work at said company (IMVU) too, and wrote a lot of Haskell (after the codebase was established), and I think it's not fair to say "it didn't work". It also wasn't a smashing success. There were definitely advantages and disadvantages. Ultimately, as technical director, I supported Haskell, because I felt the advantages outweighed the disadvantages. I now work at Dropbox, which uses Go for the same purpose instead of Haskell, and I regularly miss being able to, you know, just map across an array.
Advantages of Haskell: unit tests were 100% reliable. Performance was amazing compared to PHP. The number of accidental regressions was very low compared to PHP. Yesod's typed HTTP router was super awesome. The ability to easily parallelize IO was a big deal for reducing latency.
Disadvantages: there was a great deal of internal resistance to learning Haskell. I never managed to separate the resistance to the language itself vs. resistance to a parallel stack, but PHP was really not pulling its weight, so I'm not sure if, say, Go or Java would have had the same level of internal drama or not. Haskell Strings are stupid. We had to write our own high-performance JSON encoder to achieve <50ms service response times ( https://chadaustin.me/2015/02/buffer-builder/ ) on large JSON responses, like news feeds.
So, I love Haskell, and were I writing a new backend for a new company with people that I know would be productive in it, I'd definitely choose it again. But it's not something to be taken on lightly. Even though I was not the original Haskell advocate at IMVU, I did end up supporting it and did what I could to teach it to others.
It was surprisingly easy to teach to people. I remember showing a new engineer who'd never seen any Haskell before monads on a whiteboard and he after I explained monoids and functors and then monads, he just nodded and said "oh, okay, makes sense". He wasn't bluffing - he actually internalized the concept that quickly. The trick with teaching Haskell is to start with specifics and THEN generalize the ideas. "So, you know how you can concatenate lists? And if you concatenate a list with an empty list it stays the same? Well, those properties are true for lots of things, and those things are called monoids."
Sorry, I rambled a bit, but tl;dr: Haskell was a mixed success, brought along some drama, but overall enabled us to reduce the latency of some critical services by about 10x. At least while I was at IMVU, teaching people Haskell was actually not hard. Getting them to care about Haskell or even want to try it was sometimes VERY hard, depending on the person.
Oh yeah, and I 100% agree with slezakattack that Haskell programmers are not necessarily magical systems designers or system programmers. They're just like you and me. Some are better at some things than others. Many of my favorite Haskell libraries were written by people who came from high-performance programming in imperative languages but fell in love with Haskell's safety. Their libraries tend to have nice, safe APIs while not sacrificing performance. :)
I remember showing a new engineer who'd never seen
any Haskell before monads on a whiteboard and he
after I explained monoids and functors and then monads,
he just nodded and said "oh, okay, makes sense".
He wasn't bluffing - he actually internalized the concept
that quickly.
This is amazing.
The trick with teaching Haskell is to start with specifics
and THEN generalize the ideas.
Definitely!
Sorry, I rambled a bit, but tl;dr: Haskell was a mixed
success, brought along some drama, but overall enabled
us to reduce the latency of some critical services by
about 10x. At least while I was at IMVU, teaching people
Haskell was actually not hard. Getting them to care
about Haskell or even want to try it was sometimes VERY
hard, depending on the person.
Please, please, PLEASE turn this into a blog post. Haskell has a lot of great testimonials, but they can't be convincing unless they also show the downsides. For technical topics I think Haskellers do a great job being honest, eg: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md ("Numerical -- immature ... Front End ... immature ... Distributed programming ... immature"). But there aren't a lot of writeups of Haskell being tried in business with mixed results. A writeup saying "a big concern is getting developers onboard" would be hugely reassuring to companies considering Haskell that _do_ have their developers onboard.
Oh yeah, and I 100% agree with slezakattack that Haskell
programmers are not necessarily magical systems designers
or system programmers. They're just like you and me.
Totally. There are some geniuses, but then there are also people like me who use it because my brain isn't big enough to hold a whole program in my head, so I need the types:)
> It was surprisingly easy to teach to people. I remember showing a new engineer who'd never seen any Haskell before monads on a whiteboard and he after I explained monoids and functors and then monads, he just nodded and said "oh, okay, makes sense".
You will be happy to know that we now removed profiling from production builds, age our Haskell is now 12x faster than the PHP instead of "only" 6x faster :-)
I agree that any new technology introduced into an enterprise requires significant investment in training, which can be hard to justify for a startup chasing product market fit.
> 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),
This was a couple years ago when I was starting off with Haskell and was not intimately involved with what was happening. IIRC it was something to do with opening too many file descriptors on /dev/urandom. I think it was linked with one of the random libs. That's all I can remember.
I remember that. One of the crypto libraries was implemented by using unsafePerformIO to access a global handle to /dev/urandom rather than accepting another parameter.
For what it's worth, this bug was an outlier. The pitfalls of unsafePerformIO are relatively well-known.
For contrast, there a bug in PHP's opcode cache that causes memory corruption in our setup. The best we've managed to do to deal with that by patching PHP to bump the refcount of some object to a billion. The failure condition is sufficiently obscure that it took us multiple man-months to figure that much out.
> defining requirements, shipping a product on time, understand tradeoffs
You could say that Haskell itself is only good at the first of these.
And: that it's common for a Haskell dev to not be good at the first, leads to deeper questions about Haskell's reason for existence at all in industry.
No, I think you could say that Haskell allows you to be good at the first. Working with stakeholders to help define requirements is not a skill you pick up with functional programming. In fact, my comment you're quoting really isn't dependent on what language you are using. It's more or less just a correlation about the haskell devs that were hired. Was trying to point out that finding people who learned haskell on their own time aren't always a good fit.
> Working with stakeholders to help define requirements is not a skill you pick up with functional programming
I'd go as far as to say it's not a skill you pick with any programming language, paradigm or technology. It's an important skill which happens to be orthogonal to the technology you're using.
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.
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.
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.
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.
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.
I was in a similar boat. I found that it's relatively easy to get machine learning jobs at market pay in Scala, due to Spark etc. taking off, and functional Scala is about 80% as good as Haskell (whereas e.g. Python is about 20%). For example, the company I'm working at, Euclid Analytics, uses Scala as our primary language.
About half of companies using Scala are only doing so because it is a trendy way to trick people into continuing to maintain god-awful legacy Java (basically same for Clojure too) -- and in these places they code Scala like it is Java, e.g. use mutability everywhere, poor code style, no emphasis on functional patterns.
The other half seem like legit and interesting jobs, but they tend not to believe that self-taught Haskell experience, or on-the-job machine learning experience with say Python (even with pyspark) is translatable to Scala, and they heavily emphasize seeking people who are specifically experienced in exactly their tech stack already and immersed in the culture of it.
Either way it creates barriers that make it seem like my quality of life wouldn't be very good switching to Scala. But if I found a company that valued what I already can do with Python and my statistics experience, and was happy partially training me / helping me while I teach myself idiomatic Scala, that would be great. It just seems impossible to find that, even though some companies pay lip service to that idea.
If you're in/willing to relocate to San Francisco, feel free to message me–I definitely can relate to your experience about dramatically different Scala cultures, and could recommend some companies that will likely value your experience while being willing to train you in Functional Scala (including my current employer, where I lead a Scala study group.)
I appreciate that -- unfortunately I am focusing mostly on the Eastern US for family reasons and I doubt SF would work out for me. Glad to hear there are some good Scala companies out there though.
Nice article. Although at some points I disagree with the author.
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.
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.
However, true is that some libraries lack _any_ documentation and it seems you should be grateful to have the typesignatures.
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.
1. People who learn Haskell put in a lot of effort for their own learning benefit - they're not usually learning Haskell to get a job.
2. Once you learn Haskell you really kind of want a Haskell job to put all this nice stuff into practice.
3. There aren't many Haskell jobs about (in part due to a perception that it's hard to hire Haskell developers).
As a company in the lucky position of hiring for a Haskell role you have a pool of people who have self selected to be above average in determination and smarts, but limited options in employment in their new tech of choice.
source Built a Haskell team at a startup, now work on a Haskell team in finance. Hiring has NEVER been a problem.
> 2. Once you learn Haskell you really kind of want a Haskell job to put all this nice stuff into practice.
Personally, not really.
I enjoy dabbling with Haskell on my open source projects but doing so has made it abundantly clear why I would never want to use it on a production system, especially one I'm responsible for. Laziness making performance intractable, bad tooling (see the stack trace observation above), difficulties hiring Haskell programmers and the fact that while they can be good coders, they are usually very weak on the engineering side, etc...
Both Haskell and Scala are on my list of languages that I love to experiment with on my free time but that I think are not ready for mission critical stuff.
> you have a pool of people who have self selected to be above average in determination and smarts
I hear this claim a lot from Haskell programmers but this has zero evidence.
It's just a human thing to believe that your choices of technology make you better than people who made different choices.
> Both Haskell and Scala are on my list of languages that I love to experiment with on my free time but that I think are not ready for mission critical stuff
I find this curious, since both languages have been successfully used for mission critical stuff, and in particular Scala is deployed for mission-critical enterprise applications. At my day job, for example, but this is starting to look even more common, judging by the recruitment emails I get.
I am curious what makes Scala in your opinion enterprise unready? It is the same JVM in the end and learning curve for a Java programmer is not that high.
Agreed - we're a Haskell-based startup in London and have been utterly impressed at the developers we've met - not just in terms of their programming ability but also as engineers who are able to contribute as a team and work with us to build product according to specs/deadlines.
"Putting all this nice stuff into practice" is the kicker. I'd really like to do FP work, but I'm not willing to leave my current employer to do it. I think there's basically a skunk works deal of Haskell at Facebook, and F# for n programmers where n is basically unknown externally... and that's it. Am I missing someone that's a) in Silicon Valley b) mature enough that the benefits are there (such as always being paid on time, good health insurance etc etc)
Verizon Labs is scala, and (mostly) on the extreme functional side (heavy Scalaz). Scala/FP experience not required, but a willingness to learn is. Ping me if you want to chat more.
> As a company in the lucky position of hiring for a Haskell role you have a pool of people who have self selected to be above average in determination and smarts
[citation needed]
There's really no evidence that people choosing Haskell are any smarter or more determined than anybody else.
I'm mainly pointing this out because the Haskell community's "We're smarter than everybody" attitude is a big pet peeve of mine.
I agree with your critique about the community attitude, so I sympathize with your position. However, speaking as a non-Haskell learner with a Haskell writing friend, I don't think it's fair to dismiss the notion entirely.
Haskell is pure functional programming, and it's structure actively discourages a lot of the more common practices in iterative languages. I watched my friend struggle with a very simple web project for weeks while he was learning the language. At the end of it all though, when it finally came together and worked for the first time, he was confident about its behavior in a way I'm not sure I ever could be with the code I write regularly. (I'm a game programmer, so I write a lot of C++ and dabble in Python and Lua.)
I think there's something to be said for the journey that Haskell necessarily takes you on. I don't think the upper skill ceiling for good Haskell developers is any higher than other languages, but the barrier for entry certainly seems to be.
> I agree with your critique about the community attitude
Please link to concrete examples of this. I'm genuinely interested in calling people out on such rudeness. The Haskell community has traditionally been modest and very welcoming and I'd like to keep it that way.
I've heard this before too, and I think a big part of it comes from the fact that people writing on Haskell aren't afraid to use mathematical terminology, and that comes off a snooty to most.
Haskell is non-standard and significantly different from everything else. Even if you ignore subjective qualities of the language, it takes some amount of initiative and self-selection to pick Haskell up at all, while lots of people are funneled into languages like Java, JavaScript, C#, Python by default. For example, relatively few universities (and presumably no bootcamps!) teach it at all, while it's hard to avoid programs that strongly feature Java and Python.
More generally, it makes sense for the sort of people who make non-mainstream choices to be qualitatively different from many who do go with the mainstream.
You've never worked with..uh... cheaper developers who've been on a course and need everything explained 4 times and have no common sense and sniff a lot but who claim to be great Java/c#/JavaScript developers? Happens all the time. I'm guessing it's harder to bullshit the sort of person who handles hiring Haskell developers.
Plus, someone who's studying Haskell probably is smarter on average than the average developer (and no, I'm not a Haskell developer although it interests me)
I understand your pet peeve, really I do, but if you look at the contrapositive statement I think you will find it hard to argue:
People who are just looking to get into software engineering for the money are unlikely to learn Haskell.
They will almost certainly learn Java, PHP, Ruby, Node or maybe even Go, but not Haskell. And looking around SV these days, there is a huge number of people around that are only in it for the money.
Not that that is a panacea... my instinct is you might end up with a very strong technical team, but one that might be more likely to miss the forest for the trees when it comes to building a successful business.
There are many attempts to justify the practical use of Haskell. However why does the Haskell community not have just proven the superiority of Haskell by an impressing showcase of working equivalents of Eclipse, Open Office, full-blown browsers, 3D games, and things like that?
AFAIK there is _nothing_ comparable in the Haskell world!
I know things like Leksah and FP-Complete's online editor but these things are far from being comparable to power IDEs like Eclipse. Haskell, as it is today, is a nice language for study purposes and academic use but it is barely used in the industry. Haskell is by far not so practical as the Haskell community wants it to be.
People have no right to complain without suggesting solutions. So do I. My suggestion: The Haskell community should develop languages based on Haskell which are much more practical, and which use all the nice power features of Haskell - the purity of functional programming for instance. Haskell is too cool to be wasted for academic use. It could be a very nice backend for really practical languages. The first promising attempts are there - IDRIS for instance.
It kind of seems like you're grinding an axe that has nothing to do with my comment. But FWIW, I agree, but I also respect that Haskell is not designed to be a "successful" industry language. I'd love better tooling for it, but I also don't think it's a do-or-die kind of situation. Haskell has a fairly stable critical mass and a slow and steady upwards trajectory.
> They will almost certainly learn Java, PHP, Ruby, Node or maybe even Go, but not Haskell. And looking around SV these days, there is a huge number of people around that are only in it for the money.
I think you're confusing orthogonal issues. Only writing code because it pays the bills really says nothing about how smart or motivated a person is. Is there a rule somewhere that dumb people can't enjoy programming and learn Haskell? On the other hand I know a few very smart people who only write code because it pays their bills.
I'm not confusing anything, I just disagree with you.
It's not about smart vs dumb, it's about intrinsic versus extrinsic motivation. Being smart is an advantage, but it is meaningless without a massive amount of practice. There's nothing about programming that a 100 IQ person can't become competent at it.
Programming is first and foremost, an exercise in frustration. It is exacting and unforgiving in a way that few human activities are. It's somewhat unnatural. In order to excel at it I believe you need to feel an intrinsic thrill when solving a problem that surpasses all the frustration leading up that point, and you need to seek this out over and over and over.
Note that this says nothing about whether you only work for money, or even what brought you to the field. However, if you do not feel this thrill, then you will naturally gravitate towards a job where you can execute rote incantations again and again without having to face new problems. I'm sure there are people who love programming and persist in it despite being terrible at it, but I guarantee you they are far outnumbered by the hordes of wannabe tech millionaires flooding into the Bay Area as we speak, completely oblivious to how much they will actually hate and subsequently suck at programming—and those people ain't learning Haskell.
> Programming is first and foremost, an exercise in frustration. It is exacting and unforgiving in a way that few human activities are. It's somewhat unnatural. In order to excel at it I believe you need to feel an intrinsic thrill when solving a problem that surpasses all the frustration leading up that point, and you need to seek this out over and over and over.
This is more than two tweets long. How is it supposed to become the viral quote it deserves to be?
> Only writing code because it pays the bills really says nothing about how smart or motivated a person is.
No, but actually bothering to learn something that isn't what is being shoveled through most major outlets is at least somewhat correlated with motivation.
After further thought, it seems like having a reputation as difficult to hire for and a reputation for attracting smart people would be two very good reasons for people "only in it for money" to learn Haskell.
Not sure why you were downvoted here, I agree with you on this. The only thing is that there aren't a lot of Haskell jobs out there, and that is a far stronger signal to people looking to jump into the software industry than the nuanced opinions of industry veterans in forums like HN.
> Is there a rule somewhere that dumb people can't enjoy programming and learn Haskell?
No, there's no such rule. Can you possibly imagine that there might be any factors at play that affect the observed intelligence of Haskell programmers besides "a rule"?
> Haskell community's "We're smarter than everybody" attitude
Please link to concrete examples of this. I'm genuinely interested in calling people out on such rudeness. The Haskell community has traditionally been modest and very welcoming and I'd like to keep it that way.
The person I replied to is a Haskell developer, talking about Haskell developers. A member of the community, talking about how smart people in the community are .
Yes, he believes that the average smartness across Haskell developers is greater than the average smartness across all developers (as do I). This is a fairly weak claim. He did not make the claim "we're smarter than everybody else", which is a very strong claim. That's your strawman.
jlarocco said two things: "There's really no evidence that people choosing Haskell are any smarter or more determined than anybody else" and "I'm mainly pointing this out because the Haskell community's "We're smarter than everybody" attitude is a big pet peeve of mine."
Note the phrases "smarter than everybody" and "not smarter than anybody else". Those are not nuanced statements, but I don't think they're intended to be absolutely exclusive statements.
Or to put it another way, if you interpret "smarter than everybody" as the claim that Haskell programmers are actually the smartest programmers, then grammatically, you also have to read "not smarter than anybody else" as the claim that Haskell programmers are as dumb as the dumbest programmers in existence - which I'm pretty sure was not jlarocco's actual claim.
I think the point is that learning Haskell takes time and effort outside of standardized courses, so people who learn it are, as a percent of the population that knows the language, more determined than those who use more mainstream languages.
As a simple example, even dropouts probably know Java.
They even have their internal Haskell compiler which IIUC gets fed a dialect in order to have strict evaluation and a couple other non-standard properties. One nice thing the ecosystem got from their internal team is the official Shake implementation, which supersedes the various 3rd-party implementations and actually works really well. It even can interpret Ninja files, so it can be used in place of ninja when building things like Cmake-based projects or, say, Chromium. Not that there much of a reason to use Shake when you use Ninja, but you can and some of the reporting features might be exclusive to Shake. Usually you write a Shakefile.hs (instead of Makefile) and run it with shake.
Probably easier for Haskell: for Java (and most other broadly-recognized-as-industrially-popular languages) a lot of the problem of hiring good developers is separating the people that are self-motivated, will dig into to new challenges, and do something more than cargo cult coding from the herd.
With Haskell, well, that's probably a lot less of a problem, for now.
Looking, a year back, for some to take over a Haskell project, I received a good deal of interest from very qualified Haskellers, despite promising substantially under market rate with no prospect of later windfall (work was on a non-profit).
If you are able to pay people what they are worth, I can't imagine how easy you'd have it.
Stop hiring "Java developers" or "Erlang developers" or "Blub3.0 developers". Just hire developers who are smart enough to learn whatever language you are using.
Maybe you hire a "developer with experience in functional languages such as Haskell" if you are in a rush. But if you find yourself in a place where you need to hire very specific skills with no time to train, then you have already lost.
I actually prefer Haskell, because it is pretty simple, you have datatypes and functions and that's it.. In Java, things are more complicated, with all the different design patterns and classes and other contraptions. I think you have to be smarter to program in Java than to program in Haskell.
For a "Hello World", maybe. Developing a non-trivial Haskell app or library will require the equivalent amount of knowledge (if not more) as developing a Java app or library.
Haskell is anything but simple - which is why everyone writing a program which does efficient and safe file I/O needed to read a paper from Oleg.
Claiming that Java is complicated because it has all those "different design patterns and classes and other contraptions" and _then_ saying that Haskell is simple is simply dishonest.
Really? Fine. Then please show me a list of Haskell equivalents of Eclipse, NetBeans, Open Office, e-commerce software, and other big software which was written in Java. Thank you.
Let me answer you and it will hopefully address other replies as well.
First, your response is a straw man; there is an enormous amount of effort put into systems that are more complex than needs to be be. Mostly this is for historical and compatibility reasons (including social inertia). In case of Java, it succeeded because it was based on C++.
Also, simpler programming doesn't always translate to more runtime efficiency. Haskell programs on their own are not very efficient; potentially, yes, but IMHO at this moment efficiency shouldn't be a reason why to choose Haskell over C++ or Java.
Paradoxically, to understand how to do things in a simple way requires a lot of effort, and history seems to progress from more complicated to simpler (although there is also increase in abstraction, because that's what improves productivity).
I work in mainframes, and it's a sort of archeology that gives you a good perspective on that. A good canonical example is datasets; on z/OS, datasets have different organization (different record sizes and whatnot), unlike in Unix, where file is simply a sequence of bytes. There are many other examples from mainframes (like CKD DASD). Some of them were given by historical limitations of hardware (or also done for efficiency reasons), but mostly they are evolutionary dead ends of too much complexity.
So I really think Haskell has simpler building blocks. More abstract, more orthogonal, and so on, than Java (or most imperative languages). The point is, it's not simpler to build something with more complicated building blocks, on the contrary. There are intrinsic complications of the problem (which other reply to me alludes to), but there are also unnecessary complications arising from complicated building blocks (such as, having to deal with different ways to access files on z/OS, compared to Unix).
To conclude, I feel that the concept of Java-like "class" is a too complicated building block that tries to do too many things in one abstraction. And I see design patterns as a sort of evidence, because most of these explain how to build things from classes that are perfectly obvious when you have data types and functions.
> Really? Fine. Then please show me a list of Haskell equivalents of Eclipse, NetBeans, Open Office, e-commerce software, and other big software which was written in Java. Thank you.
> I actually prefer Haskell, because it is pretty simple, you have datatypes and functions and that's it.. In Java, things are more complicated, with all the different design patterns and classes and other contraptions. I think you have to be smarter to program in Java than to program in Haskell.
did you take to be a claim that Haskell offers equivalents of the vast Java ecosystem, or even any claim about the relative merits of the products of the languages (rather than the ease of using them to program)?
If people claim that Haskell is "pretty simple" and Java is "more complicated" then why in the world is there almost no evidence for that? Why are things like Eclipse and Netbeans availabe for many years why Haskell is still blaming itself by fighting the very basic cabal hell? I know sandboxes and Nix and all those tools which circumvent the cabal hell. But consider how the Java world would respond if Java 9 would require sandboxes or Nix to manage every software project :-)
I like Haskell, and I consider Haskell far superior (and more complicated) than Java. I also know Java pretty well. Java is far from being "more complicated" than Haskell. There is a reason why there are way more Java developers than Haskell developers. In my experience Haskell is powerful and elegant but not very practical. Practical are other languages (Rust, C++, Java, Nim, OCaml, ...). That' why Eclipse, Open Office, MS Office, operating systems, mars land projects and other big software is written in everything but Haskell.
I think there is a problem in your thinking with conflating "simple" and "practical". You can have a more complicated thing being more practical simply because there is a better tooling or ecosystem, as you correctly point out.
> What is the worth of "simple" if it is not "practical"?
I cannot speak for js8, but I think you took his or her statement of personal preferences as a statement of value. (That is, I think that the statement that he or she preferred a simple language was not the statement that it was 'worth' more in any abstract sense.) I imagine that everyone in this discussion would agree that 'simple' and 'practical' are different. I personally think that the lambda calculus is even simpler than the theory of Turing machines, and yet probably still less practical. I enjoy the theoretical beauty and austerity, and I imagine that js8 is in somewhat the same boat.
(For an extreme example of going the other direction, consider Perl, which is an eminently, even sometimes excessively, practical language, but which none among even its most ardent fans—and I am one!—would call simple.)
On the other hand, though, any developer that knows Haskell is much more likely to be a good developer. So even if the overall pool is smaller, the percentage of that pool that is qualified is probably much higher.
There are a good subset of developers wanting to work full time in any functional language, and most of them have walked through haskell at some point.
In my (limited) experience it is easier to spot bad developers in (perceived hard) niche languages so I would assume a smaller % in that already small group tries to bluff their way in. Learning Haskell, Prolog or something like Coq usually starts on an academic level and if one wants to pursue a carrier it needs to turn into a quite time consuming 'hobby' first if you do not roll into something from uni. In my experience people who are bad are not looking for a career in it while they would be in more mainstream languages (... were Stackoverflow can get you quite far anyway).
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.
Off the top of my head I've got:
pandoc - translates from one document format to another
ion - a window manager
git-annex - store stuff in git without it being in git.
If we can get to 50 useful "apt-get install"-able programs Haskell will be worth looking closely at again.
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'm not a Haskell programmer, but I wish more languages had Newtypes.
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.
I implemented a newtype [1] system in C#. It's (obviously) not as robust as Haskell (relies on some runtime checks), and isn't as efficient (reflection and boxing for value types). But if type-safety is what you want, it's definitely an improvement over passing integers, strings, or other basic types around.
Paul Graham is overrated. I believe almost every developer goes through a phase where they are enamoured by his writings, and thanfully, they grow through them when they get into the real world. Perhaps your time will come soon too.
I am honestly curious whether you think PG's opinions on Python 12 years ago also "make no sense whatsoever" and are "Purely subjective speculation at best". Speculation about my professional growth is irrelevant.
The total market cap of companies coming out of YCombinator is a pretty staggering number.
I don't say that as proof Paul Graham's writings are all true and should be accepted as gospel without question. But it's not credible to suggest Paul Graham doesn't understand "the real world" of software business.
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.