Live data from Hacker News

Why engineers can't be rational about programming languages

spf13.com

91–100 of 206 posts

Re: Why engineers can't be rational about programming languages

#91
post #20

I think the author almost contradicts themselves; they reach the salient-but-obvious conclusion that rewriting a product is almost always a bad idea and that rewriting a product only to change programming language is _always_ a bad idea, that tribalism is a poor decisionmaking framework, and that leadership by arbitrary decree is stupid. Great! These are age-old lessons that people somehow seem to forget, so seeing t…

I think rewriting something in another language can be a great idea, especially if $CURRENT_LANG does not have a sane way of configuring its features.

https://discord.com/blog/why-discord-is-switching-from-go-to...

Re: Why engineers can't be rational about programming languages

#92
post #80

Earlier quoted context omitted.

This is a good take. In the consulting context, I've quickly realized that most problems at a business can be broken down into "this will destroy the project on its own" and "this is an annoyance to a good engineer". Language choice is basically always in the latter category, whereas poor management or one egotist is frequently in the former. Like, my team doesn't know anything about Java, but we COULD ship in Java i…

My team ships with a multi-hour CI pipeline that works 50% of the time and effectively zero local development. It's awful in almost every way developer experience-wise, but rock bottom is deeper than you think!

I had local development in a previous job, but you had to start a whole Kubernetes cluster. No unit tests, but a whole suite of e2e tests. And forget about debuggers as it was all microservices.

Re: Why engineers can't be rational about programming languages

#93

But... which side is being more rational? I was hired at a shop who had a large, complex Visual FoxPro application they'd developed in house. They brought me in to write a web interface for it, which I did in Python because there was, thankfully, no Visual FoxPro for Web Apps. I contented that they needed to start a rewrite in something else ASAP. VFP wasn't going to get more supported as time went on. On the other h…

> It's not like a team wanted to rewrite it in PHP, which we can all at least agree would be madness.

That seems like the same argument that TFA is making, but in reverse. I think it's just as invalid. PHP is a perfectly fine language for many things. There is plenty of greenfield development being done in PHP these days + a substantial amount of PHP in production all over the place. Unilaterally writing it off as "madness" seems pretty disingenuous to me.

Re: Why engineers can't be rational about programming languages

#94
It is the language, available tools and libraries, and the community. As a programming snob the fact that most of my coding is now done in Javascript is a threat to my identity managed with a handful of clearly reasoned explanations. This choice works with tools and libraries that support my needs and there are always more experienced programmers that can be called on when help is required.

Re: Why engineers can't be rational about programming languages

#96

But... which side is being more rational? I was hired at a shop who had a large, complex Visual FoxPro application they'd developed in house. They brought me in to write a web interface for it, which I did in Python because there was, thankfully, no Visual FoxPro for Web Apps. I contented that they needed to start a rewrite in something else ASAP. VFP wasn't going to get more supported as time went on. On the other h…

> It's not like a team wanted to rewrite it in PHP, which we can all at least agree would be madness. That seems like the same argument that TFA is making, but in reverse. I think it's just as invalid. PHP is a perfectly fine language for many things. There is plenty of greenfield development being done in PHP these days + a substantial amount of PHP in production all over the place. Unilaterally writing it off as "m…

Congratulations for getting the point of the article. :)

Re: Why engineers can't be rational about programming languages

#97
post #20

I think the author almost contradicts themselves; they reach the salient-but-obvious conclusion that rewriting a product is almost always a bad idea and that rewriting a product only to change programming language is _always_ a bad idea, that tribalism is a poor decisionmaking framework, and that leadership by arbitrary decree is stupid. Great! These are age-old lessons that people somehow seem to forget, so seeing t…

> I cannot agree that programming language choice is a primary driver in a product's success or failure

A possible reason for this is that our current languages are way too similar to make a difference.

Even most of the ones we think of as radically different.

Re: Why engineers can't be rational about programming languages

#98
For anyone interested: Takkle was "a social networking and media site geared toward those involved in high school sports: players, coaches, and fans" as per this article from 2006, aptly titled "Takkle.com, social networking for jocks".

[https://www.cnet.com/tech/services-and-software/takkle-com-s...]

Re: Why engineers can't be rational about programming languages

#99
post #76
post #69

Earlier quoted context omitted.

In my first post, the example I really wanted to use was people picking Go for their top-end, competitive-with-anything-in-the-market database. I choose Python just because anyone who would argue that is a good choice is clearly not someone who is in a position to see reason. But I think Go is a serious mistake... it's just one that lets you get to market, unlike Python which never would. But it's still going to end…

> the example I really wanted to use was people picking Go for their top-end, competitive-with-anything-in-the-market database. You mean they're writing their own database? Why? That's a huge job and available databases are pretty good. There are multiple open-source choices, all of which work. If they think they're going to compete with Oracle, they need to read the history of Oracle.

There are many workloads for which all available database engines are poor. If you have one of those workloads and the esoteric technical expertise, it is entirely plausible to improve performance, scale, etc metrics by 10-100x versus whatever is currently available in the market. 10-100x is qualitative if that is central to your business.

Of course, almost no one should attempt this. The number of people with the technical expertise to pull it off successfully is much, much smaller than the number of companies with workloads that would benefit from this.

It doesn't have to be an exotic workload. Sometimes the market is just full of weak implementations e.g. graph databases.

Re: Why engineers can't be rational about programming languages

#100
post #20

I think the author almost contradicts themselves; they reach the salient-but-obvious conclusion that rewriting a product is almost always a bad idea and that rewriting a product only to change programming language is _always_ a bad idea, that tribalism is a poor decisionmaking framework, and that leadership by arbitrary decree is stupid. Great! These are age-old lessons that people somehow seem to forget, so seeing t…

> and that leadership by arbitrary decree is stupid. Great! These are age-old lessons

To some extent! There are also cases where any decision is better than no decision, and all the options are good enough that it's not worth the delay to argue about them.

Post reply on HN