Live data from Hacker News

Software Rot

permacomputing.net

231–240 of 252 posts

Re: Software Rot

#231
post #230

Earlier quoted context omitted.

Thanks for the interesting post! The -11 could do things like: mov (PC)+,R0 where the PC+ addressing mode picked the constant out of the next 16 bits in the instruction scheme. It's just brilliant.

I'm glad you liked it! Yeah, with (PC)+ (27), you didn't need a separate immediate addressing mode where you tried to stuff an operand such as 2 into the leftover bits in the instruction word; you could just put your full-word-sized immediate operands directly in the instruction stream, the way you did with subroutine parameters on the PDP-8. And there was a similar trick for @(PC)+ (37) where you could include the 1…

I rewrote my Empire game in PDP-11 assembler, long ago:

https://github.com/DigitalMars/Empire-for-PDP-11

but I have little knowledge of how the CPU works internally. One could learn the -11 instruction set in a half hour, but learning the AArch64 is a never-ending quest. 2000 instructions!

Re: Software Rot

#232

Earlier quoted context omitted.

What I mean is that the bar was set up for the lawyers themselves at that time. They didn’t create a 250 year plan for a Philadelphia bar that has played out in all that time and gotten us to today. It’s stayed in existence because it happened to stay useful for the lawyers that followed after them. Law itself is a collection of decisions made by judges and juries in trials, not decisions that are calibrated to have…

You don't see an institution that established useful norms persisting for lifetimes as one worth preserving and emulating? I do. Medieval guilds are another equivalent but they could not deal with the industrial revolution or colonialism, so they don't seem like something worth studying (outside of their failures) if it can't deal with societal change.

You’re missing what I’m saying. I’m not commenting at all on their usefulness. I’m saying that the motivating factors that build and grow institutions are short term. Institutions last because people happen to find them useful over successive short time horizons, or they’re able to change them to suit the needs of the time. There’s no super long term planning in it, some happened to have the right combination of elements and some didn’t.

Re: Software Rot

#233

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.

It can be as simple as a year change. A lot of old software rotted away once the year 2000 rolled around and more unmaintained software will in 2038.

Re: Software Rot

#234
post #207

Earlier quoted context omitted.

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

> still doing the same thing The core issue, in my humble opinion, is that it's not doing the same thing. But from a thousand miles away it looks like that, because everyone uses 20% of functionality, but everyone in aggregate uses 100% of functionality. > 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.…

Well Slack may have a few more features over IRC but none of them should cause my laptop fans to start spinning. Many of the slowdowns in modern web are because of trackers. Software may be more efficient but all that is neglected by software trying to do more. But so much of that "more" isn't resulting in more features for the user.

And yes convenience, social adoption and flashy modern appearance are major factors in the decision making. Whether it contributes to obsolescence or is fast isn't a factor at all.

Re: Software Rot

#235

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…

>And since you're probably not writing code that directly interfaces with the network layer, you're going to be reliant on all the libraries that do

That said, why the network layer doesn't run as a socks or http proxy or something? That would greatly simplify network logic. All network libraries provide old interfaces like streams and requests.

Re: Software Rot

#236
post #72

Earlier quoted context omitted.

So one effect I've seen over the last decade of working: if it never needs to change, and no one is adding features, then no one works on it. If no one works on it, and people quit / change teams / etc, eventually the team tasked with maintaining it doesn't know how it works. At which point they may not be suited to maintaining it anymore. This effect gets accelerated when teams or individuals make their code more ma…

That's probably true, but you're describing incentives and social dynamics, not a technological problem. I notice that every other kind of infrastructure in my life that I depend upon is maintained by qualified teams, sometimes for decades, who aren't incentivized to rebuild the thing every six months.

But why are those teams incentivized to exist?

For roads, brushes, wastewater, sewer, electricity - it's because these things are public utilities and ultimately there is accountability - from local government at least - that some of these things need to happen, and money is set aside specifically for it. An engineer can inspect a bridge and find cracks. They can inspect a water pipe and find rust or leaks.

It's much harder to see software showing lines of wear and tear, because most software problems are hard to observe and buried in the realities of Turing completeness making it hard to actually guarantee there aren't bugs; software is often easy to dismiss as good enough until it starts completely failing us.

A bridge is done when all the parts are in place and connected together. Much software is never really done because - it's rare to pay until we have nothing more to refactor - the software can only be as done as the requirements are detailed; if new details come to light or worse, change entirely, the software that previously looked done may not be. That would be insane for a bridge or road.

Re: Software Rot

#237
post #205

Earlier quoted context omitted.

But adding features isn't staying at the same spot.

Honestly. I think it is. All software exists in a kind of attract consumer/developer evolutionary race. If I assume your point is true, wouldn't everyone then just switch to Paint for all 2D picture editing? I mean it's the fastest - opens instantly on my machine vs 3-4sec for Krita/Gimp/Photoshop. But it's also bare bones. So why isn't Paint universal used by everyone? My assumption: what people want is to not waste…

I use paint, because it starts fast so I don't waste my time. When I want complex edit, I use paint.net - because it does everything yet starts million times faster than Krita/Gimp/Photoshop. In fact paint.net 3 already had all the features in 2008, after that it was vapid churn, it's literally impossible to notice the difference.

Re: Software Rot

#238
post #136

SQLite has an explicitly stated policy on this: "The intent of the developers is to support SQLite through the year 2050." https://www.sqlite.org/lts.html People talk about SQLite's reliability but they should also mention its stability and longevity. It's first-class in both. This is what serious engineering looks like.

That’s only another 25 years. Granted it’s already been around for a good while.

25 years is a very long time in our industry Think what about pieces of software from 25 years ago are still maintained and working

Re: Software Rot

#239
post #83

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.)

Don't bundle your JS then, problem solved. Vanilla JS and CSS written 20 years ago still works except maybe for a couple of obscure deprecated things.

Rot is directly proportional to the amount of dependencies. Software made responsibly with long term thinking in mind has dramatically less issues over time.

Re: Software Rot

#240
post #205

Earlier quoted context omitted.

Honestly. I think it is. All software exists in a kind of attract consumer/developer evolutionary race. If I assume your point is true, wouldn't everyone then just switch to Paint for all 2D picture editing? I mean it's the fastest - opens instantly on my machine vs 3-4sec for Krita/Gimp/Photoshop. But it's also bare bones. So why isn't Paint universal used by everyone? My assumption: what people want is to not waste…

I use paint, because it starts fast so I don't waste my time. When I want complex edit, I use paint.net - because it does everything yet starts million times faster than Krita/Gimp/Photoshop. In fact paint.net 3 already had all the features in 2008, after that it was vapid churn, it's literally impossible to notice the difference.

> When I want complex edit, I use paint.net

That's kind of my point. Even you eschew Paint's simplicity when you need a more complex transformation. Nothing you do in Paint.Net isn't impossible in Paint, given enough calculation and preparation. So a performance isn't the deciding factor. It's the speed of achieving thing X (of which startup/lag is a tiny cost).

Similarly in Paint.Net you could emulate many Photoshop features (e.g., non-destructive editing), but doing so would be tedious (duplicate layer, hide layer adjust copy layer, then edit until you get it to where you want it).

Post reply on HN