Hacker News Reader

Comment by euske | Hacker News Reader

I think what's discussed in OP is not software rot, but software clutter. Software rot would be something inherent that happens to software naturally over time, without any external change. I can't think of a good example of this, so I think software rot is in general a misnomer.

View on HN

In my opinion, software "rot" is most likely where software has been passed on through a number of lead contributors over time. The original reasons for a particular set of design decisions are forgotten. Someone else comes along and doesn't quite understand a particular nuance, tries to add factionality, but it doesn't quite work, so writes a bit of code that ends up reimplementing an aspect of the original, so you have two lots of code doing the same thoing in different ways, perhaps with their own set of variables.

Then someone else comes along and is faced with real confusion and before you know it you find yourself with a system which, if you update data one way, the changes are sometimes picked up by another part of the system, sometimes not and... its rotten.

I'm not sure software clutter describes this either but I understand what you are trying to say. I think of software rot more as code that hasn't been touched by anyone in years and now it no longer works due to it's environment changing. Things like API updates, general system updates, security updates or other factors causing it to malfunction eventually.

I had a thumbnailing micro service I made years ago that worked happily until 3 months ago. A combination of PIL updates and various Ubuntu security updates made it no longer work properly in various ways from keeping the alpha layer on PNG files to cropping from the wrong position. I consider this software rot since I hadn't updated anything but the surrounding system.

An even more extreme case of this is trying to bootstrap a compiler from the first version, e.g.: http://www.joachim-breitner.de/blog/748-Thoughts_on_bootstra...

"""So it seems that besides GHC, only ever HBC was used to compiler GHC. HBC is a Haskell compiler where we find the sources of one random version only thanks to archive.org. Parts of it are written in C, so I looked into this: Compile HBC, use it to compile GHC-0.29, and then step for step build every (major) version of GHC until today.

....

[M]ost of [HBC] is written in LML, and the LML compiler is written in LML."""

Well there is bit-rot. One manifestation of this is when nobody works on code for a while and it becomes unusable or less usable because the world has moved on. Maybe newer versions of the compiler won't compile it. Maybe some of the dependencies have changed. Just try to build even a small program written for Windows 95 or 98 today.

This is one reason "do one thing and do it well" is useful. The interface is kept simple and should be easy enough to update to a new environment. At the same time, that means for bigger systems a lot of small things will need updating over time, but at least the changes should be straight forward.

> Just try to build even a small program written for Windows 95 or 98 today.

This largely works, especially on the C/C++ side.

My experience is not really. The most common thing you will need to fix is assumptions about pointer sizes. Including casts between integer and pointer, which compilers used to be more permissive about in the days before intptr_t. (A few years ago I was compiling code from the 90s that did these casts implicitly, which had me wondering why the compiler ever let them get away with it...)

C++ in particular has also changed a lot since the 90s including how permissive the compilers used to be, even for stuff covered by c++98.

isnt this 'bitrot' function of the interface size ? I doubt sed will ever rot for instance

sed does simple operations on text. But it certainly had to change when the definition of “text” changed from US-ASCII to “Whatever the LOCALE settings are, but most often ISO-8859-1”, and then later to “Most often UTF-8”.

damn humans

I think we can test this retroactively. sed has been around a long time. So we can go grab a copy from, say, Version 7 Unix and try to build it on a modern system. I grabbed v7.tar.gz from https://github.com/v7unix/v7unix, extracted it, and tried to build:

    $ make
    cc -n -O   -c -o sed0.o sed0.c
    In file included from sed0.c:2:
    sed.h:116: warning: declaration does not declare anything
    sed.h:128: warning: declaration does not declare anything
    sed0.c: In function ‘main’:
    sed0.c:32: error: ‘union reptr’ has no member named ‘ad1’
    sed0.c:48: warning: incompatible implicit declaration of built-in function ‘exit’
    <snip many more lines>

The problem here is that although sed was written in "C" and we have a "C compiler" on our system, the definition of what exactly constitutes "C" has changed. The modern compiler no longer accepts the same language as the V7 compiler.

We can fix the source to deal with this and produce a working binary. But then, what would we do with it? We can't really install it as /bin/sed. The world now expects /bin/sed to support switches and syntax that this sed does not. Trying to use this as /bin/sed would cause lots of programs to fail. The definition of what exactly constitutes a working "sed" program has also changed.

So it seems to me like sed already has rotted in some sense. Looking forward, the sed from a current system is likely to be similarly rotted when you try to use it on a machine 40 years from now.

You're right .. even sed can corrode. That said it gave me ideas about deriving updates based on changes in data encoding / representations...

> The problem here is that although sed was written in "C" and we have a "C compiler" on our system, the definition of what exactly constitutes "C" has changed. The modern compiler no longer accepts the same language as the V7 compiler.

Standards provide solid points of reference in this mess: 1989 ANSI/ISO C is not going to change. Specific compilers come and go, but the language defined by those documents (one ANSI, one ISO) is unchanging and, more importantly, well-understood such that C compiler implementers both feel the need to implement it correctly and understand how.

> Looking forward, the sed from a current system is likely to be similarly rotted when you try to use it on a machine 40 years from now.

I think it's likely the language won't rot the same way, due to the standardization I mentioned, but the OS interfaces beyond POSIX or similar might rot.

A well‐used door needs no oil on its hinges.

A swift‐flowing stream does not grow stagnant.

Neither sound nor thoughts can travel through a vacuum.

Software rots if not used.

These are great mysteries.

— The Tao of Programming, Geoffrey James, 1987

> Just try to build even a small program written for Windows 95 or 98 today.

This largely works if it was written in Delphi.

As someone who has tried to build Delphi apps:

Well...

The code might very well work the same, but the dependencies were a nightmare: They were scattered across 14 different CDs and web sites. One provider of often used components had gone out of business, luckily those components were released on sourceforge.

Since there wasn't pom.xml (forgive me for mentioning a Java-thing here, but this was long before package.json or ProjectName.csconf was invented) in Delphi projects one also had to go through a bit of research, trial and error to figure out which versions was needed and the exact ones that were compatible with each other.

Luckily we had a seasoned, well paid Delphi expert at hand and we got it working in just under 3 days.

If anything I'd say this is a great example of (one form of) bit rot.

Now that I think of it it might very well have been the same week that I left behind my last bit of prejudice against Java and started openly preferring it.

Yep. We have huge delphi app. It's composed of few dozen DLLs, each dll is a different project with its own forms. Each DLL uses its own components, different DLLs use different versions of the same components, they are incompatible. Basically to build this nightmare you would need around 8 virtual machines to install those components. At least they have all those components downloaded offline. This app is in desperate need of huge refactoring but nobody got money for that.

Think about freshness. When code was recently written, it's fresh in memory. People can remember what the code was written for, and why it was written.

As time passes, code gets stale. And finally, when people can't remember what the code does, at that point you could consider it rotten. At some point the tooling becomes unavailable and you wont be able to run it!