[HN Gopher] Why engineers can't be rational about programming la...
___________________________________________________________________
Why engineers can't be rational about programming languages
Author : spf13
Score : 64 points
Date : 2025-11-03 17:08 UTC (5 hours ago)
(HTM) web link (spf13.com)
(TXT) w3m dump (spf13.com)
| bobx17 wrote:
| We see the "we need to rewrite in X" conversation play out all
| the time here on HN. Love this take on it.
| didibus wrote:
| > 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.
| IAmBroom wrote:
| 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.
| ranger_danger wrote:
| 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 of your ignorance and
| continue being conservative with your self estimates.
| hunterpayne wrote:
| 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.
| dragonwriter wrote:
| > Dunning-Kruger applies to people who don't know a specific
| domain.
|
| I mean, its largely a statistical artifact around which a pop
| science myth has accumulated, but on its own terms it applies
| smoothly and continuously across the entire range of ability
| in a domain, not in any special way just one one side of
| binary knowledge dividing line (the finding was basically
| that people across the whole range of ability to tend to rate
| their own relative ability closer to the 70th percentile than
| it actually is, but have monotonically increasing with actual
| relative ability.)
| Freedom2 wrote:
| 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.
| Jtsummers wrote:
| > 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.
| IAmBroom wrote:
| Reason #9 will shock you!
| esafak wrote:
| I did not. I read the comments and still found little reason
| to check the article.
| wvenable wrote:
| 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.
| 1718627440 wrote:
| Why would management care about tools?
| hunterpayne wrote:
| 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.
| hunterpayne wrote:
| Because his first experience with this debate was forcing PHP
| on engineers who knew that would be a bad choice. No matter
| what you are doing, PHP isn't the right choice for it if more
| than 1 person will ever use or depend upon the software.
|
| PS I've seen PHP destroy billions in value in my career. It and
| Brainfuck are the only 2 languages you should never use to make
| software for other people. Every other language has a core use
| it is good at. JS in the browser, Python for scripting, Java
| when you need good observability and 3rd party libraries,
| etc...
| kerblang wrote:
| > Because his first experience with this debate was forcing
| PHP on engineers who knew that would be a bad choice
|
| Ummm... No, I think it was about forcing Perl on engineers
| who had been using PHP.
| Balinares wrote:
| 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.
| btilly wrote:
| 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."
|
| 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...
| tailrecursion wrote:
| > A new language / style / technology / whatever very often
| will leave us less competent.
|
| This may be a big factor in rejecting unfamiliar languages.
| Over time the brain trains itself to grok a specific syntax,
| and understanding becomes partly automatic: we look at a Java
| program and our brain injects meaning into our consciousness.
| If we then look at APL or Lisp, however, that training on Java
| doesn't apply and the automatic injection doesn't function.
| We're left having to read the symbols directly, and it's
| unsettling not having the auto-assist. It makes us feel we
| "can't" understand the language, when it would likely take a
| couple weeks of immersion to change that impression.
| LorenPechtel wrote:
| 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.)
| dmoy wrote:
| Indeed, and the perhaps canonical article on "don't rewrite"
| from 2000: https://www.joelonsoftware.com/2000/04/06/things-
| you-should-...
| tracker1 wrote:
| VB.Net winforms app from 2005?
| wvenable wrote:
| I'm working on such a re-write / learning process right now
| because underlying stuff has fundamentally changed and it was
| (slightly) long past time to make the move. Of course, we're
| still going things incrementally and slowly and making effort
| to keep older tech running.
|
| For some tech choices there was just one clear path from where
| we are to where we need to go. But for others, the overriding
| decision was more often than not that some team member had
| familiarity with the technology. Certainly not the only
| criteria but enough to tip the scales if it came to that.
| Balinares wrote:
| I once was involved in a complete rewrite in a new language
| that ended up saving the company -- so those do happen,
| empirically.
|
| That was an unusual scenario, however; the previous iteration
| of the product had major issues, buggy and costly to maintain,
| and the language change was in part for the purpose of
| repointing the hiring pipeline toward a different kind of
| profile. Such special circumstances aside, I'm with you on
| recommending against rewrites. Much as I'm often tempted.
| tracker1 wrote:
| 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.
| hunterpayne wrote:
| > 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 use a language with
| functions as first class types (ie a FP language). You might
| say, most people doing ML use Python. This came to be because
| the language was picked based upon what people knew. But the
| big companies doing ML (successfully) don't use Python anymore
| and haven't for over a decade. ML researchers kept FP alive for
| several decades when nobody else cared because FP is the best
| tool for ML (or for writing a compiler). Where the FP folks get
| into trouble is trying to push FP where it doesn't make sense.
| I see this pattern repeating over and over again. Languages are
| pitched as silver bullets when they are just screwdrivers and
| hammers.
|
| Right tool for the job, ignoring this leads to "religious wars"
| because that's how we describe disputes which are matters of
| taste.
|
| Also, you are massively overvaluing expertise in a given
| language. A more talented engineer who doesn't know your
| favorite language after a couple of months will be better than
| you in your favorite language too despite your greater
| experience with that language.
| fabian2k wrote:
| 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.
| tracker1 wrote:
| I think you missed something...
|
| > ... or there are underlying reasons for a language shift.
|
| As to "best language" that is just as dogmatic as anything
| else... just look at the C/C++ vs. Rust divide in the Linux
| community.
|
| I think you are overestimating the value of a best fit
| language for any given task, especially those where there are
| a half dozen popular languages that more people know well
| that can do the job good enough. Don't build for a sky
| scraper when all you need is a birdhouse.
|
| Also, _MOST_ engineers aren 't particularly talented. If
| you're fortunate enough to be working for an organization
| where everyone is a rockstar, that's great... for those doing
| bog standard CRUD apps for business, you don't get rockstar
| money, and you aren't finding rockstar talent. You get what
| you get and make the pest of it.
|
| In nearly three decades, I've once, only once worked a
| project where I didn't have to explain a relatively simple
| concept to someone, where everyone on the project delivers
| their pieces in time and all were talented. It was wonderful.
| Then new management gets stacked on top, all the job roles
| are reclassified to mid level developers and everyone rolls
| out of that group.
|
| A lot of the actual experience is literally explaining
| public/private key usage to other developers who manage to
| (re)use the same keys from dev to all the production
| deployments. Or a pissing match with the "security expert"
| who doesn't understand that your app's use case is different
| than the in the box security script that is failing, because
| your /login route is a different app from / and the bogus
| query params don't matter.
| thomasmg wrote:
| > the language most of the team know the best
|
| I fully agree. The challenge is, some will want to use the
| latest languages and technologies because they want to learn it
| (personal development, meaning: the next job). Sometimes the
| "new thing" can be limited to (non-critical) testing and
| utilities. But having many languages and technologies just
| increases the friction, complicates things, and prevents
| refactoring. Even mixing just scripts with regular languages is
| a problem; calling one language from another is similar. The
| same with unnecessary remote APIs. Less technologies is often
| better, even if the technologies are not the best (eg. using
| PostgreSQL for features like fulltext search, event processing,
| etc.)
|
| This is a bit related to external dependencies vs build
| yourself (AKA reinvent the wheel). Quite often the external
| library, long term, causes more issues than building it
| yourself (assuming you _can_ build a competent implementation).
| kazinator wrote:
| People 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.
| egorelik wrote:
| 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.
| kstrauser wrote:
| 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 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.
| wiseowise wrote:
| > 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.
| cozzyd wrote:
| It CAN be.
|
| If a company chose brainfuck as a main programming language,
| it's doubtful they'd come back from that choice.
| twic wrote:
| 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.
| laxd wrote:
| 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.
| Arcuru wrote:
| This person appears to have been "Languages Product Lead at
| Google", so they are very used to arguing about how important
| language choice is.
| IshKebab wrote:
| 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 the article. He makes it
| sound like there isn't any difference between programming
| languages and any preference is purely about developer
| identity. But that identity doesn't come from nowhere. Rust is
| popular because a load of C++ developers finally found
| something technically better. Not because they all woke up one
| morning and decided to be "a Rust developer".
|
| Where the story falls apart is that Perl is arguably even worse
| than PHP. One deluded Perl programmer does not prove a
| principle.
|
| On Rust vs Go, he's absolutely right that Go is has a slightly
| better "build & deploy" story (though not by a much). But
| reading between the lines I think he's misrepresenting that -
| it sounds like a) that was just one point for choosing Rust,
| and b) that was a point when comparing to _typical_
| alternatives, e.g. C++ or Java. It 's not untrue that Rust is
| easy to build & deploy simply because Go is slightly easier.
| Jtsummers wrote:
| > 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.
| jack_tripper wrote:
| _> Getting past paradigms gives you much greater freedom to
| explore and participate in the world._
|
| It's not me who has problems getting past paradigms, or anyone
| else I know for that matter, it's the recruiters and HR people
| who screen resumes by only ticking boxes on buzzword.
| humanfromearth9 wrote:
| They are the cancer of our profession.
| ludicity wrote:
| Someone told me to read Meadows over a year ago, and I can no
| longer remember who, and to make it worse it slipped off my
| radar. I'm filled with regret now because they appear to be a
| concise and insightful thinker, or at least an effective
| proliferative of good ideas.
| Jtsummers wrote:
| No reason to regret, still time to read her works. That essay
| is also a chapter in her book _Thinking in Systems: A Primer_
| (publish posthumously), and more essays are on that site.
| bri3d wrote:
| 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.
| ludicity wrote:
| 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 if forced to. We can't ship if the feedback loop
| is a 30-minute CI pipeline because there is no way to have a
| local dev environment.
| Ocerge wrote:
| 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!
| bluGill wrote:
| I remember being there and the large amount of work many
| people did to make things better. Dig in for a few years
| and you can too.
| tyleo wrote:
| > 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.
|
| This is my experience too. I'd go a bit further and say the
| leads are the primary driver of success. Because ultimately, if
| the composition of the people on a project is incorrect, it's
| the lead's responsibility to realize and change it.
| seneca wrote:
| This is really the heart of it:
|
| > Don't get me wrong - to an extent, some languages (especially
| more niche ones) drive hiring and what kind of employee you get
|
| In my experience, the community around a given language is
| going to significantly influence the sort of typical applicant
| you get for a job working in that language. Those profile vary
| a surprising amount, especially for, as you say, niche
| languages, but also for "beginner" languages.
|
| I have seen businesses significantly harmed because they hired
| what I would term language specific technicians instead of
| engineers. That's a failure of leader, certainly, but that
| failure is a lot more likely for certain languages.
| bri3d wrote:
| > they hired what I would term language specific technicians
| instead of engineers.
|
| I have seen this too, and I really like the way you phrased
| it - I think I'll use that in the future!
|
| I do think it's an easier trap to fall into with some
| languages, but I still don't think the language really drives
| it.
|
| I worked on a large-scale Rust project that could probably
| have been a Go project a while ago and while Language
| Technicians were a big hiring hazard, after we got one or two
| we both learned how to manage them and stopped hiring that
| type of employee (since they weren't what our project needed)
| and things evened out and were successful in Rust.
| seneca wrote:
| > I do think it's an easier trap to fall into with some
| languages, but I still don't think the language really
| drives it.
|
| Yeah, in the end poor hiring practices drive it. The
| language you choose just makes the probability of that
| failure possibility higher or lower.
|
| > I worked on a large-scale Rust project that could
| probably have been a Go project a while ago and while
| Language Technicians were a big hiring hazard, after we got
| one or two we both learned how to manage them and stopped
| hiring that type of employee (since they weren't what our
| project needed) and things evened out and were successful
| in Rust.
|
| That tracks with my experience, for sure. Once you learn to
| spot it, you can mitigate it.
| jerf wrote:
| "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 language decisions.
|
| I'm going to exaggerate to make the point in an attempt to
| avoid too much argument about whether or the language would be
| suitable, but: You do not sit down to write an industry-
| leading, high-performance database whose top-level
| implementation language is Python. If your project spec
| involves running code provided at runtime by users, Go is a
| fairly poor choice. You can make things a _lot_ harder for
| yourself trying to be too insistent about what language you 'll
| do your mobile development in, rather than just accepting that
| there's a very dominant choice in those spaces.
|
| I've also seen projects I couldn't prove to you beyond a shadow
| of a doubt failed due to language selection, but I am fairly
| certain the project I saw that chose Scala failed primarily for
| the choice of Scala where it was a bad fit, both technically
| and for the skillsets of the engineers involved.
|
| I've also seen projects nearly fail because they chose
| databases incorrectly, which I would submit is a fairly similar
| thing. Mostly because of choosing a NoSQL database "because
| fast" when they should have used a relational DB. The projects
| in question didn't fail because they were able to switch in
| time, but it was a close thing.
|
| Part of "the composition of the employees of a project" being
| responsible for its success is that good engineers pick at
| least a _decent_ solution to a problem from day one. The
| aforementioned DB problem, for instance, should have been
| obvious from the very beginning that it was not the correct
| choice in their case. There are absolutely wrong choices, that
| can crash projects both quickly and slowly.
| tyleo wrote:
| 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.
| jerf wrote:
| Absolutely agree. People made the bad decisions. But the
| bad choices existed. People who don't understand the bad
| choices are bad choices, or worse, think that there is no
| possible way there is a bad choice, are far more likely to
| end up being those people who made bad decisions then
| people who understand that the decisions mattered.
|
| Don't go running around telling people that they can dig
| the Panama Canal with three toothpicks and a spare weekend,
| and if they fail, well by golly they just didn't have
| enough grit and gumption like us awesome folks who could
| have done it with only two. Tool choice matters. In fact I
| can hardly process how anyone can be an engineer and think
| that it doesn't, let alone how they can think it's some
| sort of engineering _wisdom_ to claim that it doesn 't
| matter what tools you use to do a project.
|
| Of course, picking the tool is only the moment the project
| may fail. It is not the moment the project succeeds;
| there's still a lot of using it correctly that will be
| necessary and plenty of further opportunities to fail even
| with the correct tool. But at least success is within the
| range of possibilities. You can forstall that possibility
| entirely on day one with incorrect tool choices.
| bri3d wrote:
| > Tool choice matters. In fact I can hardly process how
| anyone can be an engineer and think that it doesn't, let
| alone how they can think it's some sort of engineering
| wisdom to claim that it doesn't matter what tools you use
| to do a project
|
| Just to be clear, I wasn't trying to claim this; tooling
| certainly matters, at the very least, for the happiness
| and welfare of an engineering team! But, the article
| tries to claim things like "choosing a programming
| language is the single most expensive economic decision
| your company will make" and outside of a few extreme edge
| cases, I just can't agree with that particular thesis.
| Even the examples of bad decision-making you pose in your
| sibling comments, like writing a database in Go or
| "almost failing" by using sketchy niche datastores, are
| actually examples of this exact thing: these projects
| made huge engineering mistakes only to achieve some level
| of success as a business. Would they have been more
| successful if they made better engineering decisions?
| Possibly, but again, language and framework just was not
| the most important decision or factor driving an outcome.
|
| I'm not saying that means we shouldn't care about making
| good engineering choices; there are easy ways to do
| things and hard ways to do things, and certainly I'm
| going to advocate for and work with people and at
| companies that favor the easy ways to do things. But when
| it comes to overall outcomes, I'll stand by having seen
| far more projects sacrificed to analysis paralysis,
| rewrites, rewrite-related hand wringing, and
| language/tooling hubris than sabotaged by poor language
| and framework choices.
| bdangubic wrote:
| great team can write amazon clone in fortran. bad team cannot
| write todo list clone in... well anything :)
|
| it is (almost) always people and (almost) never
| language/framework/...
| jerf wrote:
| The great team would not have written the Amazon clone in
| Fortran. There is no engineering justification for such a
| choice, and "we are swaggeringly awesome engineers who can
| conquer anything" is not even remotely an engineering
| justification.
| bluGill wrote:
| If you are starting from scratch fortran is a bad choice.
| However if you have a fortran project that keeps getting
| more features you may become an amazon clone along the
| way
| pyrale wrote:
| > I've seen it. There are definitely incorrect language
| choices for certain projects.
|
| I guess we can all agree that writing your web application
| using a fortran framework to generate JS code is a bad idea.
|
| But if you pick tfa's second example, picking Go vs. Rust for
| a new project, the language choice is secondary. Both
| languages were likely fine unless the project as a specific
| library requirement.
|
| The main criteria to make the choice was likely whether the
| team had developers with some experience in that language,
| and whether using that language would make them feel dead
| inside in the morning when they check in ; and I'm pretty
| sure developers can be found that make either choice a great
| choice.
|
| The point tfa's making, that picking a language defines
| culture, the hiring pipeline etc. is fitting neither the
| first example (team already there, and a rewrite is almost
| always a bad choice) nor the second example (team also
| already there, and the culture with them. Pipeline therefore
| irrelevant).
| jerf wrote:
| 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 up holding back the company that
| makes that decision in the end.
| Animats wrote:
| > 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.
| jaggederest wrote:
| There are at least a dozen new databases in the market
| making decent money that were started this decade.
|
| They're just not competing with Oracle.
| bluGill wrote:
| A large part of success is picking a goal that is
| obtainable.
| hshdhdhehd wrote:
| 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).
| fabian2k wrote:
| 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.
| OkayPhysicist wrote:
| 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.
| tcfhgj wrote:
| > Switching from C++ to Rust? Probably not.
|
| Counter example:
|
| https://fishshell.com/blog/rustport/
| bri3d wrote:
| FWIW, this was an intelligent rewrite, piece by piece. This
| is the only way I have ever seen "rewrite it in X" ever
| work. Fish also isn't a commercial product, so the calculus
| is a little different.
| mamcx wrote:
| > I cannot agree that programming language choice is a primary
| driver in a product's success or failure....
|
| This and similar are common ideas for the people that never see
| the _real whole world_ of programming, and maybe have the
| fortune of be in the "startup" circles.
|
| I see the opposite, and is very good predictor to know how bad
| a product or a team is, using the programming language AND the
| main DB engine, but that is because I live in the world of
| "enterprise" code where for example:
|
| * I'm called to do a rewrite
|
| * I see the _screenshot_ of the main app
|
| * I guess correctly was made with _vb_ (first big alarm) (how I
| know: I never see _in my circle_ anybody that do vb, php, c,
| c++ anything resembling a sane UI. BTW just the use of colors
| was enough to guess)
|
| * I worry, but confirm, that use _Access_ as the main db
|
| * I discover that part of the data was ALSO in a _excel file_ ,
| that is used with the equivalent of "joins", and was not
| surprised to see things like this
|
| Even without knowing more about the people that do it, that is
| far enough signals to guess much.
|
| BTW, there are very good predictors, if Use: MySql, MonGo, Php,
| Js (almost whatever you wanna add here in terms of frameworks),
| VB, Perl, Android (aka: Java android and android itself without
| using iOS alongside), is likely terrible. Then Java or C#
| taking turns how much worse, but not as bad as the ones before.
| I sweat if somebody say it use C or C++. Probably enough to
| straight refuse to take the project.
|
| Any use of not-obscure tech in this sector and is a good
| predictor to be more or less not-that-bad.
|
| BTW: Also complex infra and related boilerplate is now probably
| a stronger predictor after some langs like python, go,
| typescript and more modern java/kotlin/c# has spread (and also
| more pg and much less nosql, but too much "cloud")
| jjmarr wrote:
| 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.
| pron wrote:
| 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?
| lordnacho wrote:
| 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.
| tailrecursion wrote:
| > 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.
| lordnacho wrote:
| Nah, I spent a short time with Java and a lot of time with
| c++.
| fragmede wrote:
| > 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!)
| levodelellis wrote:
| Isn't this what Joel wrote 25 years ago? Don't rewrite your
| software?
|
| 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
| tailrecursion wrote:
| Let the team choose the language they're most familiar with or
| most happy with. Then if they choose the wrong one, get a
| different team.
| romaniv wrote:
| > 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.
| tailrecursion wrote:
| The story at the beginning proves that choosing your VP is
| significantly more important than choosing a PL.
| Animats wrote:
| 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.
| egorelik wrote:
| As far as I'm aware, Rust's trait system is more closely
| related to Haskell's type class system than to actual object-
| oriented programming. As a type class system, it is fine; it is
| a different mindset than classic OOP. Rust happens to also use
| this same system for something more closely resembling
| traditional objects, but this is much more restricted than
| either.
| ForHackernews wrote:
| 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.
| keybored wrote:
| Please spare us the typical
|
| - 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.
| scuff3d wrote:
| In my experience "choose the right tool for the job" almost
| always translates into "pick the tool you like most and justify
| it later".
| taeric wrote:
| This falls into the "people aren't rational/logical" trap. You
| really have to define what you would mean for it to be rational.
| And then you have to establish what the baseline ideas are from
| which you plan on establishing the logic/rationality. All the
| while, you need to really resist any "just so" stories that would
| explain anything.
|
| Worse, this also falls into the trap of thinking you have to make
| a choice, and that an informed choice is better than chance.
| Reality is that you are often best trying to do both, and then
| having some sort of coin flip to disambiguate choices works far
| better than we'd like to admit. In large part for the simple
| reason that simply doing something is more than a lot of your
| competitors will be doing.
___________________________________________________________________
(page generated 2025-11-03 23:01 UTC)