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.
Why engineers can't be rational about programming languages
71–80 of 206 posts
Re: Why engineers can't be rational about programming languages
#72Please spare us the typical
- Look at people using identity-focused reasoning with politics
- It’s research!
- That’s the same as those
- 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.
Re: Why engineers can't be rational about programming languages
#73I think the author almost contradicts themselves; they reach the salient-but-obvious conclusion that rewriting a product is almost always a bad idea and that rewriting a product only to change programming language is _always_ a bad idea, that tribalism is a poor decisionmaking framework, and that leadership by arbitrary decree is stupid. Great! These are age-old lessons that people somehow seem to forget, so seeing t…
> I cannot agree that programming language choice is a primary driver in a product's success or failure....
This and similar are common ideas for the people that never see the real whole world of programming, and maybe have the fortune of be in the "startup" circles.
I see the opposite, and is very good predictor to know how bad a product or a team is, using the programming language AND the main DB engine, but that is because I live in the world of "enterprise" code where for example:
* I'm called to do a rewrite
* I see the screenshot of the main app
* I guess correctly was made with vb (first big alarm) (how I know: I never see in my circle anybody that do vb, php, c, c++ anything resembling a sane UI. BTW just the use of colors was enough to guess)
* I worry, but confirm, that use Access as the main db
* I discover that part of the data was ALSO in a excel file, that is used with the equivalent of "joins", and was not surprised to see things like this
Even without knowing more about the people that do it, that is far enough signals to guess much.
BTW, there are very good predictors, if Use: MySql, MonGo, Php, Js (almost whatever you wanna add here in terms of frameworks), VB, Perl, Android (aka: Java android and android itself without using iOS alongside), is likely terrible. Then Java or C# taking turns how much worse, but not as bad as the ones before. I sweat if somebody say it use C or C++. Probably enough to straight refuse to take the project.
Any use of not-obscure tech in this sector and is a good predictor to be more or less not-that-bad.
BTW: Also complex infra and related boilerplate is now probably a stronger predictor after some langs like python, go, typescript and more modern java/kotlin/c# has spread (and also more pg and much less nosql, but too much "cloud")
Re: Why engineers can't be rational about programming languages
#74Earlier quoted context omitted.
While I’ve seen bad technology chosen for projects, it seemed at root more a problem with the people choosing it than the technology itself.
Absolutely agree. People made the bad decisions. But the bad choices existed. People who don't understand the bad choices are bad choices, or worse, think that there is no possible way there is a bad choice, are far more likely to end up being those people who made bad decisions then people who understand that the decisions mattered. Don't go running around telling people that they can dig the Panama Canal with three…
> Tool choice matters. In fact I can hardly process how anyone can be an engineer and think that it doesn't, let alone how they can think it's some sort of engineering wisdom to claim that it doesn't matter what tools you use to do a project
Just to be clear, I wasn't trying to claim this; tooling certainly matters, at the very least, for the happiness and welfare of an engineering team! But, the article tries to claim things like "choosing a programming language is the single most expensive economic decision your company will make" and outside of a few extreme edge cases, I just can't agree with that particular thesis. Even the examples of bad decision-making you pose in your sibling comments, like writing a database in Go or "almost failing" by using sketchy niche datastores, are actually examples of this exact thing: these projects made huge engineering mistakes only to achieve some level of success as a business. Would they have been more successful if they made better engineering decisions? Possibly, but again, language and framework just was not the most important decision or factor driving an outcome.
I'm not saying that means we shouldn't care about making good engineering choices; there are easy ways to do things and hard ways to do things, and certainly I'm going to advocate for and work with people and at companies that favor the easy ways to do things. But when it comes to overall outcomes, I'll stand by having seen far more projects sacrificed to analysis paralysis, rewrites, rewrite-related hand wringing, and language/tooling hubris than sabotaged by poor language and framework choices.
Re: Why engineers can't be rational about programming languages
#75In my experience "choose the right tool for the job" almost always translates into "pick the tool you like most and justify it later".
Re: Why engineers can't be rational about programming languages
#76Earlier quoted context omitted.
> I've seen it. There are definitely incorrect language choices for certain projects. I guess we can all agree that writing your web application using a fortran framework to generate JS code is a bad idea. But if you pick tfa's second example, picking Go vs. Rust for a new project, the language choice is secondary. Both languages were likely fine unless the project as a specific library requirement. The main criteria…
In my first post, the example I really wanted to use was people picking Go for their top-end, competitive-with-anything-in-the-market database. I choose Python just because anyone who would argue that is a good choice is clearly not someone who is in a position to see reason. But I think Go is a serious mistake... it's just one that lets you get to market, unlike Python which never would. But it's still going to end…
> the example I really wanted to use was people picking Go for their top-end, competitive-with-anything-in-the-market database.
You mean they're writing their own database? Why? That's a huge job and available databases are pretty good. There are multiple open-source choices, all of which work.
If they think they're going to compete with Oracle, they need to read the history of Oracle.
Re: Why engineers can't be rational about programming languages
#77I 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 communicatin…
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.
Re: Why engineers can't be rational about programming languages
#78Earlier quoted context omitted.
In my first post, the example I really wanted to use was people picking Go for their top-end, competitive-with-anything-in-the-market database. I choose Python just because anyone who would argue that is a good choice is clearly not someone who is in a position to see reason. But I think Go is a serious mistake... it's just one that lets you get to market, unlike Python which never would. But it's still going to end…
> the example I really wanted to use was people picking Go for their top-end, competitive-with-anything-in-the-market database. You mean they're writing their own database? Why? That's a huge job and available databases are pretty good. There are multiple open-source choices, all of which work. If they think they're going to compete with Oracle, they need to read the history of Oracle.
There are at least a dozen new databases in the market making decent money that were started this decade.
They're just not competing with Oracle.
Re: Why engineers can't be rational about programming languages
#79I 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.
Because his first experience with this debate was forcing PHP on engineers who knew that would be a bad choice. No matter what you are doing, PHP isn't the right choice for it if more than 1 person will ever use or depend upon the software. PS I've seen PHP destroy billions in value in my career. It and Brainfuck are the only 2 languages you should never use to make software for other people. Every other language has…
> Because his first experience with this debate was forcing PHP on engineers who knew that would be a bad choice
Ummm... No, I think it was about forcing Perl on engineers who had been using PHP.
Re: Why engineers can't be rational about programming languages
#80I think the author almost contradicts themselves; they reach the salient-but-obvious conclusion that rewriting a product is almost always a bad idea and that rewriting a product only to change programming language is _always_ a bad idea, that tribalism is a poor decisionmaking framework, and that leadership by arbitrary decree is stupid. Great! These are age-old lessons that people somehow seem to forget, so seeing t…
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 i…
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!