The Lindy effect in software The longer a tech has been around, the more robust it is seen as compared to more recent ones, we often talk about a technology’s maturity The C language SQL has been around for a while, https://antonz.org/fancy-ql/ JS libraries seem to come and goesComplete with rewriting everything in the trendy memory safe quasi-portable language that is faster than (poorly written) C in your personal microbenchmarks.
All the job postings I see are for C++ (Annoyingly. Fortran is better). Or Python obviously.
Enterprise I've seen, all europe, deliberately vague: Banking, Telecoms, Trains, Insurance
I work in a polyglot agency, and the RFPs asking for .NET have gone down, even key enterprise products like Sitecore, have moved away from .NET.
We only touch Go due to containers tooling, and Rust only due to the RIR stuff from Python and JavaScript.
Enterprise consulting is staying with Java, .NET, JavaScript/Typescript, Python, Powershell, SQL, and co.
Naturally Swift and Kotlin if doing mobile without Cordova, React Native and friends.
C or C++ for native libraries, as those are what SDKs support out of the box without additional tooling.
Boring technology for the most part, and usually a few versions behind stuck in some LTS.
But by rewriting software, even in the same language we can learn from past mistakes and experiences and create better and more maintainable software.
Like I've worked places where the business ran off a layer cake of '80s tech, '90s tech that partially replaced the '80s tech, and '00s tech that partially replaced the '90s tech, and were now on their way to launch a big project to replace all that with '10s tech, a project doomed to run out of steam half way through (because legacy code got hands), inevitably leading to a codebase that consists of three failed attempts to rewrite the '80s codebase, and the '80s codebase.
As the functionality of the code was business critical, and no shift in behavior could be tolerated, they're never getting out of this mess, and would have been better off staying on '80s tech.
It's good for job security that's for certain.
In the context of free software it is usually also a method to be able to sideline part of the existing user or developer community, which you can not easily justify when making changes the existing project but can be achieved with a rewrite. But the former leads to a honest view of the trade-offs and consequences where the rewrite is a toxic power move.
Couldn’t a Lindy enthusiast have gone “umm but isn’t Java too new and shouldn’t we just stick to C which is well trodden and understood??”
It’s easy to write sloganeering articles. But it doesn’t tell me anything specific.
Invoking Lindy is just bias to status quo. I prefer bias to progress but respecting chestertons fence.
I've invoked it in my job mostly to explain to younger developers why learning vim keybindings+terminal git usage while they have the most plasticity is most likely going to be a good bet for the remainder of their career, as editors, operating systems and associated keybindings & UI will change around them much more often than those fundamentals.
It's not a guarantee, and i wouldn't bet my entire business on the Lindy effect, but it is worth reflecting on it as an explanation of something that is paradoxical or not obvious.
Interesting - I see it as the opposite: learning the git CLI is pointless. It’s slow, clunky and it doesn’t teach you any of the very interesting inner-workings of Git.
There are much better things to spend time learning, especially if your editor has a native git integration.
For prescriptive, I would use Chesterton's Fence https://fs.blog/chestertons-fence/
Under the section -
"Applying the Lindy effect to software engineering"
The suggestions are -
- Prudent Adoption
- Stick to Proven Foundation
- Plan for Longevity
- Embrace Evolution, Not Revolution
I think people often misrepresent history because they view it with the benefit of hindsight. People who chose to use Java didn't do it to embrace a revolutionary idea, they were embracing an evolutionary one. It seemed like a natural optimization step, rather than a clean slate.
Most Jave devs were proficient C devs who found the idea of a platform independent C quite appealing.
That's the Lindy effect. C (the essence of it) survives in Java and right up to JS/python/go.
In contrast consider Pascal, Fotran, Perl, COBOL, (and dare I say ... Lisp ?)
Looking at the examples of Lindy that the OP mentioned, they're mostly at the infrastructure level. That's probably because many systems have been built on top of them, and the cost of replacing them is high.
On the flip side, things with weak Lindy effects are likely frontend frameworks or specific libraries. CSS methodologies are a good example of that.
In other words, the deeper something is, the harder it is to change, and as long as that deep language and its ecosystem aren't replaced, it will persist. As a counterexample, Fortran comes to mind—it's still being used today. Fortran has also evolved to exist beneath NumPy and Julia.
Ultimately, I think the core isn't the Lindy effect itself, but rather how many people you can attract commercially, and how many jobs you can create based on that.
In that sense, I think the next-generation language will succeed when it's used to build new infrastructure, and when the cost of refactoring becomes exponentially high. Right now, something that's growing similarly strong is CUDA. Personally, I'm always waiting to see what that language will be.