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

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

#171

Post by OkayPhysicist » Tue, Nov 04, 2025, 4:39 PM UTC

imtringued wrote: post #151

OkayPhysicist wrote: post #55

Earlier quoted context omitted.

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. Switc…

Your final example feels wrong. Rust provides features that are basically unmatched by the fast majority of C++ and Rust competitors. I've also been soured enough on C++ to the point where rewriting an entire ecosystem in Rust seems like less effort than to figure out how to make the decrepit C++ one work for my purposes. You spend weeks trying to install a C++ library only to realize that it is not fit for purpose a…

Don't get me wrong: Starting a new project, I'd choose Rust hands-down. But rewriting a massive project is a massive investment, and unless there is something extremely deficient in the language you're currently using, that there isn't sufficient tooling to work around, it's probably not worth it.

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

#172

Post by cozzyd » Tue, Nov 04, 2025, 5:00 PM UTC

imtringued wrote: post #151

OkayPhysicist wrote: post #55

Earlier quoted context omitted.

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. Switc…

Your final example feels wrong. Rust provides features that are basically unmatched by the fast majority of C++ and Rust competitors. I've also been soured enough on C++ to the point where rewriting an entire ecosystem in Rust seems like less effort than to figure out how to make the decrepit C++ one work for my purposes. You spend weeks trying to install a C++ library only to realize that it is not fit for purpose a…

what C++ libraries take weeks to install? It's true that C++ compile times are atrocious but even that is over the top :).

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

#173

Post by OkayPhysicist » Tue, Nov 04, 2025, 5:17 PM UTC

bmitc wrote: post #120

OkayPhysicist wrote: post #55

Earlier quoted context omitted.

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. Switc…

> Moving from LABVIEW to a real programming language ... Switching from C++ to Rust? Probably not. Weird. LabVIEW is a real programming language. And both LabVIEW and Rust make entire classes of bugs that you often hit in C++ go away, especially for concurrent programs. > remotely modern development tooling I would make the argument that it is the tooling, i.e., Git and Diff, that is ancient and not remotely modern.…

Spoken like someone who's never worked on a large-scale LABVIEW system. A moderately sized codebase (equivalent to a project with a million-odd lines of code) ends up with a project containing tens if not hundreds of thousands of files. Each file opens up two windows, so if you're working on anything nontrivial you're going to have dozens and dozens of windows open at a time. Compiling such a project takes upwards of an hour, and you can't rely on the interpreter environment because it has observably different behavior than the resulting builds (oh, and the compilation process happens in the same process as the IDE, so that's completely bricked during that hour or two).

No one ever names their wires, so there's no variable names anywhere. To see the name of a subvi (think function), you have to hover over it. Sure there's a little picture, but that just means instead of just merely naming my functions I have to draw a little picture. Don't even get me started on wire routing, which is a crucial, manual process for any vi of non-trivial complexity.

Then there's the fundamental engine bugs, which National Instruments' response to hearing about is approximately "get fucked". Like, for example, the GUI rendering breaking in subtle ways when Windows has an update queued. Imagine getting a bug report that consists of "We can't do feature X", and trying desperately to figure out if your code is wrong, or if your customer's just an idiot, only to discover that 0.1% of the buttons in your project just... don't exist sometimes.

Then there's version control, which is rudimentary at best. In order to compare two files, you need to load both files, which even with lazy loading takes what feels like an eternity. Merges? No automation whatsoever. Every merge is manual.

Extremely useful features (like metaprogramming, which is important because of just how miserable writing LABVIEW is) are locked behind shoving obscure keys into ini files like "ABANDONALLHOPEYEWHOENTERHERE=1" or "SuperSecretPrivateSpecialStuff=true" (That second one is real).

Don't get me wrong, LabVIEW has its place as a way to hack together a little control panel to talk to some instruments. But anyone suggesting adding a subvi should be shot, and the project should be rewritten in a real programming language.

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

#174

Post by cozzyd » Tue, Nov 04, 2025, 5:34 PM UTC

binary132 wrote: post #101

jerf wrote: post #34

Earlier quoted context omitted.

"I cannot agree that programming language choice is a primary driver in a product's success or failure" I've seen it. There are definitely incorrect language choices for certain projects. It would be fair to say that these cases are themselves often exceptions. Many projects can be equally well accomplished by teams skilled in any language. But there is definitely a set of problems for which you can make incorrect la…

I’m having a hard time envisioning a project that could be killed by choosing Scala that wasn’t actually killed by bad engineering. Scala is pretty easy to write Just Simpler Java in….

Perhaps it's running on a semi-embedded system...

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

#175

Post by roguecoder » Tue, Nov 04, 2025, 6:26 PM UTC

FuckButtons wrote: post #131

asveikau wrote: post #124

Earlier quoted context omitted.

> rewriting a product only to change programming language is _always_ a bad idea, There are of course a few scenarios where changing the programming language is a more defensible, less "always wrong" kind of thing. An extreme case would be something like a COBOL system that needs maintenance and you have trouble finding people who can do it.

Or if you’ve written the mvp in python and realize you have to meet some performance metric that is 100x what your system is capable of.

It is bizarre how popular Python is for a language that is as poorly operationalized and encourages such poor architecture choices.

I would argue that the number of successful companies with Python code bases is the best evidence that language choice doesn't matter.

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

#176

Post by roguecoder » Tue, Nov 04, 2025, 6:30 PM UTC

hshdhdhehd wrote: post #47

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…

Language choices does make a decent difference to time spent, bugs, extensibility. Id guess a 20-100% tax for choosing the wrong language. However most of the time the best language is the one the team knows well. Caveat to that is if the threading model or performance doesnt suit. Or company platform engineering reasons (e.g. availability of platform libraries).

Frameworks are a major contributor to these dynamics, which is a little unfair to blame on the language, but I've seen orders of magnitude difference.

I had one time it was faster for the three of us to rewrite a web app in Rails than to make the Play framework accomplish what we wanted it to accomplish, even though none of the three of us had ever worked in Ruby before. Rewriting four months of work took two weeks because Rails neatly supported what we were doing and so much could be generated. We ended up with better test coverage too.

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

#177

Post by aj_hackman » Tue, Nov 04, 2025, 7:10 PM UTC

Balinares wrote: post #60

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 enginee…

90% of the time I've witnessed someone assert themselves to have some positive trait, they've espoused the complete opposite... especially when it came to morality or rationality. If someone tells you they're a logical person, they're probably highly limited in their thinking. If someone tells you they're a good person, run.

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

#178

Post by IshKebab » Tue, Nov 04, 2025, 7:59 PM UTC

wiseowise wrote: post #165

IshKebab wrote: post #83

Earlier quoted context omitted.

Maybe not the most expensive but it is certainly potentially one of the most costly. Look at Facebook with PHP and Dropbox with Python. It's the sort of thing you can overcome despite the odds (as both those companies did), but can also tip an on-the-edge company into failure. Same thing with the fundamental architecture of programs, and especially the data model & database solution. Still I don't entirely agree with…

> Look at Facebook with PHP and Dropbox with Python. What about them?

They ended up being extremely costly choices. Facebook resorted to developing its own language that only Facebook uses to escape from PHP. Dropbox also tried developing a complete new Python runtime because Python is so slow (but they gave up eventually). Dropbox had to rewrite their sync engine in Rust, and I think they also have rewritten backend stuff in Go.

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

#179

Post by geodel » Tue, Nov 04, 2025, 8:24 PM UTC

lproven wrote: post #158

tyleo wrote: post #36

Earlier quoted context omitted.

While I’ve seen bad technology chosen for projects, it seemed at root more a problem with the people choosing it than the technology itself.

> a problem with the people choosing it than the technology itself. Which is, I think, the key point of the OP's article. And my response to this is: We need objective, scientific, real-world measurements of PL efficiency, so that informed judgements can be made free of cognitive bias. This is how science works. Especially medicine. But programmers seem to feel that they are above this stuff.

> But programmers seem to feel that they are above this stuff.

No, programmers are quite below this stuff. Budgets for medical research, treatments, trials are way more than IT budgets. And for typical IT project the underlying point is even if requirements were wrong, changed halfway , software is malleable enough, to be changed, refactored. And all while it can remain in use even during change cycle.

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

#180

Post by wiseowise » Tue, Nov 04, 2025, 9:02 PM UTC

IshKebab wrote: post #178

wiseowise wrote: post #165

Earlier quoted context omitted.

> Look at Facebook with PHP and Dropbox with Python. What about them?

They ended up being extremely costly choices. Facebook resorted to developing its own language that only Facebook uses to escape from PHP. Dropbox also tried developing a complete new Python runtime because Python is so slow (but they gave up eventually). Dropbox had to rewrite their sync engine in Rust, and I think they also have rewritten backend stuff in Go.

> They ended up being extremely costly choices.

Extremely costly choice would be choosing .Net or Java and never releasing at all. Creating Hack advanced whole PHP ecosystem and cost nothing in the grand scheme of things.

> Dropbox had to rewrite their sync engine in Rust, and I think they also have rewritten backend stuff in Go.

Bah, idiots, should've just waited 4 years until Go and Rust came into existence.