4 ms·
It's about accountability. There are two types of it: a leader either recognizes and understands the gain to be had from using something like Haskell and has t
by ixmatus 12y ago
It's about accountability.
There are two types of it: a leader either recognizes and understands the gain to be had from using something like Haskell and has the resources to hire someone really good at it (who is therefore accountable, but he/she knows how to replace that person if they leave), or the leader themselves is an implementor in the esoteric technology and is comfortable being an accountable party themselves.
You rarely see the first type, more often it's the second type. Being accountable means that even if all of our programmers left us, I could at least keep the lights on without panicking (funny enough, that's actually easier to do in Haskell than a large Python / Ruby codebase).
BTW, it isn't hard to find them but it is expensive. These are people that have a level of motivation above the average and subsequently have a level of knowledge and skill also above the average. Basic economics can be used to answer why they are more expensive. Particularly when you start looking at specialized fields with a specialized technology: applied mathematicians that are also skilled Haskell programmers, or kernel hackers that also understand Haskell well.
- sanderjd 12y agoI agree with every word you wrote. To take it further, assuming both that projects built by experienced Haskell programmers are "better", and that those experienced Haskell programmers are more expensive, are those projects actually "better" enough for the company to break even. For the vast majority of projects, the answer is almost certainly "no", because most projects don't live or die on their technical merits. I think this limits the supply of companies further than even the perception-of-difficulty effects.
- marcosdumay 12y agoProjects don't live or die on technical merits. But more often than not, they are born or not on technical merits. Remember that lots of IT projects fail, often with no result at all to show. That fact it easy to ignore when you interact only with competent developers.