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.
> 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 .
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.
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).
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.