There might be many biases in this research. If one is able to write code in Haskell it tells a lot about them, and he might be a better programmer than one who writes in Ada or C++.
To make this research unbiased we need to do the following:
* Take people who are profecient in Ada, Haskell and Ada
Seasoned and experienced Ada programmers are likely to come from a high-level (software) engineering background in some large company, e.g. in the aviation industry or military. Haskell programmers will more likely work in academia, e.g. a professor of computer science. And the C++ programmers could come from any field or industry.
These people will likely shine with certain tasks and be less productive with other tasks, depending on their varying skill sets. So you're probably only measuring the overall level of proficiency of programmers of certain languages in a particular programming domain. For example, I'd bet that the average experienced C++ programmer is slightly less skilled than the average experienced Ada programmer (if both of them are mostly working with their language professionally), simply because C++ is more widespread whereas the few Ada jobs left require a relatively high level of expertise. On the other hand, if you're writing programs in Ada for Airbus, you're probably accustomed to a slower development pace than if you write C++ code for a small gaming company, so the "productivity" will appear to be fairly low in comparison.
Then there are measures like LOC that are fairly meaningless across languages and perhaps even in general.
Finally, languages are usually chosen for their tool and library support and on the basis of available developers anyway.
"There might be many biases in this research. If one is able to write code in Haskell it tells a lot about them, and he might be a better programmer than one who writes in Ada or C++."
I'm going to bite as an Ada fan to say this is probably true to a degree since it's a high-level, functional language. Haskell similarly gets slammed in productivity by Common LISP which is high-level, less safe, has fast iterations, and good tools. However, if we're talking apples to oranges, Haskell already failed at doing the kind of low-level, efficient, and/or real-time apps that Ada was designed for vs Ada that makes it straightforward. The House operating system was a celebrated achievement and embedded use Haskell-based DSL's extracted to C for good reasons. Meanwhile, SPARK variant is allowing proof of absence of key errors without people being experts in theorem provers and with most of the efficiency of Ada vs provable ML/Haskell.
Yeah, I'd love to see a bunch of teams trying to write deterministic, safe, and fast software in each of these languages. Let's see about protocol engines, string libraries, real-time apps, high-performance on single cores, lightweight containers, provable absence of problems in component, and so on. I'm betting on Ada 2012/SPARK 2014, C++, and Haskell in that order given attempts to balance all those requirements.
I wonder if there's ever been even a single comparative programming languages study which would adhere to the standards routinely required in medical and epidemiological studies?
> which would adhere to the standards routinely required in medical and epidemiological studies?
For a long time, medical studies could change the topic of the study after the study has been completed (i.e. study was initially done to prove effectiveness for one thing, but it was discovered that it was not effective for this thing, but for another, and happened to not kill anyone, so the study was now for the other thing), so I would definitely not use the field of medicine as a example of unbiased studies.
> If one is able to write code in Haskell it tells a lot about them, and he might be a better programmer than one who writes in Ada or C++.
And here's the arrogant, self-important attitude that turned me off of Haskell.
When I was using it, I didn't see any evidence that Haskell users are any better or worse than programmers in any other language.
If it were true, why aren't Haskell developers taking over the world with their superior software?
In reality, any new, interesting language is going to attract better than average developers at first, because those developers are always learning new stuff and trying different things.
I started to learn Haskell several times and decided every time that it's not really worth effort and time spent. Technology should adapt to humans, not humans to technology. IMHO Haskell exemplifies the latter.
Haskell is quite well adapted to the humans that like using it :-)
Partially it's a matter of taste.
I hated Haskell syntax in the first few weeks ("Why did they have to differ on this?!") but later I realized it's objectively nicer for expressing the things Haskell expresses and much prefer it.
Then there's a lot of bad tutorials out there.
And finally the tooling / IDEs aren't great for discovering the language and type system.
I don't see significant ways Haskell itself could be more geared towards humans than it already is. It brings simple mathematical concepts and abstractions to the forefront - and simple is not easy, but is worth it.
> If one is able to write code in Haskell it tells a lot about them, and he might be a better programmer than one who writes in Ada or C++. - solomatov
> And here's the arrogant, self-important attitude that turned me off of Haskell. - jlarocco
> It is people frustrated by the (difficult) learning curve of Haskell that say such things. - peaker
> And there it is again. I haven't drank the Haskell kool-aid, so I must not be smart enough to use it properly.
Firstly, reading "people frustrated by the difficult learning curve of haskell say such things" as "I haven't drank the Haskell kool-aid, so I must not be smart enough to use it properly." is a very uncharitable interpretation.
Secondly, I believe solomatov and Peaker's comments could be written more unambiguously as follows (though I thought they were precise enough):
solamatov commment rewrite: Someone who can write Haskell might be a better programmer than programmers who use other languages because Haskell is difficult to learn.
peaker comment rewrite: People frustrated by the difficulty of the Haskell learning curve say things such as "Someone who managed to learn Haskell to the point they can write code in it have proven their worth more than those who use easier to learn languages"
So jlarocco, could you still call classify these comments and the thought processes behind them arrogant and self important? Is there anything that would turn you off of them?
Haskell is difficult to learn! For virtually everyone. Especially people who already learned more mainstream languages, because it is so different.
When I learned Haskell I was frustrated by its difficult learning process until I stuck with it long enough, as did almost all who passed the learning curve.
How do you get any reference to "smart enough" out of this?
"persistent enough" is definitely relevant for learning Haskell, though.
> If it were true, why aren't Haskell developers taking over the world with their superior software?
Haskell doesn't make superior software; it just (as far as I understand) allows you to make software of equivalent quality, faster. (As is true of functional languages generally; and of strongly-typed languages with type inference generally.)
Quality in all software projects sort of approaches perfection asymptotically, because nobody is all that interested in "perfect software." People just put in less and less QA effort as software "stabilizes", so the remaining bugs in a codebase (even one of static size! even bugs equally easy to find!) are found more and more slowly over time.
One could likely take a "military discipline" approach to line-by-line code reviews, and get a constant output of bugs found per man-hour; but nobody except NASA—and possibly the military itself—is ever going to bother.
---
All that being said, when people say "Haskell programmer", they're more-often-than-not referring not to anyone who codes in Haskell, but to the very specific type of person who creates Haskell libraries encoding new category-theory abstractions—which is to say, mathematicians.
Programmers who happen to also be mathematicians do write "better" software than programmers who are not mathematicians, I think. This is just because mathematicians have much broader mental libraries of abstractions available to them, where any one of those abstractions may be the key to reducing an ugly, complex solution to a simple and elegant one.
Being a mathematician doesn't force you to code in any particular language, but a lot of them happen to be drawn to Haskell when testing out constructions of new abstractions in category theory, computability theory, information theory, etc. Other Haskell programmers can then take these abstractions and—if they can understand them—reuse them in regular programs, such that those programs then become more elegant, in the same way they would be if a mathematician wrote them themselves.
Of course, just because these libraries happen to be brought into existence in the Haskell ecosystem, is no reason for them to stay there. You can port such abstractions to any language you like (if it can support them—but many languages do!)
It's just not often done, because it is kind of hard to "see the point" in such abstractions without reading this-or-that paper... and all the people who are willing to do that gravitate toward Haskell, leaving the rest of the language ecosystem with very few people interested in expanding their language-of-choice's abstraction capabilities. (Another sad network effect.)
> Haskell doesn't make superior software; it just (as far as I understand) allows you to make software of equivalent quality, faster.
But the same question applies to that claim: If it is true, why aren't Haskell developers taking over the world with their ability to deliver the same software, faster?
Much easier question to answer: there aren't that many of them, and network effects are important.
There's a reason code-bases like Facebook Chat get successful, and then get rearchitected from niche languages (Erlang) to popular languages (C++), and it isn't ease of development or quality of result. It's the ability to hire people to maintain the thing. And, in large corporations, that reason is usually considered early-enough on that nobody lets development happen in such languages in the first place.
As such, it's only small ISVs that will end up using niche languages. (Sometimes small ISVs that get crazy successful—like WhatsApp—but still, small.)
Even then, the problem is that a code-base that's full of elegant abstractions... is still a codebase you have to learn. The fact that not everybody understands those abstractions is a bad thing for hire-ability, just as much as it's a good thing for ease-of-development and maintainability.
It's just like use of macros in a code-base: they (usually) make the resulting code better once you have taken the time to understand it—but the code starts off more opaque to anyone who hasn't yet taken that time.
Haskell's elegance happens when people who read math papers write software. People who haven't read those math papers can't maintain that software. Thus: Not Viable In The Enterprise.
And, to bring the point home: if you write better software, at the same speed, you can win as an ISV, because your software is, well, better. But if you merely write the same software faster (or for less cost), your bigcorp rival is going to win. No customer cares about how little time or money it took you to build the software. They just care about the result. If FooCorp can spend 10x the resources to make a product that's 10% better than yours, they'll still capture your whole market.
An interesting side note: I work with several mathematicians. We are an algorithmic management company, they come up with optimization algos, we (software guys) make it scale. They seem to prefer imperative code over functional style.
To make this research unbiased we need to do the following:
* Take people who are profecient in Ada, Haskell and Ada
* Randomly assign them to different teams
* Compare their results