As much as I would love to use Haskell professionally, I always wondered if teams/projects using Haskell don't also struggle with all the sociology involved in developing software ..<p>Sure, being able to use Applicative reduces lots of code duplication, brings in better clarity and all .. but what if the product owner still remains a jerk without a vision?<p>In all the teams I have been so far, I can honestly say that the _language_ itself was never _the_ problem. It was always a combination of communication, skill or product vision.<p>The only thing I can imagine is that by choosing Haskell you tend to get better skilled developers - so only communication and product vision remain that could ruin your project/product.<p>Any thoughts?
You'll get good and bad developers no matter what language you program in. Your career is more dependent upon whether you can work with people who are difficult to work with or not, rather than your skill in technology X.<p>Technologies change; people don't. If you want to succeed, treat fixing your people problems as higher priority.<p>And don't fall into the trap of the "people who use technology X are better people" line of thinking.<p>Words from a 20 year veteran of the industry.
It matters, but like you said: it matters a whole lot less than a lot of other factors.<p>That is to say: If you've got a strong vision, the right team, the right backers, the right product-market-fit, etc and your engineers are sitting around trying to figure out how to make the product better/faster/more-reliable, then maybe start looking at the language you chose. But honestly an underperforming language is a problem that most startups never have the good-fortune of having to legitimately worry about.
It has a large impact on long term productivity and cost. As a general rule a 10kloc project is much easier and cheaper to maintain than a 100kloc project and you can get these kinds of improvements by choosing the right language.<p>Its not the most important decision, but it matters.