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

211–220 of 252 posts

Re: Software Rot

#211

Post by 8n4vidtmkvmk »

eviks wrote: post #103
legends2k wrote: post #90

Earlier quoted context omitted.

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?

I'd advocate for 'nano' on Linux because it's widely installed and easy for newcomers. A seasoned professional will know they can substitute vim or what have you, I don't need to explain that to them. So yes... If I was trying to explain to a noob how to open a text file on windows and I don't know what they have installed, I'd absolutely tell them to use notepad.

Would I advocate writing my core business software in bash or perl? No, I'd hire and train for what was chosen. For small scripts I might need to share with coworkers? 100%

Re: Software Rot

#212

Post by 8n4vidtmkvmk »

perrygeo wrote: post #124

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.

If the apple remains pristine, but the tree trunk dies, it doesn't much matter that the apple hasn't changed. It dies with the tree.

Re: Software Rot

#213

Post by 8n4vidtmkvmk »

rgmerk wrote: post #66

You can't build permanent software in a world where a) everything is connected to everything else, and b) hackers will exploit anything and everything they can get their hands on.

Isn't that half the problem right there? Stop connecting everything to everything. Make your app work offline. And for anything that must connect, at least use a well defined API that can swap for some other service. E.g. S3 API is now defacto for block storage.

Re: Software Rot

#214

Post by 8n4vidtmkvmk »

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…

I recently discovered how many of my bash scripts run perfectly fine in git-bash on windows. I was pleased. I believe Bun (yes the js runtime) can run .sh scripts too. And of course under WSL too. So 3 different ways I can run them on Windows. File paths can get a little sketchy but with a couple helpers it's not hard to convert back and forth.

Re: Software Rot

#215

Post by 8n4vidtmkvmk »

collinmcnulty wrote: post #112

In my experience, the most common type of rot is that the real world the software describes has changed. For instance, I wrote software that modeled electrical power contracts, and when those real world contracts’ structure changes, no amount of “bedrock platform” is going to prevent that rot.

I don't know anything about electrical power, but this reminds me about a story about making assumptions about human relationships. Like, you can legally be your own grandfather. Does your program account for that? Software needs to be flexible to account for new, weird scenarios. Sometimes we just can't predict everything, but we can try.

Re: Software Rot

#216

Post by 8n4vidtmkvmk »

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.

I don't want to reformat my fridge.

Re: Software Rot

#217

Post by 8n4vidtmkvmk »

flomo wrote: post #83
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.)

I've been debating how to go abouts installing js packages directly into my project. Like when I update a dependency, show me the diff for that whole project, not just my package.json bump. If it's good, I'll just accept the merge as-is. If it's bad, it can stay pinned to that version forever. No downloads. I guess this doesn't solve the "peer dependency" issue if 2 different things depend on 1 thing in a way such that I can't have 2 copies of the lib (eg react 18 and 19 is a nono but 2 lodashes is fine). Hmm.. a man can dream.

Re: Software Rot

#218

Post by 8n4vidtmkvmk »

mook wrote: post #40
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.

Things like E4X, sharp variables, and array comprehensions have already been removed; it's just that the mass of newer developers mean the average doesn't know about them. Unfortunately it's not like they never remove things.

I didn't know about either of those, and I've been using js for 20ish years. I could have used those sharp variables in a previous project! Fortunately it's not terribly hard to do the same thing with an IIFE. Or get() method.

Re: Software Rot

#219

Post by 8n4vidtmkvmk »

jillesvangurp wrote: post #12
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.

Except of course software rot and javascript code bases go hand in hand. You seem to assume, browsers have stopped changing and will be more or less the same 75 years from now. I think you are right that that code might run. But probably in some kind of emulator. In the same way we deal with IBM mainframes right now. Hardware and OS have long since gone the way of the dodo. But you can get stuff running on generic li…

If they want to introduce html6, they'll add a new doctype. If they want moderner JS they'll do another 'stricter' or file type or what have you. The fact that it will continue to run with zero changes is good enough.
Post reply on HN