A business decision, what drivel. By that argument, no technical merit of anything ever matters, and yet many things of what’s considered viable in a “business” have changed all the time, some of them because of the push of engineers towards better things.
This is a forum for engineers (not only, I know), who collectively will at least have a large part in steering what languages are considered common in future.
I actually don't pay any attention to what HN considers technically valid. Collective opinion among HNers is often very skewed from the actual reality.
Here is a comment from 9 years ago. It sounds like parody to me and demonstrates how echo chambers eventually deviate from reality. HN can often be an echo chamber
> A good programmer should wake up at 6 am in the morning get a solid 2.5hrs of coding done by 8:30 am, at 8:30 leave for work, work till 6 (it goes without saying that the lunchbreak must be spent trying to learn the Haskell or if you are feeling lazy answering questions on stackoverflow). Commute from 6 to 6:30 (it's a bonus if you listen to a technical podcast during this time and no stuff like TWIT does not count, perhaps audio lectures from the Advanced Algorithms course on MIT OCW). 6:30 to 7:00 time for supper and excellent time to catchup on r/programming and hackernews. 7-8:30pm is the time for relaxation by doing some recreational mathematics, doing problems from project Euler and that proof from The Art of Computer Programming excercises which you have been itching to get a go at! 8:30pm to 1 am code contribute to that open-source project, write patches for the Linux kernal and continue working on your startup.
> Anyone who does less programming that what is mentioned above cannot call himself a "good programmer", I would have serious reservations in calling that person even a mediocre programmer.
Yes, it is. But it makes a valid point about HN and the elevation of technical prowess over other concerns. It points out the danger of using an echo chamber as a gauge for reality.
I don't use technical recommendations from HN users because they consistently underestimate pragmatic concerns because the HN echo chamber overvalues technical virtuosity so real world pragmatic concerns get drowned out by other voices.
This is a forum for engineers (not only, I know), who collectively will at least have a large part in steering what languages are considered common in future.