Why engineers can't be rational about programming languages • Hacker News Board

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

#51

Post by hunterpayne » Mon, Nov 03, 2025, 8:24 PM UTC

1718627440 wrote: post #28

wvenable wrote: post #16

Earlier quoted context omitted.

Probably should be "management" can't be rational about programming languages because that's what it's about. The article isn't talking about a group of engineers coming together to decide on a platform, instead it's about a choice being thrust upon from from up high. That management is also an engineer but that's not really the key point.

Why would management care about tools?

Exactly, when they do its a sign of bad management. The only case I can think of when this isn't true would be the difficulty in finding people willing to use/work in that language. But in all but the most obscure languages, this is probably given too much weight by management.

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

#52

Post by fabian2k » Mon, Nov 03, 2025, 8:25 PM UTC

bri3d wrote: 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…

It's not an issue as long as you use a mainstream language, but using a language or framework that will be perceived as a dead end can hurt your chances to hire and retain people. If you're a large or prestigious enough employer you can probably compensate that as long as you're willing to train people.

Programming language alone should almost never be a big enough issue to force a rewrite, but if you already have serious other issues that force huge changes you might as well look at it at the same time.

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

#53

Post by laxd » Mon, Nov 03, 2025, 8:25 PM UTC

twic wrote: post #32

cozzyd wrote: post #27

Earlier quoted context omitted.

It CAN be. If a company chose brainfuck as a main programming language, it's doubtful they'd come back from that choice.

I think the assertion might even have been true for non-pathological cases 20 to 40 years ago. A company that chose Visual Basic or Perl would have had a much harder road than one which chose C# or Python. But i think the languages which have survived to the present day are all pretty close in productivity. Except C.

I've worked for a company with a large code base in Visual Basic .net. Product been in development since the 90's, with rich customer that only cares about their software doing its job. It's a surprisingly productive language combined with Visual Studio. Even though, as a language enthusiast, I barfed a bit now and then. Dev team would like to switch to C# but it would have been a multi-year effort taking away from lucrative feature requests.

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

#54

Post by romaniv » Mon, Nov 03, 2025, 8:26 PM UTC

> Instead of asking “which language is best?” we need to ask “what is this language going to cost us?”

As long as engineering salaries depend on tribal identity markers (i.e. language and tooling preferences) rather than ability to save money, people will entirely rationally choose tools that look good on their resume rather than save their companies money.

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

#55

Post by OkayPhysicist » Mon, Nov 03, 2025, 8:29 PM UTC

bri3d wrote: 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…

In my experience, a language switch rewrite can be a benefit only when switching from a dead ecosystem to a living one.

For example, migrating a web app from a language that predates Unicode to something that won't require a bunch of scaffolding around every user input sometimes is worth it. Moving from LABVIEW to a real programming language that integrated with remotely modern development tooling was worth it. Switching from C++ to Rust? Probably not.

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

#56

Post by fabian2k » Mon, Nov 03, 2025, 8:30 PM UTC

hunterpayne wrote: post #38

tracker1 wrote: post #10

More often than not, preference should be given to the language most of the team know the best. The only exception is when everyone on the team feels a different language is a better fit for the need or there are underlying reasons for a language shift. Personally, my bias is towards the languages I'm most comfortable with. I recognize this and will make other suggestions and if I'm not responsible for the code, I'm…

> More often than not, preference should be given to the language most of the team know the best. I'm sorry but I disagree. Languages are tools, pick the best tool for the job. The idea that languages are all good at everything is not true. And when I see takes like this, I tend to think that that person just doesn't understand how to assess a language's strengths and weaknesses. Want to write ML, probably best to us…

I think for many cases it is fair to make the assumption that you're staying roughly within the same kind of application. So if your team previously did web applications you won't suddenly do embedded stuff or high-frequency trading. And within such an area, there aren't enough differences between languages to overcome the drawback of learning a new one.

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

#57

Post by hunterpayne » Mon, Nov 03, 2025, 8:31 PM UTC

ranger_danger wrote: post #4

I've got a different theory than this AI slop: Engineers often aren't rational because engineers can still be stupid. Dogmatism/black-and-white thinking is often a sign of low emotional intelligence (and can also be a defense mechanism called "splitting"). The Dunning-Kruger effect also applies to "smart" people. You don't stop when you are estimating your ability correctly. As you learn more, you gain more awareness…

Dunning-Kruger applies to people who don't know a specific domain. If you spend all day writing code, you probably understand at least one language fairly well. Maybe you are not an expert in how compilers work but at least you understand programming to some degree. So this topic is probably one of the least appropriate ones to apply DK. If you want to make this argument, perhaps best to base it on identity, not DK.

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

#58

Post by tailrecursion » Mon, Nov 03, 2025, 8:34 PM UTC

lordnacho wrote: post #41

Huge problem with the conclusion, and it is something mentioned in the article. It is suggested to view the language choice as an economic decision. But guess what, that is already what the decision makers think they are doing. There's another almost-got-it in the article. He is suggesting people tie their identity to their programming language of choice. This seems odd to me, because we tend to think of identity as…

> I was daunted by making the jump to C, then c++ and python. Only over time did I overcome the nerves and move on with Java, [...]

It sounds as if you did skip C++ and moved to Java instead. If so you serendipedously avoided the one language that's likely to cause problems. C++ doesn't work like the rest of the languages on your list, and it really is as full of land mines as people say - even though, with a good process, evidently it can be managed.

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

#59

Post by fragmede » Mon, Nov 03, 2025, 8:37 PM UTC

lordnacho wrote: post #41

Huge problem with the conclusion, and it is something mentioned in the article. It is suggested to view the language choice as an economic decision. But guess what, that is already what the decision makers think they are doing. There's another almost-got-it in the article. He is suggesting people tie their identity to their programming language of choice. This seems odd to me, because we tend to think of identity as…

> certainly not specific to tooling ("I'm a DeWalt carpenter!")

I'm not sure that's a correct analysis of their situation. Yes, if you hand a perfectly spherical DeWalt screwgun to a Nikita carpenter, they'll know how to use it, but in practice, everyone I know in the trades has picked a team and just committed to it (to the tune of many thousands of dollars in tools). Fortunately for them, the tools are basically the same, just a stupid bit of plastic (and there are 3d printable or buyable adapters) so it's easy enough to switch teams if they had to, it's just a pile of money, unlike sw tools and materials where I mean, yeah, eventually I got the hang of Ruby, as I did C++ and C and Python and Perl and now typescript and JavaScript oh god and also Swift. (Managed to avoid Obj-C tho!)

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

#60

Post by Balinares » Mon, Nov 03, 2025, 8:38 PM UTC

Freedom2 wrote: post #5

I don't agree with the title - I've seen many engineers be rational and pragmatic about programming languages. I'm not entirely sure why the author decided to lead with such a charged headline.

I've seen a lot more engineers self-describe as rational and pragmatic than I've seen act like it. This here website is quite a marvelous zoological gallery in that respect. (Love you folks, you are messy complicated humans the lot of you and I wish I could cogently convey how good it is to embrace that instead of pretending elsewise.)

We do pick tools in good part based on how we feel about them (especially engineers who believe themselves beings of pure rationality, tbh), and I think that's in fact okay; how we feel doesn't come from nowhere, it's informed by decades of experience often acquired the hard way. But it's still a squishy metric that can only be trusted to a point, and being aware of how this sort of decision making occurs, in yourself and in others, is highly valuable IMO.