Yes, we do, but that is not the subject the article is talking about.
From the way so many commentators are refusing to engage with the point expressed in the title I think there is collective denial of the core point, so instead, people are discussing the symptoms rather than the disease that is the subject here.
> A programming language is the single most expensive choice a company makes, yet we treat it like a technical debate
I'd have to disagree, it really isn't, and I even think that's kind of the point the article makes.
Rewritting existing services from scratch in another language can often be a bad decision, because it assumes the choice of programming language is an important one. And any rewrite is costly, doesn't matter the reason why.
But starting a new project in a new language I don't think has much impact generally. And if it motivates the team, because they're excited about it, it can even help.
Deciding later to rewrite this once it's been built because it's not in the same language as what is common at the company, that's likely the mistake that will happen.
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 of your ignorance and continue being conservative with your self estimates.
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 absolutely love this take. Then again it matches what I've been saying for decades, so I would.
Generalizing briefly, the same phenomena of identity underlies a lot of our religious wars. Be it language, braces, indentation, or a variety of other programming choices. What's fundamentally going on is that programming expertise is fragile. (I think I first saw that idea in Code Complete?) A new language / style / technology / whatever very often will leave us less competent. Ideally we would respond with, "I guess I need to get back on that learning curve." But often it is easy to instead blame the external factor. "I'm a good programmer. I tried it. The result didn't work well. It must be bad."
It's very rare for a rewrite to make sense unless the underlying stuff has so fundamentally changed you don't really have a choice. (For example, DOS to Windows. You have to scrap your UI completely.)
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 than flexible.
All the fad chasing and top down declarations that we're all going to use Cucumber, GraphQL, Microservices or anything else is often a bad move.
First learn the problem you are trying to solve and empathize on behalf of the user... Then empathize on behalf of support... on behalf of the maintenance developers... on behalf of yourself in a decade. Is there a boxed solution? Buy it.. Is something custom really needed, what can you outsource as part of it? integrate it. Do the simplest, easiest thing you can to get the job done.
One day, many millennia ago, Caveman Ug carved himself a really nice club, and it became his favorite. He carried it everywhere and used it for everything.
The only conclusion I can draw from this is that some engineers are not great at arguing the merits and challenges of a programming language. GC vs non-GC should be one of the first and most straightforward decisions made when picking a language. It's hard to tell in this situation given that there are no concrete examples of what the arguments were, but if one is seriously considering Go for a domain, then they don't actually need the complexity a non-GC language brings.
If anything, maybe this says there is room for a Rust-like GC'd language.
The only conclusion I can draw from your comment is that you wanted to provide an example of the sort of flawed reasoning that the article is in fact discussing.
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 hand, it was a large, working app, and the pushback was "yeah, someday, but for now we're using it to drive the company".
The discussions were always calm, measured, and conducted by adults. We didn't shout or scream at each other, or anything like that. Both sides had reasonable and compelling arguments to support their viewpoint. But from my POV, staying with the VFP app, with the looming deprecation warnings on the calendar, was insanity. Their point was that rewriting the entire, working app from scratch was also insanity.
It's not like a team wanted to rewrite it in PHP, which we can all at least agree would be madness.
If you're a Python Programmer, and you've made that your identity, you've trapped yourself into the mindset that you are a Python Programmer. Same with any other identity you ascribe to yourself (or allow others to ascribe to you). Separating yourself from your tools allows you to evaluate the tools independently of your identity and you will find yourself unaffected (or at least less affected) by reaching a conclusion that the thing you know well may not be appropriate to the job. You may not be appropriate for the job, and that's fine too. Getting past paradigms (or identities with how I'm extending it) gives you much greater freedom to explore and participate in the world.
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 them reiterated is fine.
Then they turn around and claim that choosing a programming language is the most important thing you can do, and that you'll need to Like and Subscribe to learn more about it...
I've been through tens of rewrite projects, successful and unsuccessful, and seen projects and products at almost every scale, and I cannot agree that programming language choice is a primary driver in a product's success or failure. Even extending this thesis from language to framework and ecosystem, where there's perhaps a _tiny_ bit of signal, still doesn't really lead to a meaningful conversation. The main driver of a project's success is almost always driven by: the composition of employees working on the project, and the competence of the people architecting the project. Don't get me wrong - to an extent, some languages (especially more niche ones) drive hiring and what kind of employee you get, but this effect is dwarfed by who works on the project and how well it's managed.
C++ feels like a counterexample. There's zero or arguably negative hype behind the language and everyone I know hates it.
However, we continue to write new code in C++ due to libraries and because people know it. These are all factors that the OP considers to be negligible.
A reasonable rate at which to consider a new primary programming language for non-niche, non-throwaway production software is once every 15 years. Adventurous, risk-seeking teams can try for 10, but that's pushing it.
If you find yourself searching for a replacement language more frequently, you should stop, take a long look in the mirror and ask yourself:
1. Something has clearly gone wrong last time, since you're looking for a replacement so soon; are you confident of your language-picking ability?
2. Are you sure your goal is to do what's best for the software and its long-term maintenance, or is there some other consideration here?
What’s your take on older languages gaining new life in production because of ecosystem improvements? I’m thinking of Python, which for most of its 34 year history wasn’t always a go-to choice, but nowadays its ecosystem is being scaled with Rust and C++ libraries and tooling. I’ve noticed a similar trend in JavaScript, where Go and Rust are improving bundlers, type-checkers, etc. The way we deploy our software has also changed dramatically with Kubernetes, code running at the edge (thinking of Cloudflare Workers, AWS Lambda).
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 think like religion or ethnic group, not sub-professional groupings like neurosurgeon or devops, and certainly not specific to tooling ("I'm a DeWalt carpenter!")
The missing connection is back to economics. If I've spent a bunch of time coding .NET, it's going to cost me something to code Java or python. This is the actual economic conversation being had. People will have to learn a new toolset, while having deadlines over their heads.
The solution is actually this: You hire people who are language-agnostic.
I used to spend a LOT of time in VBA, and then .NET. 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, Kotlin, Elixir, js, and Rust. It was an eye-opening experience that you could do this. Just make the leap, and you find it wasn't that far.
If you don't have people who have done this a few times, you will get resistance, and the real resistance is they don't think it's worth it to put in the hours to learn the new tools. They come up with all sorts of justifications for why things are fine with the old tools.
You'll also become a language lumper if you do this. I don't really think there's a lot of language features. The main ones are GC vs manual memory, strong vs weak type, imperative vs declarative. Once I had a few points on these axes, a lot of things eased when it came to new languages.
> 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.
I dunno. I take the position that language designers have blind spots around the weaknesses of their languages.
Python: Python is almost a hard-compiled language. Most of the dynamic stuff that's really hard to compile isn't all that useful. But Guido and his enablers love the dynamism, and the CPython implementation. So instead of PyPy taking over, we have CPython with hacks to call C.
Go: The "share by communicating" thing in Go works out about as well as it does in other languages, that is, it's useful but not central. Early on, there were tortured examples of implementing locks with queues. Nobody does that any more. People pretty much write Go like they do other languages, with shared state and locks. Queues are used when queues do something useful. The real strength of Go is that the libraries needed for webcrap are maintained and used by Google, so they're all well-tested and exercised. Also, goroutines/green threads eliminate the sync/async distinction. Garbage collection takes care of most ownership problems. Simple. (I recently wrote a web back end in Rust. Big mistake. Should have used Go.)
Rust: The "traits" system is an overreaction to Objects Are Bad. Rust probably would have been better off with single inheritance, which is well understood. (Multiple inheritance has too many dark corners.) People keep trying to do OOP with traits, which is like pounding a screw.
Rust still doesn't have a good solution to the back reference problem, as I point out occasionally. The macro language sucks, but then almost all macro languages suck. "Async" is a nightmare but necessary to keep the Javascript crowd happy, since that's all they know. If you really need complex multiprocessor concurrency, Rust is currently the best game in town. Most people don't.
C++: They can't take anything out, and the cruft is too deep. "Modern C++" is not all that bad, but all of bad old C/C++ is still in there. So the safety situation remains awful. The cumulative complexity is now so high that even long-time language lawyers are giving up following it.
Javascript: Who thought that would rule the world? It's awful, but everywhere. Heroic efforts have made an inherently slow language go fast. It's kind of impressive, actually.
Rational choice for an engineer is not the same thing as rational choice for the company. I want to have an interesting working life, learning new things and keeping my CV current. It's not rational for me to shackle my career to doing maintenance fixes on a dying PHP app.
- Look at people using identity-focused reasoning with politics
- It’s research!
- That’s the same as those <programming language tropes>
- Because I have some anecdotes about that
But the person making the argument couldn’t be falling for the same thing? Nope.[1]
Maybe it would be nice to have more objective metrics. So what’s that?
> We need a framework that makes the invisible costs visible. One that lets us have the economic conversation instead of the identity conversation. One that works whether you’re choosing your first language or evaluating a migration.
> Our industry has never really had that framework… Until now.
I better Stay Tuned.
[1] Those irrational people: making arguments. Me, the rational one: also making arguments, but mine are correct.
58 comments
[ 3.3 ms ] story [ 902 ms ] threadFrom the way so many commentators are refusing to engage with the point expressed in the title I think there is collective denial of the core point, so instead, people are discussing the symptoms rather than the disease that is the subject here.
I'd have to disagree, it really isn't, and I even think that's kind of the point the article makes.
Rewritting existing services from scratch in another language can often be a bad decision, because it assumes the choice of programming language is an important one. And any rewrite is costly, doesn't matter the reason why.
But starting a new project in a new language I don't think has much impact generally. And if it motivates the team, because they're excited about it, it can even help.
Deciding later to rewrite this once it's been built because it's not in the same language as what is common at the company, that's likely the mistake that will happen.
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 of your ignorance and continue being conservative with your self estimates.
Generalizing briefly, the same phenomena of identity underlies a lot of our religious wars. Be it language, braces, indentation, or a variety of other programming choices. What's fundamentally going on is that programming expertise is fragile. (I think I first saw that idea in Code Complete?) A new language / style / technology / whatever very often will leave us less competent. Ideally we would respond with, "I guess I need to get back on that learning curve." But often it is easy to instead blame the external factor. "I'm a good programmer. I tried it. The result didn't work well. It must be bad."
Among the many attempts to try to fix the problem, I can recommend https://blog.codinghorror.com/the-ten-commandments-of-egoles.... To the extent that you manage to apply its advice, you really will do better.
Of course your improvement won't directly help those around you...
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 than flexible.
All the fad chasing and top down declarations that we're all going to use Cucumber, GraphQL, Microservices or anything else is often a bad move.
First learn the problem you are trying to solve and empathize on behalf of the user... Then empathize on behalf of support... on behalf of the maintenance developers... on behalf of yourself in a decade. Is there a boxed solution? Buy it.. Is something custom really needed, what can you outsource as part of it? integrate it. Do the simplest, easiest thing you can to get the job done.
One day, many millennia ago, Caveman Ug carved himself a really nice club, and it became his favorite. He carried it everywhere and used it for everything.
If anything, maybe this says there is room for a Rust-like GC'd language.
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 hand, it was a large, working app, and the pushback was "yeah, someday, but for now we're using it to drive the company".
The discussions were always calm, measured, and conducted by adults. We didn't shout or scream at each other, or anything like that. Both sides had reasonable and compelling arguments to support their viewpoint. But from my POV, staying with the VFP app, with the looming deprecation warnings on the calendar, was insanity. Their point was that rewriting the entire, working app from scratch was also insanity.
It's not like a team wanted to rewrite it in PHP, which we can all at least agree would be madness.
By far no. Now I don't know if I even should read beyond that.
- Donella Meadows, Leverage Points: Places to Intervene in a System https://donellameadows.org/archives/leverage-points-places-t...
If you're a Python Programmer, and you've made that your identity, you've trapped yourself into the mindset that you are a Python Programmer. Same with any other identity you ascribe to yourself (or allow others to ascribe to you). Separating yourself from your tools allows you to evaluate the tools independently of your identity and you will find yourself unaffected (or at least less affected) by reaching a conclusion that the thing you know well may not be appropriate to the job. You may not be appropriate for the job, and that's fine too. Getting past paradigms (or identities with how I'm extending it) gives you much greater freedom to explore and participate in the world.
Then they turn around and claim that choosing a programming language is the most important thing you can do, and that you'll need to Like and Subscribe to learn more about it...
I've been through tens of rewrite projects, successful and unsuccessful, and seen projects and products at almost every scale, and I cannot agree that programming language choice is a primary driver in a product's success or failure. Even extending this thesis from language to framework and ecosystem, where there's perhaps a _tiny_ bit of signal, still doesn't really lead to a meaningful conversation. The main driver of a project's success is almost always driven by: the composition of employees working on the project, and the competence of the people architecting the project. Don't get me wrong - to an extent, some languages (especially more niche ones) drive hiring and what kind of employee you get, but this effect is dwarfed by who works on the project and how well it's managed.
However, we continue to write new code in C++ due to libraries and because people know it. These are all factors that the OP considers to be negligible.
If you find yourself searching for a replacement language more frequently, you should stop, take a long look in the mirror and ask yourself:
1. Something has clearly gone wrong last time, since you're looking for a replacement so soon; are you confident of your language-picking ability?
2. Are you sure your goal is to do what's best for the software and its long-term maintenance, or is there some other consideration here?
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 think like religion or ethnic group, not sub-professional groupings like neurosurgeon or devops, and certainly not specific to tooling ("I'm a DeWalt carpenter!")
The missing connection is back to economics. If I've spent a bunch of time coding .NET, it's going to cost me something to code Java or python. This is the actual economic conversation being had. People will have to learn a new toolset, while having deadlines over their heads.
The solution is actually this: You hire people who are language-agnostic.
I used to spend a LOT of time in VBA, and then .NET. 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, Kotlin, Elixir, js, and Rust. It was an eye-opening experience that you could do this. Just make the leap, and you find it wasn't that far.
If you don't have people who have done this a few times, you will get resistance, and the real resistance is they don't think it's worth it to put in the hours to learn the new tools. They come up with all sorts of justifications for why things are fine with the old tools.
You'll also become a language lumper if you do this. I don't really think there's a lot of language features. The main ones are GC vs manual memory, strong vs weak type, imperative vs declarative. Once I had a few points on these axes, a lot of things eased when it came to new languages.
I think you have it totally backwards for >90% of people, and I counter your argument with a very famous quote:
"Dammit, Jim, I'm a doctor, not a bricklayer!"
I wrote a compiler/language, and I was expecting something different from the article after my experiences
Like many of the other commenters, I didn't like the article
The subject is right there in the title:
Engineers Can't Be Rational About Programming Languages
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.
Python: Python is almost a hard-compiled language. Most of the dynamic stuff that's really hard to compile isn't all that useful. But Guido and his enablers love the dynamism, and the CPython implementation. So instead of PyPy taking over, we have CPython with hacks to call C.
Go: The "share by communicating" thing in Go works out about as well as it does in other languages, that is, it's useful but not central. Early on, there were tortured examples of implementing locks with queues. Nobody does that any more. People pretty much write Go like they do other languages, with shared state and locks. Queues are used when queues do something useful. The real strength of Go is that the libraries needed for webcrap are maintained and used by Google, so they're all well-tested and exercised. Also, goroutines/green threads eliminate the sync/async distinction. Garbage collection takes care of most ownership problems. Simple. (I recently wrote a web back end in Rust. Big mistake. Should have used Go.)
Rust: The "traits" system is an overreaction to Objects Are Bad. Rust probably would have been better off with single inheritance, which is well understood. (Multiple inheritance has too many dark corners.) People keep trying to do OOP with traits, which is like pounding a screw. Rust still doesn't have a good solution to the back reference problem, as I point out occasionally. The macro language sucks, but then almost all macro languages suck. "Async" is a nightmare but necessary to keep the Javascript crowd happy, since that's all they know. If you really need complex multiprocessor concurrency, Rust is currently the best game in town. Most people don't.
C++: They can't take anything out, and the cruft is too deep. "Modern C++" is not all that bad, but all of bad old C/C++ is still in there. So the safety situation remains awful. The cumulative complexity is now so high that even long-time language lawyers are giving up following it.
Javascript: Who thought that would rule the world? It's awful, but everywhere. Heroic efforts have made an inherently slow language go fast. It's kind of impressive, actually.
- Look at people using identity-focused reasoning with politics
- It’s research!
- That’s the same as those <programming language tropes>
- Because I have some anecdotes about that
But the person making the argument couldn’t be falling for the same thing? Nope.[1]
Maybe it would be nice to have more objective metrics. So what’s that?
> We need a framework that makes the invisible costs visible. One that lets us have the economic conversation instead of the identity conversation. One that works whether you’re choosing your first language or evaluating a migration.
> Our industry has never really had that framework… Until now.
I better Stay Tuned.
[1] Those irrational people: making arguments. Me, the rational one: also making arguments, but mine are correct.