Hacker News Reader

Comment by otabdeveloper1 | Hacker News Reader

They're rare because attempts to actually use Haskell in the field result in disaster. When you're hiring random programmers off the street to code your shitty business logic in Haskell, the result is a horrible mess of 'Unsafes, exploding memory leaks and random crashes. It's a train wreck.

View on HN

That's why you don't hire random programmers. You hire good ones, or you develop a training program and ensure they're good before you give them the responsibility for making or breaking your business.

Why would anyone trust "random programmers" to some of their most critical business efforts?

Because random businesses don't know how to hire good programmers. (In fact, even good businesses struggle with it.)

While that may be true to some extent, it doesn't further the discussion because it makes the point moot.

For the purposes of discussing the technical merits between different technology alternatives, we must assume some baseline competency of programmers. Otherwise the point becomes "technology doesn't matter because programmers are all stupid", which is not a constructive discussion.

otabdeveloper1 said (four parents to this post) that there aren't many successful Haskell projects because businesses can't (or at least don't) hire good programmers. Jtsummers said to hire good ones, or train them to be good.

So in context, you could read my post as saying that run-of-the-mill companies don't know how to hire good Haskell programmers.

> For the purposes of discussing the technical merits between different technology alternatives, we must assume some baseline competency of programmers.

No. If it's harder to find good Haskell programmers than it is to find good Python programmers, that absolutely has to be figured in. It's not a technical merit of Python or a technical flaw of Haskell, but it certainly has to be factored into the decision of which to use.

Perhaps the summary would be "Technical merit doesn't matter if all the good programmers for that language are unavailable."

Then there's the problem that, even though we have a good track record of hiring good C++, Java, and Objective C programmers, I am not sure that we would be competent at selecting good Haskell programmers, even if they were available.

So if I'm the CTO of RandomCo, I probably don't use Haskell for that new project, no matter how technically good the language is, because I can't identify, locate, and hire good people for the team. And bad people for the team can turn Haskell into... something less.

Ok, I understand the concern, but I don’t think it reflects the market, at least at the scale I operate in.

It’s the same as when DHH was asked about hiring Ruby developers a little over ten years ago. The question was “why would I use Ruby when there are far fewer developers that know it? Why not just use PHP since there are thousands of PHP developers available?”

The answer being “how many developers do you need? Thousands? Probably not. You probably need two or three.”

I did a hiring round for Haskellers recently for my startup, and we were spoiled for choice. There are so many brilliant people available, and we can’t hire them all.

100% of my income is from web applications written in Haskell. I hire Haskellers, and it's been a positive experience so far. None of my projects use unsafePerformIO. I track metrics across everything, and I'm not suffering memory leaks or random crashes.

Everything you have said is nonsense.

Reply on news.ycombinator.com