Ask HN: Does the programming language actually matter?
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 ..
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?
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.
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.
Any thoughts?
10 comments
[ 3.2 ms ] story [ 31.1 ms ] threadTechnologies change; people don't. If you want to succeed, treat fixing your people problems as higher priority.
And don't fall into the trap of the "people who use technology X are better people" line of thinking.
Words from a 20 year veteran of the industry.
There is truth in this, but a bad Haskell developer is less likely to be able to get their program to compile than say a bad Java developer.
This makes it easier to weed out bad Haskell developers.
You'll also get good and bad human beings no matter what language you program in. The bad human beings will treat people around them like dirt. No matter how good a programmer they may be, it's not worth it.
Then there's the "not evil, but their personality needs some debugging" people...
1/ Isn't this statment contradicting itself? How can you fix people problems if they don't change? Or maybe you "replacing" rather than fixing?
2/ What tools or methods have you experienced in those 20 years? Were any of them suitable for a bottom-up approach?
2/ Mostly it involves facilitating self-actualization in those you're managing. People want to feel like they are being heard, and are making a useful contribution. There are exceptions, of course, but I'm talking about the norms. Some people have bad habits that need to be broken. Others are fearful and need encouragement. Others are thin-skinned and need more experience working with teams. People go through life challenges, crises, epiphanies... Even if you're not a manager, it behooves you to learn humanity and how it works. It's one of the few things in the technology sector that doesn't change.
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.
More: a startup doesn't have the resources to just throw bodies at a problem, or have a dedicated dev or two working on a non-core product. Picking the wrong language + ecosystem can ruin a project.
Less: Startups are make or break. If you break then who cares about the long term cost of code maintainance? If you make it then you can easily absorb the long term costs. E.g. If choosing php in the early days cost Facebook an extra 100 man-years worth of effort in the long term its a minor blip. 100 man-years is nothing to a company the size of Facebook.
Its not the most important decision, but it matters.