"Hiring Haskell developers is not hard", it's already hard to get good Java developer can't imagine for Haskell...
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.
Mind sharing names?
https://twitter.com/donsbot -- author of Real World Haskell
See https://wiki.haskell.org/Haskell_in_industry for more.
Several other financial names including Bank of America Merril Lynch, Barclays Capital, Capital IQ, Credit Suisse, Tsuru Capital are listed.
Their anti-spam group definitely uses it
https://code.facebook.com/posts/745068642270222/fighting-spa...
I'm sure there are others too.
[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.
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.
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.
As a simple example, even dropouts probably know Java.
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.
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.
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.
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"?
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.
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.
This is more than two tweets long. How is it supposed to become the viral quote it deserves to be?
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.
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)
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.
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.
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.
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.
With Haskell, well, that's probably a lot less of a problem, for now.
If you are able to pay people what they are worth, I can't imagine how easy you'd have it.
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.
Knowing a less-commonly-used language like Haskell could be a fairly good indicator for this quality.
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.
What in the world about js8's post, which said (https://news.ycombinator.com/item?id=11895156):
> 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)?
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.
https://www.quora.com/Functional-Programming-Which-of-Haskel...
Yi is nice. There is also Leksah which looks even more appealing.
http://leksah.org/images/Bildschirmfoto-leksah-13-linux.png
I just wonder why are there are so few practical applications if Haskell is so practical and "simple".
Turing machines can do all computable things. They are the most simple computers yet they are not practical at all.
> You can have a more complicated thing being more practical simply because there is a better tooling or ecosystem
The point I am making is that after 25 years of age "simple" Haskell should have be a better ecosystem than Java.
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.)
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.
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.
try{
Well, obviously, you're making them write Java.
}catch(CheekyJokeException e){
// todo
}
Sub WriteGoodJava
On Error Resume Next
While True
'todo: write something
End While
End SubYes, after looking at code that reads
int i = (STDIN);
$i = <STDIN>;
For all C's faults, I still miss the simplicity of "FILE (star)", created by either "fopen()" or "popen()"
Not that I would have wrote that... :-)