Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Rot

permacomputing.net

Post reply on HN
Print view View original

101–110 of 252 posts

Re: Software Rot

#101

Post by pvtmert »

saurik wrote: post #64
whizzter wrote: post #48

Earlier quoted context omitted.

2005 is already 25 years ago, and what the author is hinting at is the difference in difficulty between keeping 1980s software running vs keeping 2005 software running is momentous. 1980s NES software is "easy" as in emulating a CPU and the associated hardware (naturally there are corner cases in emulation timing that makes it a lot harder, but it's still a limited system). I used to make demos as mentioned in the ar…

> 2005 is already 25 years ago o_O

a confirmed time-traveller :)

Re: Software Rot

#102

Post by pvtmert »

It is interesting that one of the most solid piece of software component that is relatively resistant to rotting is Shell/Bash scripts. (Including Makefiles)

Python, Ruby, etc. constantly get obsolete over time, packages get removed from the central repositories, ceasing to work.

Obviously shell scripts contain _many_ external dependencies, but overall the semantics are well-defined even if the actual definitions are loose against the shell script itself.

P.S: I have written couple of Bash-script projects that are still running (mostly deployment automation scripts) meanwhile, some of which I was being "smart" and wrote them in Python 2.7, unfortunately ceased to function, requiring upgrades...

Re: Software Rot

#103

Post by eviks »

legends2k wrote: post #90
eviks wrote: post #82

Earlier quoted context omitted.

> There isn't much to evaluate, and nothing to compare against These are exactly the skill issues I meant! Git gud in evaluating and you'll be able to come up with many more sophisticated evaluation criteria than the primitive "it's installed everywhere"

While there are other parameters I would consider like maintainability, ergonomics, mind share, ease of deployment, etc. The ubiquitous availability point triumphs most others though. Installation of new toolchain is usually a hassle when the same task can be done with existing tools. Also when I present it in a company setting installing new software and broadening the security attack surface is the first pushback I…

Do you advocate the use of Notepad on Windows to edit text because it already exists? What about the increase in the security attack surface from using languages that make it easy to make mistakes in something basic like quoting/escaping? Does it get in the top 10 of pushbacks?

Re: Software Rot

#104

Post by benchly »

pvtmert wrote: post #102

It is interesting that one of the most solid piece of software component that is relatively resistant to rotting is Shell/Bash scripts. (Including Makefiles) Python, Ruby, etc. constantly get obsolete over time, packages get removed from the central repositories, ceasing to work. Obviously shell scripts contain _many_ external dependencies, but overall the semantics are well-defined even if the actual definitions are…

What about C? Is there something to be said for the proximity of the language to the machine language?

Maybe that sounds like a dumb question because I am a beginner at coding, so I apologize, but it's something I've recently gotten into via an interest in microcontrollers. A low(er)-level language like C seems to be pretty universally sound, running on just about anything, and seems to have not changed much in a long, long time. But when I was dabbling in both Python and Ruby (on Rails) and .NET framework, I noticed what you mean, as I scooped up some old projects on github thinking I'd add to them and realize that it would be a chore to get them updated.

Re: Software Rot

#105

Post by LittleCloud »

vrighter wrote: post #84
Ygg2 wrote: post #57

Earlier quoted context omitted.

Python 2 is a warning about doing backwards compatibility changes too late. As soon as you have a few massive libraries, your backward compatibility risks grow exponentially. C# did just as big of a change by going from type-erased to reified generics. It broke the ecosystem in two (pre- and post- reified generics). No one talks about it, because the ecosystem was so, so tiny, no one encountered it.

When did c# have type erasure?

C# 1.0 did not have generics, period. So the standard dictionary (Hashtable†) type took keys and values typed as "System.Object". As seen in the linked documentation this class still exists in the latest .NET to this day.

Occasionally one would still encounter non-generic classes like this, when working with older frameworks/libraries, which cause a fair bit of impedence mismatch with modern styles of coding. (Also one of the causes of some people's complaints that C# has too many ways of doing things; old ways have to be retained for backwards compatibility, of course.)

† https://learn.microsoft.com/en-us/dotnet/api/system.collecti...

The paper that the other commentator was referring to might be this: https://www.microsoft.com/en-us/research/wp-content/uploads/...

Re: Software Rot

#106

Post by gr4vityWall »

noduerme wrote: post #69

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

> 50-60% of my lifetime code output before 2018, and pretty much all the large libraries I had written, were in AS3

Out of curiosity, what kind of work did you do? Regarding our old AS3, did you have any luck with Haxe? I assume it would be a straightforward port.

Re: Software Rot

#107

Post by dusted »

Perfect little text, that article is.

Same site has this article about "bedrock platforms" which resonate deeply with me https://permacomputing.net/bedrock_platform/

Software does not rot, the environment around software, the very foundation which owes its existence: the singular task of enabling the software, is what rots.

Let's look at any environment snapshot in time, the software keeps working like it always did.. Start updating the environment, and the software stops working, or rather, the software works fine, but the environment no longer works.

I'm not saying never to update software, but, only do it if it increases speed, decreases memory usage, and broadens compatibility.

I like things better the way they were.

I like things better now than how they will be tomorrow.

I can't remember the last time I saw a software update that didn't make it worse.

Re: Software Rot

#108

Post by ManBeardPc »

Software rot is a big problem in many business tools. Everything not recently built from the tip of main is probably no longer working. APIs change, URLs change, Processes change, newer versions of dependencies no longer work because of version conflicts or deprecation without replacement. The amount of work just to fix the rot is constantly rising. No care is spent to keep things stable. Stable interfaces are really something I learnt to appreciate more and more, even if sometimes crusty and verbose. If it is reliably working don't replace it without a very good reason. I attribute these problems mostly to agile the way it is practiced in many companies. Only thinking in providing "value" per sprint and little to no planning ahead, prioritizing ease of change over everything else.

Re: Software Rot

#109

Post by prmoustache »

pvtmert wrote: post #102

It is interesting that one of the most solid piece of software component that is relatively resistant to rotting is Shell/Bash scripts. (Including Makefiles) Python, Ruby, etc. constantly get obsolete over time, packages get removed from the central repositories, ceasing to work. Obviously shell scripts contain _many_ external dependencies, but overall the semantics are well-defined even if the actual definitions are…

Frankly perl5 seems like one that is very resistant to rot. TCL and TK as well.

Re: Software Rot

#110

Post by prinny_ »

I don’t get the comparison to building a house. Houses have a ton of maintenance. You can’t build a house on steady ground and leave it unattended for 20 years either. And sometimes what you need to do is not even construction type of maintenance, it’s bills, legal paperwork, replacing old furnitures just because you grew tired of that 15 year old sofa etc.
Post reply on HN