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

91–100 of 252 posts

Re: Software Rot

#91

Post by aragilar »

gbin wrote: post #63
zeta0134 wrote: post #50

Earlier quoted context omitted.

Python even has venv and other tooling for this sort of thing. Though, admittedly I seem to have dodged most of this by not seriously writing lots of python until after Python3 had already happened. With any luck the maintainers of the language have factored that negative backlash into future language plans, but we'll see. Mostly I recoiled in horror at bash specifically, which in addition to bash version, also ends…

How many times the virtualenv/pipenv/pyenv/... changed though? The package management also between wheels and setup and all the breakages. Even for somebody that did not aim to have python programs for 20y, python is definitely not a good example of a "pdf for programs"

I think if you had chased every single latest hotness then you would have hit lots of breakages, but depending on what you are doing and where you are running (and what dependencies you are using) then I think you could easily have something from 10-15 years ago work today. Part of the trick would have been to aware enough to pick the boring long-term options (but at some level that applies to every language and ecosystem), but the other part is understanding what the tools are actually doing and how they are maintained.

Re: Software Rot

#92

Post by account42 »

The OS/libraries changing is one example of software rot but another one is requirements changing and you can't completely eliminate that.

Re: Software Rot

#93

Post by esseph »

cjfd wrote: post #77
esseph wrote: post #56

Earlier quoted context omitted.

That's why your build pipeline alerts you when tests no longer work, and then you have a release of the previous build still available for download at any time. This is how containers are released!

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.

Re: Software Rot

#94

Post by [deleted] »

blueflow wrote: post #89
eviks wrote: post #7

Earlier quoted context omitted.

This dogmatic approach means you lose out on ergonomics by using poorly designed tools like bash and perl, so you incur those costs all the time for little potential benefit far away in the future (after all, that effect is just a broad hypothesis)

Its not "far away in the future". Every other IT job right now is supporting, maintaining and fixing legacy software. These are the software choices of the past and you pay them in manpower.

[deleted]

Re: Software Rot

#95

Post by testthetest »

forgotmypw17 wrote: post #2

This and Lindy Effect factors a lot into my choices for what to use for my projects. My choice for a project I want to be as maintenance-free as possible are special subsets of ASCII/txt, SQLite, Perl, Bash, PHP, HTML, JS, CSS. The subsets I choose are the parts of these languages which have persisted the longest. Using the Lindy Effect for guidance, I've built a stack/framework that works across 20 years of differen…

It’s getting harder to make perfect choices as projects grow more complex. Even simple products often mean building for iOS, Android, web, backend, etc. You can only lean on html/js for parts of that, but in practice, the mobile apps will probably get rewritten every few years anyway.

From my side I think it’s more useful to focus on surfacing issues early. We want to know about bugs, slowdowns, regressions before they hit users, so everything we write is written using TDD. But because unit tests are couple with the environment they "rot" together. So we usually set up monitoring, integration and black-box tests super early on and keep them running as long as the project is online.

Re: Software Rot

#96

Post by dpassens »

cookiengineer wrote: post #32
userbinator wrote: post #14

those written for e.g. Linux will likely cease working in a decade or two Have we already passed the era of DON'T BREAK USERSPACE when Linus would famously loudly berate anyone who did? I suspect Win32 is still a good target for stability; I have various tiny utilities written decades ago that still work on Win11. With the continued degradation of Microsoft, at least there is WINE.

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.

Re: Software Rot

#97

Post by gjvc »

sebtron wrote: post #33
zeta0134 wrote: post #24

Earlier quoted context omitted.

Very helpfully, python has stuck around for just as long and is almost always a better choice against these two specific tools for anything complicated. It's not perfect, but I'm much more likely to open a random python script I wrote 6 years ago and at least recognize what the basic syntax is supposed to be doing. Bash beyond a certain complexity threshold is... hard to parse. Python's standard library is just fine…

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?

Re: Software Rot

#98

Post by gjvc »

codeflo wrote: post #44

We 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?

post a link to a stable repository on github on this site. watch as several people pipe up and say "last commit 2020; must be dead"

source code is ascii text, and ascii text is not alive. it doesn't need to breathe, modulo dependencies, yes. but this attitude that "not active, must be dead and therefore: avoid" leads people to believing that the opposite: unproven and buggy new stuff, is always better.

silly counter-example: vim from 10 years ago is just as usable for the 90% case as the latest one

Re: Software Rot

#99

Post by mezyt »

sebtron wrote: post #33
zeta0134 wrote: post #24

Earlier quoted context omitted.

Very helpfully, python has stuck around for just as long and is almost always a better choice against these two specific tools for anything complicated. It's not perfect, but I'm much more likely to open a random python script I wrote 6 years ago and at least recognize what the basic syntax is supposed to be doing. Bash beyond a certain complexity threshold is... hard to parse. Python's standard library is just fine…

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…

There's a script to update from python2 to python3, it's now the most used language in the world, and they learned their lessons about the python2 to python3 migration. A python3 script is literally the most likely candidate to be still working/maintenable by someone else in 20 years.
Post reply on HN