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.)
VB.Net winforms app from 2005?
Why engineers can't be rational about programming languages
11–20 of 206 posts
Re: Why engineers can't be rational about programming languages
#12People identify with tools!
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.
Re: Why engineers can't be rational about programming languages
#13The 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.
Re: Why engineers can't be rational about programming languages
#14> 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 m…
By corollary with Warren Buffett's belief that the most important financial decision you will ever make is to choose your marital partner... The most expensive choice a company makes is who will lead.
NOT because a good leader will save $$$$$$; because a bad leader can single-handedly sink a ship.
Re: Why engineers can't be rational about programming languages
#15I 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'm not entirely sure why the author decided to lead with such a charged headline. It got people to click the link to their think piece.
Reason #9 will shock you!
Re: Why engineers can't be rational about programming languages
#16I 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.
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.
Re: Why engineers can't be rational about programming languages
#17But... 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 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.
Re: Why engineers can't be rational about programming languages
#18> A programming language is the single most expensive choice a company makes
By far no. Now I don't know if I even should read beyond that.
Re: Why engineers can't be rational about programming languages
#19> 1. The power to transcend paradigms.
- 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.
Re: Why engineers can't be rational about programming languages
#20I 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.