7 ms·

Why engineers can't be rational about programming languages

164 points by spf13 11mo ago

scuff3d 11mo ago
In my experience "choose the right tool for the job" almost always translates into "pick the tool you like most and justify it later".
bobx17 11mo ago
We see the "we need to rewrite in X" conversation play out all the time here on HN. Love this take on it.
- lproven 11mo ago
  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.
didibus 11mo ago
> 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 11mo ago
  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 11mo ago
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 11mo ago
  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 11mo ago
    > 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 11mo ago
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 11mo ago
  > 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 11mo ago
    Reason #9 will shock you!
  - esafak 11mo ago
    I did not. I read the comments and still found little reason to check the article.
- wvenable 11mo ago
  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 11mo ago
    Why would management care about tools?
    - hunterpayne 11mo ago
      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.
btilly 11mo ago
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-egoless-programming/ 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 11mo ago
  > 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 11mo ago
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 11mo ago
  Indeed, and the perhaps canonical article on "don't rewrite" from 2000: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- tracker1 11mo ago
  VB.Net winforms app from 2005?
- wvenable 11mo ago
  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 11mo ago
  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.
- lproven 11mo ago
  This is true, but the article is not about rewriting.
tracker1 11mo ago
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 11mo ago
  > 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.
kazinator 11mo ago
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 11mo ago
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.
- lproven 11mo ago
  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.
kstrauser 11mo ago
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.
- cweagans 11mo ago
  > It's not like a team wanted to rewrite it in PHP, which we can all at least agree would be madness. That seems like the same argument that TFA is making, but in reverse. I think it's just as invalid. PHP is a perfectly fine language for many things. There is plenty of greenfield development being done in PHP these days + a substantial amount of PHP in production all over the place. Unilaterally writing it off as "madness" seems pretty disingenuous to me.
  - kstrauser 11mo ago
    Congratulations for getting the point of the article. :)
wiseowise 11mo ago
> 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 11mo ago
  It CAN be. If a company chose brainfuck as a main programming language, it's doubtful they'd come back from that choice.
  - twic 11mo ago
    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 11mo ago
      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.
      - avadodin 11mo ago
        that comment is probably referring to VisualBasic 6.0 which was not a dialect of C# like VB.NET but then again your product from the 90s likely started off as that
    - wiseowise 11mo ago
      > A company that chose Visual Basic or Perl would have had a much harder road than one which chose C# or Python. Based on what? Economics define where you go, not language. If company using Perl or VB has steady cash flow and their bottleneck is language - they’ll just rewrite when it makes sense. No amount of writing in C# or Python from scratch will save you if your product is garbage.
Jtsummers 11mo ago
> 1. The power to transcend paradigms. - Donella Meadows, Leverage Points: Places to Intervene in a System https://donellameadows.org/archives/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 11mo ago
  >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 11mo ago
    They are the cancer of our profession.
  - bmitc 11mo ago
    Engineers are also part of the problem, as not every engineer avoids myopia.
    - jack_tripper 11mo ago
      Feel free to speak for yourself. This is not representative of me or anyone I know.
      - bmitc 11mo ago
bri3d 11mo ago
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 11mo ago
  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 11mo ago
    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!
oldpersonintx2 11mo ago
[dead]
jjmarr 11mo ago
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.
- kagakuninja 11mo ago
  Young Padawan, C++ was once a cool language, and I had to battle at multiple companies before I was finally able to make the career switch from C. The conventional wisdom was "Where will we get C++ programmers?", "We don't have experience with C++", "C++ is too bleeding edge", and so on. The same excuses people give today to not use Rust, or your favorite hyped language. If we follow the logic of OP, we will almost never develop new languages, because there are already multiple established languages good enough for any task at hand.
- morshu9001 11mo ago
  I've been in situations where we use C++ for no good reason, and it's just cause the others hate the "noob" ones like Python or JS.
pron 11mo ago
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?
- wrathofmonads 11mo ago
  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).
  - pron 11mo ago
    Python is doing very well, and the really good thing about established languages is that their pros and cons are known. Not many people would choose Python to write a high-performance server or a program that's expected to grow to a million lines or so, and if they do, they have no one but themselves to blame. With newer or less popular languages, you might not know what you're really getting yourself into, and if, five or seven years in, you end up not where you wanted, well, you also have no one but yourself to blame.
lordnacho 11mo ago
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 11mo ago
  > 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 11mo ago
    Nah, I spent a short time with Java and a lot of time with c++.
levodelellis 11mo ago
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
- lproven 11mo ago
  That is not what the article is about. The subject is right there in the title: Engineers Can't Be Rational About Programming Languages
tailrecursion 11mo ago
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 11mo ago
> 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 11mo ago
The story at the beginning proves that choosing your VP is significantly more important than choosing a PL.
Animats 11mo ago
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 11mo ago
  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.
tug2024 11mo ago
[dead]
ForHackernews 11mo ago
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 11mo ago
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.
taeric 11mo ago
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.
isaacremuant 11mo ago
> A programming language is the single most expensive choice a company makes, False. Next.
m0llusk 11mo ago
It is the language, available tools and libraries, and the community. As a programming snob the fact that most of my coding is now done in Javascript is a threat to my identity managed with a handful of clearly reasoned explanations. This choice works with tools and libraries that support my needs and there are always more experienced programmers that can be called on when help is required.
- morshu9001 11mo ago
  I also avoided JS for no good reason until one day
  - rkomorn 11mo ago
    Until one day you stopped avoiding it, or you found a good reason?
    - morshu9001 11mo ago
      I stopped avoiding it.
morshu9001 11mo ago
They can be, especially those who have deeply used multiple langs
antfarm 11mo ago
For anyone interested: Takkle was "a social networking and media site geared toward those involved in high school sports: players, coaches, and fans" as per this article from 2006, aptly titled "Takkle.com, social networking for jocks". [https://www.cnet.com/tech/services-and-software/takkle-com-social-networking-for-jocks/ https://www.cnet.com/tech/services-and-software/takkle-com-s...]
msteffen 11mo ago
I love the author's argument, but this conclusion feels obvious to me—rationalizing emotional decisions is like the oldest human activity there is. Try asking somebody why they're whatever-religion or whatever-political-party that their parents, friends, or partner is/are. I further claim that much of the purpose of managers is to do this for individual contributors: give people a story that scaffolds a decision you hope they'll make: staying at the company and going along with whatever decision has just been announced. I also don't think it's necessarily bad that people do this. The input to any decision a person makes includes their entire life experience up to that point[1]. How could an executive encode all that in some kind of pat logical explanation, and how could the also-human engineers at the company possibly digest such an explanation, and what could make it more compelling to them than their own life experiences? People need to get through life, though, so they need to make decisions. They can't fully rationalize every single one, but they want to feel at least OK about the decisions they're making, so they tell themselves and each other these incomplete little stories and get on with it. That managers scaffold this process with their own stories is a little manipulative, but how else could people cooperate enough to have companies? The whole process just seems intrinsically human to me. The most important part of being an executive is understanding all of this and choosing to hire people who will ultimately make good strategic decisions for you. Don't hire a well-known Perl contributor as your CTO unless you like the idea of rewriting your product in Perl. If your company is dying because this has happened, my condolences but at least you're not alone. Edit: I hadn't read this far when I wrote the comment but the author also literally says, "The moment you hire a Rust developer to evaluate languages, you’ve already chosen Rust." I guess I just disagree that it could work differently. Each of us possesses bounded knowledge and bounded rationality, and "which language is best", is probably too complicated for an individual to figure out, especially when you don't even know what the roadmap will be in a year—you'd have to build the company several times in several languages and compare the results (and the best engineers I've met do write code multiple times, but rarely more than twice IME). Each of us can only really know how we would solve the company's problems. Executives' job is to try and guess, and make decisions that are ideally optimal but at least internally consistent. [^1] My favorite example of this, actually: even in the highly-rational field of scientific research, scientists have to decide whether a given body of evidence is dispositive of a particular theory, and the standards they apply likewise depend on who they are and what their life experience is. So, as Max Planck put it, science advances one funeral at a time.
ModernMech 11mo ago
The thing people get but don't really want to admit to themselves is that programming languages are cults to some degree. We understand this when we talk about the irrationality of the language flame wars. Back in the Slashdot days we joked about it explicitly. So in that tradition: I don't want to start a holy war but... You've got all the ingredients. First and foremost the BDFL. He's the cult leader, coming in with a new "way of thinking" which, if you follow his rules (the language) will lead to a better life (better code, better career, personal enlightenment, righteousness, purity, becoming closer to the machine (god)). Often times this is expressed in terms that even he cannot quantify -- the language is "efficient", "advanced", "secure", or "modern". But the point of the language is, if you only adhere to these dogmas (everything is an object/table/function, everything must be immutable), then your life will be filled with fast/efficient/secure code (again, can't really quantify it). Some of them even sell you a "purist" cult -- "we don't sling dirty imperative code here, our code is pure functional, which is closer to the ideal (god/the word of the BDFL) and therefore good". Lispers figuratively go there saying things like Lisp is the language of God. HolyC (TempleOS) literally goes there with claims the project is a word from God. Now, there's mental illness mixed in with that (but would you believe me if I told you many language designers suffer from mental illness? At least every one I've known. If anything, there's a good deal of narcissism and delusions of grandeur in this community, which incidentally you'll also find in cult leaders). Of course like any good cult, aesthetics are enforced. You can't just program in the language, you have to program the way everyone else programs. Take the Zen of Python, which preaches a sort of asceticism. Some cults are about "beautiful" code, that looks "clean" and is free of anything impure like certain syntax or even specific characters that are thought to be a nuisance. The key to all of this is it has nothing really to do with the essence of the language. Just having these elements floating around is enough for people to glom on and stick around. You don't even need to have an actual language to form on of these cults, look at Jai. There the BDFL has held back his language for about a decade, promising to release it but never actually doing so, which paradoxically keeps people holding out to receive the forbidden knowledge he is keeping from them. We've got our holy books of course. The language spec holds all the keys to understanding the word of the BDFL, although the number of people who have actually read it compared to use the language rounds to 0. Not only because these specs and docs can be voluminous, but also sometimes they are written purposefully to be inscrutable. See "Nock" and "Hoon". Half of understanding those things is just getting your head wrapped around the jargon, which itself is meant to be exclusionary -- if only the authors can read it, it puts them in a special place of translating the holy texts so that mere mortals might understand their wisdom (it also means that if anyone disagrees with them, they can just insist the texts are being translated wrong). Other times there are style guides which tell you the one true way to read and write the language. Then there are the various blogs and tutorials which are the equivalent of sermons, spreading the good word to the masses. Speaking of the masses, that brings us to the community! That's us, we are the cultists! The community will defend the BDFL to the death, and attack anyone who questions the dogma. You see this all the time in language communities, where any criticism of the language is met with vitriol and ad hominem attacks. Usually the BDFL treats people this way, and his community sees it a sign of strength, so they emulate it. Although The community is often more zealous than the BDFL themselves, going out of their way to convert others to the faith. We see that from time to time on HN, when people show up here from some lang community and they get way too into it, to the point their lang is flagged here every time it's posted (not even gonna name them because they'll be here to say something). They will also police the community, ensuring that everyone adheres to the dogma and punishing those who stray from the path. This is often done through social pressure, other times it's through explicit excommunication (banhammer). Which leads to sects! I mean forks! When a language community gets big enough, you start to see splinter groups forming. Tensions rise in the community around aesthetics, features, or very often how the community is being (mis)managed, how the BDFL is leading or ignoring users. Eventually you get a Martin Luther type who strikes out and forks the cult intending to create their own cult. We saw this with projects like Elm stagnating as the BDFL continued to bless certain packages but refused this access to the rest of the community, so forks starting to appear. Or look at the recent controversy with Nim and the Nimony fork. And let me tell you, as someone who was a dev for a PL and saw how these things started off, you really attract... interesting folks when it comes to a brand new language. For the thing I was involved with, it was just one person after another who had some out-there idea thy wanted to glom onto the language. Stuff like "vorpal math"... whatever that is. So, yeah that's the kind of people you start out with in the early days if you're lucky, because no one else is paying attention to the niche PL scene except the vorpal math guys, who are primed to receive any kind of special knowledge from a cult leader. You collect a couple of these followers, they become true believers, and then you grow from there. It's not too hard, but it's very unstable, so most communities don't get too big as the BDFL loses interest himself, or he can't keep the hype going. Once in a while you get guys like Yarvin who really run a grift over a looooong period of time -- with Urbit they were literally selling virtual land plots to their community. So just like actual cults, there's also a grift to run when it comes to languages (languages are not profitable at scale, but they can be profitable if you know how to grift). Now I'm not saying all languages are cults. But I think the fastest way to build a language from nothing into something somewhat active is to lean into the cult-like aspects to entice people in. Because otherwise the language has to stand on its merits, and small languages can't. So they have to stand on a promise of heaven that may or may not materialize (it probably won't), which is the basis of the cult. Because to keep the movement going, the cult leader either has to deliver nirvana, or keep promising it's just around the corner. Maybe it will be, but it's very easy to waste a decade of one's time hanging on to some lang dev waiting for him to drop the next update which will fix everything, but it never comes.
uvaursi 11mo ago
Software “engineer”[0] here. There are plenty of developers that are very rational about programming languages. I think the author lived in a weird bubble for most of their life jumping from company to company, project to project and saw some unhealthy development teams along the way. Developers make very rational decisions around PLs all the time, and the most rational choice, as also given by PG and Joel Spolsky many moons ago, is pick the language you’re most comfortable with and get over your shit. The second most rational choice is picking a language that fits the problem space like a glove. The third, most obvious rational choice of course, is Rust. [0] you sweet summer child.
getnormality 11mo ago
Maybe the Perl CTO wanted the product in Perl and not PHP because he knew Perl and didn't know PHP? Do we really need all this psychoanalysis and identity stuff to explain that?
- etothet 11mo ago
  This is often the real driver in these decisions. A previous company I worked at had an API written in modern PHP with Laravel. Traffic wasn’t very heavy on most days and we could autoscale when it was required. It worked great and we hadn’t encountered business problems that couldn’t be fairly easily solved within the ecosystem. However, one of the execs on the business side knew some other exec at a big tech company who told our guy that “PHP can’t scale”. So then we get questions if we should we consider rewriting, if we’re using the “best” language for our needs, etc. They wanted to plan for some theoretical future that they couldn’t even define from a business sense. Sure, it’s good to be aware of future business needs so that we, as technical people, can be asking the right questions to prepare for what that future may look like, but that almost never means a decision about language x over language y. It’s much deeper than that.
- lproven 11mo ago
  > Maybe the Perl CTO That's an example. It is not the subject under discussion.
dh2022 11mo ago
Rather than bet the company on a programming language I would prefer to be able to use different languages in an interoperable-fashion.
ChicagoDave 11mo ago
I’d have agreed with this three years ago, but GenAI has made me language agnostic. I’ve created apps with Typescript, Rust, Python, and completely open on more even though my background is 20 years in C#.
danans 11mo ago
If you are are starting from scratch, isn't the answer to which language to use just "the framework that best supports the business case and problem you are working on"? If that produces many options, then choose based on the team's familiarity with the language, frameworks, and ecosystems. A good software engineer should be pretty language agnostic when it comes to work, even if they have a personal aesthetic or technical preference.
- lproven 11mo ago
  The point of the article is that if you attempt to find > "the framework that best supports the business case and problem you are working on" by asking the people who will be using it, then the answer will almost certainly be wrong. The whole point here is working out which is the best tool is almost impossible because of natural human cognitive biases. TL;DR summary: No. No, that isn't the answer. It's not even an answer. It's the answer to a different question.
insane_dreamer 11mo ago
> “Everyone’s talking about Rust.” There it was: a 50 million dollar decision made on hype, about to be green lit. I've seen this with React. You might have a great website working with some solid MVC framework + good'ol jQuery or equivalent, but no, the whole thing has to be rewritten from scratch to be an SPA in React, to "keep up".
phibz 11mo ago
Isn't senior leadership choosing languages or core technology, doing things wrong? Shouldn't senior leadership focus on outlining the business opportunities, value case, and requirements for their solution?
- lproven 11mo ago
  No? The point of the article is that if you delegate this choice, the people to whom you delegate it will get it wrong.
js-j 11mo ago
For some time now, I've come to the conclusion that the choice of a programming language is of crucial importance to the success of a project: programmers are inspired by beautiful tech solutions, that's what motivates them to give the best of themselves. PHP has never been such a piece of technology for me, whereas Perl used to be...
tpoacher 11mo ago
Bulverism
- lproven 11mo ago
  https://en.wikipedia.org/wiki/Bulverism https://en.wikipedia.org/wiki/Bulverism Hardly, no. The entire point of the article is pointing out an entirely different cognitive fallacy.
  - tpoacher 11mo ago
    It's Bulverism because first you need to defend and establish that your proposition is true before you can start explaining "why" it is true. At the very least the title is clear Bulverism. Admittedly, I did enjoy the article, even if I was initially a bit predisposed not to from the title. And I think the quote "if you hire a rust evangelist to choose your programming language, you've already chosen rust" is very insightful. But the author still goes into zero depth to asses to what extent rationality of language choice is a widespread problem, as opposed to isolated cases they've seen during their career. Which is ironic given that their thesis is that people go into topics emotionally without weighing them factually against the ground truth.
    - lproven 11mo ago
      He established his proposition in the opening paragraphs -- the ones that most HN commentators have seized up and not even noticed the actual argument and discussion. AFAICS you don't seem to have even noticed the initial example.
      - tpoacher 10mo ago
        I hope the irony that your argument is now the Bulverist one is not lost on you :D
dzonga 11mo ago
> “which language is best?” we need to ask “what is this language going to cost us?” Not just in salaries, but in velocity, in technical debt, in hiring difficulty, in operational complexity, in every dimension that actually determines whether you survive. then boom suddenly php, ruby & java are pragmatic choices in economic sense for business systems. same as c++ for hedge funds & video games etc.
anon291 11mo ago
Same reason you can't be rational about human language. People claim religion, but actually language is a better proxy for ethnic conflict.
louisashbourne 11mo ago
[flagged]
pjmlp 11mo ago
Very well put article, every single time I see a session like that I also ask about the business cost evaluation, especially regarding rewrites. Have they done in math in FTE salaries, times the estimated effort in days, mappend into money, and what is the expectation of ROI in that investment.
tsenturk 11mo ago
Developers chase hype technologies out of fear of becoming outdated, but they abandon these trendy programming languages just as quickly as they adopt them.

164 points by spf13 11mo ago

In my experience "choose the right tool for the job" almost always translates into "pick the tool you like most and justify it later".

bobx17 11mo ago

We see the "we need to rewrite in X" conversation play out all the time here on HN. Love this take on it.

lproven 11mo ago
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.

didibus 11mo ago

> 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 11mo ago
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 11mo ago

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 11mo ago
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 11mo ago
  > 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 11mo ago

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 11mo ago
> 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 11mo ago
  Reason #9 will shock you!
- esafak 11mo ago
  I did not. I read the comments and still found little reason to check the article.
wvenable 11mo ago
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 11mo ago
  Why would management care about tools?
  - hunterpayne 11mo ago
    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.

btilly 11mo ago

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-egoless-programming/ 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 11mo ago
> 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 11mo ago

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 11mo ago
Indeed, and the perhaps canonical article on "don't rewrite" from 2000: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
tracker1 11mo ago
VB.Net winforms app from 2005?
wvenable 11mo ago
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 11mo ago
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.
lproven 11mo ago
This is true, but the article is not about rewriting.

tracker1 11mo ago

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 11mo ago
> 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.

kazinator 11mo ago

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 11mo ago

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.

lproven 11mo ago
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.

kstrauser 11mo ago

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.

cweagans 11mo ago
> It's not like a team wanted to rewrite it in PHP, which we can all at least agree would be madness. That seems like the same argument that TFA is making, but in reverse. I think it's just as invalid. PHP is a perfectly fine language for many things. There is plenty of greenfield development being done in PHP these days + a substantial amount of PHP in production all over the place. Unilaterally writing it off as "madness" seems pretty disingenuous to me.
- kstrauser 11mo ago
  Congratulations for getting the point of the article. :)

wiseowise 11mo ago

> 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 11mo ago
It CAN be. If a company chose brainfuck as a main programming language, it's doubtful they'd come back from that choice.
- twic 11mo ago
  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 11mo ago
    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.
    - avadodin 11mo ago
      that comment is probably referring to VisualBasic 6.0 which was not a dialect of C# like VB.NET but then again your product from the 90s likely started off as that
  - wiseowise 11mo ago
    > A company that chose Visual Basic or Perl would have had a much harder road than one which chose C# or Python. Based on what? Economics define where you go, not language. If company using Perl or VB has steady cash flow and their bottleneck is language - they’ll just rewrite when it makes sense. No amount of writing in C# or Python from scratch will save you if your product is garbage.

Jtsummers 11mo ago

> 1. The power to transcend paradigms. - Donella Meadows, Leverage Points: Places to Intervene in a System https://donellameadows.org/archives/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 11mo ago
>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 11mo ago
  They are the cancer of our profession.
- bmitc 11mo ago
  Engineers are also part of the problem, as not every engineer avoids myopia.
  - jack_tripper 11mo ago
    Feel free to speak for yourself. This is not representative of me or anyone I know.
    - bmitc 11mo ago

bri3d 11mo ago

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 11mo ago
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 11mo ago
  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!

oldpersonintx2 11mo ago

[dead]

jjmarr 11mo ago

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.

kagakuninja 11mo ago
Young Padawan, C++ was once a cool language, and I had to battle at multiple companies before I was finally able to make the career switch from C. The conventional wisdom was "Where will we get C++ programmers?", "We don't have experience with C++", "C++ is too bleeding edge", and so on. The same excuses people give today to not use Rust, or your favorite hyped language. If we follow the logic of OP, we will almost never develop new languages, because there are already multiple established languages good enough for any task at hand.
morshu9001 11mo ago
I've been in situations where we use C++ for no good reason, and it's just cause the others hate the "noob" ones like Python or JS.

pron 11mo ago

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?

wrathofmonads 11mo ago
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).
- pron 11mo ago
  Python is doing very well, and the really good thing about established languages is that their pros and cons are known. Not many people would choose Python to write a high-performance server or a program that's expected to grow to a million lines or so, and if they do, they have no one but themselves to blame. With newer or less popular languages, you might not know what you're really getting yourself into, and if, five or seven years in, you end up not where you wanted, well, you also have no one but yourself to blame.

lordnacho 11mo ago

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 11mo ago
> 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 11mo ago
  Nah, I spent a short time with Java and a lot of time with c++.

levodelellis 11mo ago

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

lproven 11mo ago
That is not what the article is about. The subject is right there in the title: Engineers Can't Be Rational About Programming Languages

tailrecursion 11mo ago

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 11mo ago

> 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 11mo ago

The story at the beginning proves that choosing your VP is significantly more important than choosing a PL.

Animats 11mo ago

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 11mo ago
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.

tug2024 11mo ago

[dead]

ForHackernews 11mo ago

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 11mo ago

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.

taeric 11mo ago

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.

isaacremuant 11mo ago

> A programming language is the single most expensive choice a company makes, False. Next.

m0llusk 11mo ago

It is the language, available tools and libraries, and the community. As a programming snob the fact that most of my coding is now done in Javascript is a threat to my identity managed with a handful of clearly reasoned explanations. This choice works with tools and libraries that support my needs and there are always more experienced programmers that can be called on when help is required.

morshu9001 11mo ago
I also avoided JS for no good reason until one day
- rkomorn 11mo ago
  Until one day you stopped avoiding it, or you found a good reason?
  - morshu9001 11mo ago
    I stopped avoiding it.

morshu9001 11mo ago

They can be, especially those who have deeply used multiple langs

antfarm 11mo ago

For anyone interested: Takkle was "a social networking and media site geared toward those involved in high school sports: players, coaches, and fans" as per this article from 2006, aptly titled "Takkle.com, social networking for jocks". [https://www.cnet.com/tech/services-and-software/takkle-com-social-networking-for-jocks/ https://www.cnet.com/tech/services-and-software/takkle-com-s...]

msteffen 11mo ago

I love the author's argument, but this conclusion feels obvious to me—rationalizing emotional decisions is like the oldest human activity there is. Try asking somebody why they're whatever-religion or whatever-political-party that their parents, friends, or partner is/are. I further claim that much of the purpose of managers is to do this for individual contributors: give people a story that scaffolds a decision you hope they'll make: staying at the company and going along with whatever decision has just been announced. I also don't think it's necessarily bad that people do this. The input to any decision a person makes includes their entire life experience up to that point[1]. How could an executive encode all that in some kind of pat logical explanation, and how could the also-human engineers at the company possibly digest such an explanation, and what could make it more compelling to them than their own life experiences? People need to get through life, though, so they need to make decisions. They can't fully rationalize every single one, but they want to feel at least OK about the decisions they're making, so they tell themselves and each other these incomplete little stories and get on with it. That managers scaffold this process with their own stories is a little manipulative, but how else could people cooperate enough to have companies? The whole process just seems intrinsically human to me. The most important part of being an executive is understanding all of this and choosing to hire people who will ultimately make good strategic decisions for you. Don't hire a well-known Perl contributor as your CTO unless you like the idea of rewriting your product in Perl. If your company is dying because this has happened, my condolences but at least you're not alone. Edit: I hadn't read this far when I wrote the comment but the author also literally says, "The moment you hire a Rust developer to evaluate languages, you’ve already chosen Rust." I guess I just disagree that it could work differently. Each of us possesses bounded knowledge and bounded rationality, and "which language is best", is probably too complicated for an individual to figure out, especially when you don't even know what the roadmap will be in a year—you'd have to build the company several times in several languages and compare the results (and the best engineers I've met do write code multiple times, but rarely more than twice IME). Each of us can only really know how we would solve the company's problems. Executives' job is to try and guess, and make decisions that are ideally optimal but at least internally consistent. [^1] My favorite example of this, actually: even in the highly-rational field of scientific research, scientists have to decide whether a given body of evidence is dispositive of a particular theory, and the standards they apply likewise depend on who they are and what their life experience is. So, as Max Planck put it, science advances one funeral at a time.

ModernMech 11mo ago

The thing people get but don't really want to admit to themselves is that programming languages are cults to some degree. We understand this when we talk about the irrationality of the language flame wars. Back in the Slashdot days we joked about it explicitly. So in that tradition: I don't want to start a holy war but... You've got all the ingredients. First and foremost the BDFL. He's the cult leader, coming in with a new "way of thinking" which, if you follow his rules (the language) will lead to a better life (better code, better career, personal enlightenment, righteousness, purity, becoming closer to the machine (god)). Often times this is expressed in terms that even he cannot quantify -- the language is "efficient", "advanced", "secure", or "modern". But the point of the language is, if you only adhere to these dogmas (everything is an object/table/function, everything must be immutable), then your life will be filled with fast/efficient/secure code (again, can't really quantify it). Some of them even sell you a "purist" cult -- "we don't sling dirty imperative code here, our code is pure functional, which is closer to the ideal (god/the word of the BDFL) and therefore good". Lispers figuratively go there saying things like Lisp is the language of God. HolyC (TempleOS) literally goes there with claims the project is a word from God. Now, there's mental illness mixed in with that (but would you believe me if I told you many language designers suffer from mental illness? At least every one I've known. If anything, there's a good deal of narcissism and delusions of grandeur in this community, which incidentally you'll also find in cult leaders). Of course like any good cult, aesthetics are enforced. You can't just program in the language, you have to program the way everyone else programs. Take the Zen of Python, which preaches a sort of asceticism. Some cults are about "beautiful" code, that looks "clean" and is free of anything impure like certain syntax or even specific characters that are thought to be a nuisance. The key to all of this is it has nothing really to do with the essence of the language. Just having these elements floating around is enough for people to glom on and stick around. You don't even need to have an actual language to form on of these cults, look at Jai. There the BDFL has held back his language for about a decade, promising to release it but never actually doing so, which paradoxically keeps people holding out to receive the forbidden knowledge he is keeping from them. We've got our holy books of course. The language spec holds all the keys to understanding the word of the BDFL, although the number of people who have actually read it compared to use the language rounds to 0. Not only because these specs and docs can be voluminous, but also sometimes they are written purposefully to be inscrutable. See "Nock" and "Hoon". Half of understanding those things is just getting your head wrapped around the jargon, which itself is meant to be exclusionary -- if only the authors can read it, it puts them in a special place of translating the holy texts so that mere mortals might understand their wisdom (it also means that if anyone disagrees with them, they can just insist the texts are being translated wrong). Other times there are style guides which tell you the one true way to read and write the language. Then there are the various blogs and tutorials which are the equivalent of sermons, spreading the good word to the masses. Speaking of the masses, that brings us to the community! That's us, we are the cultists! The community will defend the BDFL to the death, and attack anyone who questions the dogma. You see this all the time in language communities, where any criticism of the language is met with vitriol and ad hominem attacks. Usually the BDFL treats people this way, and his community sees it a sign of strength, so they emulate it. Although The community is often more zealous than the BDFL themselves, going out of their way to convert others to the faith. We see that from time to time on HN, when people show up here from some lang community and they get way too into it, to the point their lang is flagged here every time it's posted (not even gonna name them because they'll be here to say something). They will also police the community, ensuring that everyone adheres to the dogma and punishing those who stray from the path. This is often done through social pressure, other times it's through explicit excommunication (banhammer). Which leads to sects! I mean forks! When a language community gets big enough, you start to see splinter groups forming. Tensions rise in the community around aesthetics, features, or very often how the community is being (mis)managed, how the BDFL is leading or ignoring users. Eventually you get a Martin Luther type who strikes out and forks the cult intending to create their own cult. We saw this with projects like Elm stagnating as the BDFL continued to bless certain packages but refused this access to the rest of the community, so forks starting to appear. Or look at the recent controversy with Nim and the Nimony fork. And let me tell you, as someone who was a dev for a PL and saw how these things started off, you really attract... interesting folks when it comes to a brand new language. For the thing I was involved with, it was just one person after another who had some out-there idea thy wanted to glom onto the language. Stuff like "vorpal math"... whatever that is. So, yeah that's the kind of people you start out with in the early days if you're lucky, because no one else is paying attention to the niche PL scene except the vorpal math guys, who are primed to receive any kind of special knowledge from a cult leader. You collect a couple of these followers, they become true believers, and then you grow from there. It's not too hard, but it's very unstable, so most communities don't get too big as the BDFL loses interest himself, or he can't keep the hype going. Once in a while you get guys like Yarvin who really run a grift over a looooong period of time -- with Urbit they were literally selling virtual land plots to their community. So just like actual cults, there's also a grift to run when it comes to languages (languages are not profitable at scale, but they can be profitable if you know how to grift). Now I'm not saying all languages are cults. But I think the fastest way to build a language from nothing into something somewhat active is to lean into the cult-like aspects to entice people in. Because otherwise the language has to stand on its merits, and small languages can't. So they have to stand on a promise of heaven that may or may not materialize (it probably won't), which is the basis of the cult. Because to keep the movement going, the cult leader either has to deliver nirvana, or keep promising it's just around the corner. Maybe it will be, but it's very easy to waste a decade of one's time hanging on to some lang dev waiting for him to drop the next update which will fix everything, but it never comes.

uvaursi 11mo ago

Software “engineer”[0] here. There are plenty of developers that are very rational about programming languages. I think the author lived in a weird bubble for most of their life jumping from company to company, project to project and saw some unhealthy development teams along the way. Developers make very rational decisions around PLs all the time, and the most rational choice, as also given by PG and Joel Spolsky many moons ago, is pick the language you’re most comfortable with and get over your shit. The second most rational choice is picking a language that fits the problem space like a glove. The third, most obvious rational choice of course, is Rust. [0] you sweet summer child.

getnormality 11mo ago

Maybe the Perl CTO wanted the product in Perl and not PHP because he knew Perl and didn't know PHP? Do we really need all this psychoanalysis and identity stuff to explain that?

etothet 11mo ago
This is often the real driver in these decisions. A previous company I worked at had an API written in modern PHP with Laravel. Traffic wasn’t very heavy on most days and we could autoscale when it was required. It worked great and we hadn’t encountered business problems that couldn’t be fairly easily solved within the ecosystem. However, one of the execs on the business side knew some other exec at a big tech company who told our guy that “PHP can’t scale”. So then we get questions if we should we consider rewriting, if we’re using the “best” language for our needs, etc. They wanted to plan for some theoretical future that they couldn’t even define from a business sense. Sure, it’s good to be aware of future business needs so that we, as technical people, can be asking the right questions to prepare for what that future may look like, but that almost never means a decision about language x over language y. It’s much deeper than that.
lproven 11mo ago
> Maybe the Perl CTO That's an example. It is not the subject under discussion.

dh2022 11mo ago

Rather than bet the company on a programming language I would prefer to be able to use different languages in an interoperable-fashion.

ChicagoDave 11mo ago

I’d have agreed with this three years ago, but GenAI has made me language agnostic. I’ve created apps with Typescript, Rust, Python, and completely open on more even though my background is 20 years in C#.

danans 11mo ago

If you are are starting from scratch, isn't the answer to which language to use just "the framework that best supports the business case and problem you are working on"? If that produces many options, then choose based on the team's familiarity with the language, frameworks, and ecosystems. A good software engineer should be pretty language agnostic when it comes to work, even if they have a personal aesthetic or technical preference.

lproven 11mo ago
The point of the article is that if you attempt to find > "the framework that best supports the business case and problem you are working on" by asking the people who will be using it, then the answer will almost certainly be wrong. The whole point here is working out which is the best tool is almost impossible because of natural human cognitive biases. TL;DR summary: No. No, that isn't the answer. It's not even an answer. It's the answer to a different question.

insane_dreamer 11mo ago

> “Everyone’s talking about Rust.” There it was: a 50 million dollar decision made on hype, about to be green lit. I've seen this with React. You might have a great website working with some solid MVC framework + good'ol jQuery or equivalent, but no, the whole thing has to be rewritten from scratch to be an SPA in React, to "keep up".

phibz 11mo ago

Isn't senior leadership choosing languages or core technology, doing things wrong? Shouldn't senior leadership focus on outlining the business opportunities, value case, and requirements for their solution?

lproven 11mo ago
No? The point of the article is that if you delegate this choice, the people to whom you delegate it will get it wrong.

js-j 11mo ago

For some time now, I've come to the conclusion that the choice of a programming language is of crucial importance to the success of a project: programmers are inspired by beautiful tech solutions, that's what motivates them to give the best of themselves. PHP has never been such a piece of technology for me, whereas Perl used to be...

tpoacher 11mo ago

Bulverism

lproven 11mo ago
https://en.wikipedia.org/wiki/Bulverism https://en.wikipedia.org/wiki/Bulverism Hardly, no. The entire point of the article is pointing out an entirely different cognitive fallacy.
- tpoacher 11mo ago
  It's Bulverism because first you need to defend and establish that your proposition is true before you can start explaining "why" it is true. At the very least the title is clear Bulverism. Admittedly, I did enjoy the article, even if I was initially a bit predisposed not to from the title. And I think the quote "if you hire a rust evangelist to choose your programming language, you've already chosen rust" is very insightful. But the author still goes into zero depth to asses to what extent rationality of language choice is a widespread problem, as opposed to isolated cases they've seen during their career. Which is ironic given that their thesis is that people go into topics emotionally without weighing them factually against the ground truth.
  - lproven 11mo ago
    He established his proposition in the opening paragraphs -- the ones that most HN commentators have seized up and not even noticed the actual argument and discussion. AFAICS you don't seem to have even noticed the initial example.
    - tpoacher 10mo ago
      I hope the irony that your argument is now the Bulverist one is not lost on you :D

dzonga 11mo ago

> “which language is best?” we need to ask “what is this language going to cost us?” Not just in salaries, but in velocity, in technical debt, in hiring difficulty, in operational complexity, in every dimension that actually determines whether you survive. then boom suddenly php, ruby & java are pragmatic choices in economic sense for business systems. same as c++ for hedge funds & video games etc.

anon291 11mo ago

Same reason you can't be rational about human language. People claim religion, but actually language is a better proxy for ethnic conflict.

louisashbourne 11mo ago

[flagged]

pjmlp 11mo ago

Very well put article, every single time I see a session like that I also ask about the business cost evaluation, especially regarding rewrites. Have they done in math in FTE salaries, times the estimated effort in days, mappend into money, and what is the expectation of ROI in that investment.

tsenturk 11mo ago

Developers chase hype technologies out of fear of becoming outdated, but they abandon these trendy programming languages just as quickly as they adopt them.