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

81–90 of 252 posts

Re: Software Rot

#81

Post by Ygg2 »

codeflo wrote: post #74
Ygg2 wrote: post #68

Earlier quoted context omitted.

> 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, have fewer bugs, and not be exploited. So you and every one of your competitors are on an update treadmill. If you ARE stable, you'll probably fall off. If you are on the treadmill you are accumulating code, features, bug fixes, until you either get off or a faster competitor emerges. Runners on treadmills don't actually move forward.

Kinda the point of the threadmill metaphor. If you are standing on a threadmill, you will fall right off. It requires great effort to just stay at one spot.

Re: Software Rot

#82

Post by eviks »

oguz-ismail wrote: post #65
eviks wrote: post #58

Earlier quoted context omitted.

Indeed, double skill issue: one with the designers and the other one with the users having poor tool evaluation skills

> poor tool evaluation skills Both tools in question are installed everywhere and get the job done. There isn't much to evaluate, and nothing to compare against

> 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"

Re: Software Rot

#83

Post by flomo »

bravesoul2 wrote: post #3

JS is hated but if you compile to browser JS that code will run in 2100. If you mainly deal with files / blobs not databases you will have these things in 2100 too. I think a lot of apps can be JS plus Dropbox integration to sync files. Dropbox may rot but make that a plugin (seperate .js file) and offer local read/write too and I think you'd be pretty future proof.

You are right that your javascript bundle will probably run forever as-is. However, three years later your toolchain will be totally broken and now you are in NPM Hell trying to fix it. Ten years later, good luck.

(S3 better example than Dropbox. That will mostly be around forever.)

Re: Software Rot

#84

Post by vrighter »

Ygg2 wrote: post #57
foxrider wrote: post #37

Python 2 situation opened my eyes to this. To this day I see a lot of py2 stuff floating around, especially around work environments. So much so, in fact, that I had to make scripts that automatically pull the sources of 2.7.18 and build them in the minimal configuration to run stuff.

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?

Re: Software Rot

#85

Post by rerdavies »

jwrallie wrote: post #34
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.

I am considering learning Win32 for that purpose, not that I plan to do anything complicated with it, but for small single purpose tools it should be useful, at least when some kind of UI is needed.

Don't do it! Seriously! Terrible awful stuff to use. Even worse to program for!

Re: Software Rot

#86

Post by Falkon1313 »

Over the course of my learning and my career, I've kind of gone back and forth on this a bit.

On the one hand, software is like a living thing. Once you bring it into this world, you need to nurture it and care for it, because its needs, and the environment around it, and the people who use it, are constantly changing and evolving. This is a beautiful sentiment.

On the other hand, it's really nice to just be done with something. To have it completed, finished, move on to something else. And still be able to use the thing you built two or three decades later and have it work just fine.

The sheer drudgery of maintenance and porting and constant updates and incompatibilities sucks my will to live. I could be creating something new, building something else, improving something, instead, I'm stuck here doing CPR on everything that I have to keep alive.

I'm leaning more and more toward things that will stand on their own in the long-term. Stable. Done. Boring. Lasting. You can always come back and add or fix something if you want. But you don't have to lose sleep just keeping it alive. You can relax and go do other things.

I feel like we've put ourselves in a weird predicament with that.

I can't help but think of Super Star Trek, originally written in the 1970s on a mainframe, based on a late 1960s program (the original mainframe Star Trek), I think. It was ported to DOS in the 1990s and still runs fine today. There's not a new release every two weeks. Doesn't need to be. Just a typo or bugfix every few years. And they're not that big a deal. -- https://almy.us/sst.html

I think that's more what we should be striving for. If someone reports a rare bug after 50 years, sure, fix it and make a new release. The rest of your time, you can be doing other stuff.

Re: Software Rot

#87

Post by zkry »

xenodium wrote: post #75

While Emacs itself is not entirely immune to software rot (external dependencies and all), it’s truly amazing how little to no rot is experienced by elisp software (packages). If you find an Emacs package written 15 years ago, the chances of successfully running out of the box are incredibly high.

I was thinking the exact same thing. As long as you're not depending on any external packages things are very stable. Like, if you're package depends on adding advice to some other package's random internal function, then yeah, it could easily break.

It's a great feeling knowing any tool I write in Elisp will likely work for the rest of my life as is.

Re: Software Rot

#88

Post by Ygg2 »

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?

I do recall some paper mentioning it. But now I'm not sure if Google is gaslighting me or it never existed. But it seems you are right.

Re: Software Rot

#89

Post by blueflow »

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)

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.

Re: Software Rot

#90

Post by legends2k »

eviks wrote: post #82
oguz-ismail wrote: post #65

Earlier quoted context omitted.

> poor tool evaluation skills Both tools in question are installed everywhere and get the job done. There isn't much to evaluate, and nothing to compare against

> 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 get.
Post reply on HN