Live data from Hacker News

The Lindy effect in software

clemsau.com

11–20 of 45 posts

Re: The Lindy effect in software

#12
post #8

Earlier quoted context omitted.

I don't think this is what we want. We want people to maintain and incrementally improve existing software and tooling and not rewrite and change things all the time.

A rewrite doesn't need to actually change the public API or experience using the software. But by rewriting software, even in the same language we can learn from past mistakes and experiences and create better and more maintainable software.

Sorry, I think the idea that rewrites are good way to achieve more maintenable software is basically always based on a delusion. It is a very common and well understood delusion for programmers who always see the existing code as crap and imagine a beautiful world when they could only rewrite it. A well understood mistake: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

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.

Re: The Lindy effect in software

#14
Terrific writing. Just terrific. Copied verbatim:

  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 goes

Re: The Lindy effect in software

#15
post #4
post #2

I'd say rust is the new Java, not Go. Complete with rewriting everything in the trendy memory safe quasi-portable language that is faster than (poorly written) C in your personal microbenchmarks.

I work in enterprise, and java still reigns supreme. You see some (very limited) cracks coming from other jvm languages, but that's all. Nobody talks about Rust, rarely about C.

Isn't .NET kinda on quite a rise in enterprise?

Re: The Lindy effect in software

#16
The Lindy effect is ultimately a kind of momentum. If that's the case, it seems like it's not the language itself, but rather the 'contracts,' 'interfaces,' and 'standards' that survive longer than the specific implementations a language provides.

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.

Re: The Lindy effect in software

#17
post #2

I'd say rust is the new Java, not Go. Complete with rewriting everything in the trendy memory safe quasi-portable language that is faster than (poorly written) C in your personal microbenchmarks.

People have been rewriting software in better languages ever since there was more than one programming language. Eventually people will be rewriting Rust programs in GoombaLang or whatever. Isn't this what we want?

The point of the article is pretty much that you can pick stable technology instead of joining the treadmill of rewriting in whatever the new thing is. When people are rewriting rust programs in GoombaLang, C will still be around. When people rewrite GoombaLang into SmurfLang, C will still be around, etc

Re: The Lindy effect in software

#18

Earlier quoted context omitted.

People have been rewriting software in better languages ever since there was more than one programming language. Eventually people will be rewriting Rust programs in GoombaLang or whatever. Isn't this what we want?

The point of the article is pretty much that you can pick stable technology instead of joining the treadmill of rewriting in whatever the new thing is. When people are rewriting rust programs in GoombaLang, C will still be around. When people rewrite GoombaLang into SmurfLang, C will still be around, etc

You can pick C, but that doesn't mean it's a good option to write something in it

Re: The Lindy effect in software

#19
post #4

Earlier quoted context omitted.

I work in enterprise, and java still reigns supreme. You see some (very limited) cracks coming from other jvm languages, but that's all. Nobody talks about Rust, rarely about C.

Isn't .NET kinda on quite a rise in enterprise?

Not really, going open seems to only helped Microsoft shops to migrate to Linux for deployments, thus saving on server licences.

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.

Re: The Lindy effect in software

#20
post #2

I'd say rust is the new Java, not Go. Complete with rewriting everything in the trendy memory safe quasi-portable language that is faster than (poorly written) C in your personal microbenchmarks.

None of them are nowhere near the Java tooling and ecosystem.

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.

Post reply on HN