If you're listening VSCode forkers, ya built on bog
Software Rot
111–120 of 252 posts
Re: Software Rot
#112In my experience, the most common type of rot is that the real world the software describes has changed. For instance, I wrote software that modeled electrical power contracts, and when those real world contracts’ structure changes, no amount of “bedrock platform” is going to prevent that rot.
Re: Software Rot
#113Earlier quoted context omitted.
Sure. It still is burdensome, though. Now there are lots of nightly build from old projects that break at random times and require developer attention.
You just described all software, for the decades it often runs. Entropy sucks.
The point of the article is that this does not have to be the case, and is not the case for all software.
Re: Software Rot
#114javascript will run forever!
Re: Software Rot
#115We as an industry need to seriously tackle the social and market dynamics that lead to this situation. When and why has "stable" become synonymous with "unmaintained"? Why is it that practically every attempt to build a stable abstraction layer has turned out to be significantly less stable than the layer it abstracts over?
So one effect I've seen over the last decade of working: if it never needs to change, and no one is adding features, then no one works on it. If no one works on it, and people quit / change teams / etc, eventually the team tasked with maintaining it doesn't know how it works. At which point they may not be suited to maintaining it anymore. This effect gets accelerated when teams or individuals make their code more ma…
Maybe it's a documentation problem? It seems to me that for a piece of software to be considered good, one has to be able to grok how it works internally without having written it.
Re: Software Rot
#116I wish I could write all the business logic I write on an NES and never have to worry about requirements going bad. I guess the thing is, if you're writing anything on top of a network layer of any kind, eventually it's going to require patches unless you literally own all the wires and all the nodes in the network, like a secure power plant or some money clearing system in a bank that's been running the same COBOL s…
Building on bedrock is one extreme; the other is to become extremely fluid - build on quicksand but do it efficiently every time the quicksand shifts. AS3 may stop being useful, but if you can use some tool to recompile AS3 code to web JavaScript, you suffer no loss.
Re: Software Rot
#117This is a good discussion to have. I spend a lot of effort on evaluating dependencies. I look for a number of things like how popular/widely used it is, who the author is (if I recognize them) and I also look at code quality and number of sub-dependencies.
If I see a library which is solving a simple problem but it uses a lot of dependencies, I usually don't use that library. Every dependency and sub-dependency is a major risk... If a library author doesn't understand this, I simply cannot trust them. I want the authors of my dependencies to demonstrate some kind of wisdom and care in the way they wrote and packaged their library.
I have several open source projects which have been going for over a decade and I rarely need to update them. I was careful about dependencies and also I was careful about what language features I used. Also, every time some dependency gave me too much trouble I replaced it... Now all my dependencies are highly stable and reliable.
My open source projects became a kind of a Darwinian selection environment for the best libraries. I think it's why I started recognizing the names of good library authors. They're not always super popular but good devs tend to produce consistent quality and usually gets better with time. So if I see a new library and I recognize the author's name, it's a strong positive signal.
It feels nice seeing familiar niche names come up when I'm searching for new libraries to use. It's a small secret club and we're in it.
Re: Software Rot
#118Nobody has a better ecosystem of “industrial marine grade code rot resistance” than Microsoft. That I can run the same .NET web app code compiled 20 years ago on a new Server 2025 is an easy experience unequaled by others. Or the same 30 year old VBA macros still doing their thing in Excel 365. There’s a company that knows how to do backwards compatibility.
I had the opposite experience. Tried out XNA one year for the Global Game Jam. Was somewhat pleased with it. It was gone the next year.
Re: Software Rot
#119Earlier quoted context omitted.
You can account for that by using Go, with CGO_ENABLED=0. Then you have a self contained binary that relies solely on the POSIX syscalls.
Linux syscalls. There's no such thing as POSIX syscalls because POSIX defines a C interface.
You're right that POSIX doesn't specify syscall tables.
What I wanted to point out is that Go also supports BSDs and other kernels out of the box that implement the POSIX standard, though with slightly different syscall tables and binary formats on those target platforms and architectures.
I was referring to POSIX as a standard specification, because it also includes not only Linux's syscall table, but also various other things that you can typically find in the binutils or coreutils package, which Go's stdlib relies on. See [2.1.3] and following pages.
I guess what I wanted to say: If I would bet on long term maintenance, I would bet on POSIX compatibility, and not on one specific implementation of it.
[2.1.3] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
Re: Software Rot
#120Earlier quoted context omitted.
Python is a very bad example because of the incompatibility between Python 2 and Python 3. All my pre-2012 Python code is now legacy because of this, and since most of it is not worth updating I will only be able to run it as long as there are Python 2 interpreters around. I like Python as a language, but I would not use it for something that I want to be around 20+ years from now, unless I am ok doing the necessary…
does 2to3 not suffice / work for your code?
It never worked for any of my nontrivial python files, even for simple projects it often failed. It was a good start, but it was not a fully automatic magic migration script. Otherwise ecosystem migration wouldn't take ages as it did.