Live data from Hacker News

Why engineers can't be rational about programming languages

spf13.com

111–120 of 206 posts

Re: Why engineers can't be rational about programming languages

#111
post #68
post #36

Earlier 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…

Sure, people with ZERO enterprise experience might say - hey, let's write our in PHP - I had a lot of fun 15 years ago with that, and I'm sure we can make it work.. That's the "3 toothpicks" in your example.

But is anyone REASONABLY competent going to do that? They might pick C/C++, Go, Rust, Java, etc. Those aren't a choice between "bulldozers and toothpicks" - they are more akin to choosing between Caterpillar, Volvo or Hitachi as the vendor of choice for construction equipment. They may have some gaps in their specific list of equipment, they may charge too much for one specific tool, your workers may have experience with one, not the other, etc..

Your example should be the textbook definition of a strawman argument..

Re: Why engineers can't be rational about programming languages

#112

Earlier quoted context omitted.

Someone told me to read Meadows over a year ago, and I can no longer remember who, and to make it worse it slipped off my radar. I'm filled with regret now because they appear to be a concise and insightful thinker, or at least an effective proliferative of good ideas.

No reason to regret, still time to read her works. That essay is also a chapter in her book Thinking in Systems: A Primer (publish posthumously), and more essays are on that site.

PDF here: https://ia800409.us.archive.org/25/items/thinking_in_systems...

Re: Why engineers can't be rational about programming languages

#113
post #20

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 t…

It's not a contradiction if you assume that (a) language choice is critical and (b) rewrites are doomed to be failures.

Having that said I agree that language/platform is a "non technical requirement" in 90% of real world cases. You pick what you know or in more industrious scenarios - what's available on the market or what's the most cost effective.

But people are indeed irrational about programming languages. There's tribalism, stereotypes and preconceptions. Most notable is probably PHP, language for human failures and shit projects. As if same exact project written in Java was suppose to be of higher philosophical value.

But it's something you can't deny. I've been asked in non ironic way by a (non technical) founder investor if I could recommend him Rails programmers, because he read about it and it's suppose to be great. I asked him about specifics of his new project and he said he doesn't have an idea yet, but it has to be in Rails. Go figure.

Re: Why engineers can't be rational about programming languages

#114
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.

Re: Why engineers can't be rational about programming languages

#115
post #63

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 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.

As a rubyist: traits are strictly typed ducktyping. I love them.

Re: Why engineers can't be rational about programming languages

#116
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.

Re: Why engineers can't be rational about programming languages

#119
post #80

Earlier quoted context omitted.

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!

Lol, that sums up the human experience. You should sell bumper stickers:

"Rock bottom is deeper than you think!"

Re: Why engineers can't be rational about programming languages

#120
post #20

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 t…

In my experience, a language switch rewrite can be a benefit only when switching from a dead ecosystem to a living one. For example, migrating a web app from a language that predates Unicode to something that won't require a bunch of scaffolding around every user input sometimes is worth it. Moving from LABVIEW to a real programming language that integrated with remotely modern development tooling was worth it. Switc…

> Moving from LABVIEW to a real programming language ... Switching from C++ to Rust? Probably not.

Weird. LabVIEW is a real programming language. And both LabVIEW and Rust make entire classes of bugs that you often hit in C++ go away, especially for concurrent programs.

> remotely modern development tooling

I would make the argument that it is the tooling, i.e., Git and Diff, that is ancient and not remotely modern. Continually demanding that anything worth source controlling is text-based, and even further line-based, is as antiquated as it gets.

Post reply on HN