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

121–130 of 252 posts

Re: Software Rot

#121

Post by integralid »

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 used virtualenv for the past 15 years and I don't recall it changing significantly. I don't get why people use new fancy tools like pipenv/pyenv/poetry/uv and then complain that there are too many tools to learn. There is nothing wrong with just using virtualenv. It has its warts but it always worked for me and it's stable.

Re: Software Rot

#122

Post by treyd »

b_e_n_t_o_n wrote: post #76
mmackh wrote: post #26

Earlier quoted context omitted.

Not if software is tied to infrastructure, buildings, etc.

Perhaps software should be designed in such a way that despite it working on infrastructure, it can be swapped and discarded.

If it works and isn't broke then why swap or discard it?

Re: Software Rot

#123

Post by roda73 »

This is one of the reasons I absolutely hate Linux based development and operating systems built with it.

We all know it now as dependency hell, but what it is in fact is just a lazy shortcut for the current development that will bite you down the path. The corporate software is not a problem, because the corporate users don't care as long as it works now, in the future they will still rely on paid solutions that will continue working for them. For me, I run a local mirror of arch linux, because I don't want to connect to internet all the time to download a library that I might need or some software that I may require. I like it all here, but since I haven't updated in a while I might see some destructive update if I were to choose to update now. This should never happen, another thing that should never happen is if I were to compile an old version of some software. Time and time again, I will find a useful piece of software on github and I will naturally try compiling it, it's never easy, I will have to hunt the dependency it requires, then try compiling old versions of various libraries. It's just stupid, I wish it were easier and built smarter. Yes sometimes I want to run old software, that has no reason not to work. When you look at windows, it all works magically, well it's not magic it's just done smart. On GNU+Linux smart thinking like this is not welcome, it never has been. Instead they rely on huge amounts of people that develop this software, to perpetually update their programs for no reason, but to satisfy a meaningless number of a dependency.

Re: Software Rot

#124

Post by perrygeo »

I don't like the term "rot" - your software isn't rotting, it's exactly the same as when you last edited it. The rest of the software ecosystem didn't "rot" either, it evolved. And your old code didn't. "Extinction" seems a much better fit.

Re: Software Rot

#126

Post by superkuh »

wolvesechoes wrote: post #22
superkuh wrote: post #17

Unless explicitly addressed rot rate is proportional to popularity. Unpopular targets, platforms, languages, etc don't get changed and provide a much needed refuge. There are some interpreted languages like perl where a program written today could run on a perl from 2001 and a program from 2001 would run on perl today. And I'm not talking about in a container or with some special version. I'm talking about the system…

> Unpopular targets, platforms, languages, etc don't get changed Ah yes, Windows, some niche OS for hipsters and base-dwellers.

Windows was an amazing exception to this rule for 2 decades. It's incredibly impressive that win32 still works on modern Windows installs. But that's changing fast now.

Re: Software Rot

#127

Post by calvinmorrison »

eviks wrote: post #7
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…

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)

Calling perl poorly designed is absurd

Re: Software Rot

#128

Post by Cthulhu_ »

icameron wrote: post #18

Nobody 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 suspect this is true for a lot of software; a modern-day JVM can still run Java from 20 years ago as long as you didn't do anything weird, Linux hasn't significantly changed since then, the web is one of the most widely supported and standardized platform out there with the 1996 Space Jam website still working and rendering today as it was back then (your screen just got bigger).

Is software rot real? I'm sure, but it's not in the runtime. It's likely in the availability and compatibility of dependencies, and mainly the Node ecosystem.

Re: Software Rot

#129

Post by myaccountonhn »

Ygg2 wrote: post #68
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?

> When and why has "stable" become synonymous with "unmaintained"? Because the software ecosystem is not static. People want your software to have more features, be more secure, and be more performant. So you and every one of your competitors are on an update treadmill. If you ARE standing (aka being stable) on the treadmill, you'll fall off. If you are on the treadmill you are accumulating code, features, and bug fi…

> People want your software to have more features, be more secure, and be more performant

I think it's worth noting that one reason hardware rots is because software seems to become slower and slower while still doing the same thing it did 15 years ago.

Re: Software Rot

#130

Post by phkahler »

I'm looking at GTK here. Don't get me wrong, I like GTK and think it should be the preferred choice of GUI toolkit for many reasons. However, I have the same complaints a lot of people do about constant change and API compatibility issues. In some cases things need to change, but why going form 3 to 4 have menus been removed and require using other constructs? Could you at least provide a wrapper? Don't use event struct members directly, OK use accessor functions... But then you change the names and other details of the functions. It's not a "window" any more, it's a "surface" just because what? Beause Wayland calls them that? API stability is an important feature but these guys are talking about regular (say every 5 years) major version bumps that break things.
Post reply on HN