Live data from Hacker News

The great software quality collapse or, how we normalized catastrophe

techtrenches.substack.com

51–60 of 260 posts

Re: The great software quality collapse or, how we normalized catastrophe

#51
post #31

I don't want to sound too dismissive, but all these arguments have been brought up time and again. The move from assembler to high level languages. The introduction of OOP. Component architecture / COM / CORBA / etc. The development of the web browser. The introduction of Java. 2018 isn't "the start of the decline", it's just another data point on a line that leads from, y'know, Elite 8-bit on a single tape in a few…

> If you plot the line it's probably still curving up and I'm not clear at which point (if ever) it would start bending the other way. I suspect when Moore‘s law ends and we cannot build substantially faster machines anymore.

One interesting thing that most non-systems programmers don’t know is that memory and cpu performance have improved at completely different rates. That’s a large part of why we have x times faster CPUs but software is still slow.

The systems people worry more about memory usage for this reason, and prefer manual memory management.

Re: The great software quality collapse or, how we normalized catastrophe

#52

Just false nostalgia memory. 20 years ago things werent any better. Software didn't consume gigabytes of ram because there was no gigabytes of ram to consume.

20 years ago, you could consistently pick up a phone, get a dial tone, and then call a human to solve a problem.

Sure, plenty of stuff didn't work. The issue is we're not bothering to make anything that does. It's a clear cultural shift and all of this "nothing ever worked so why try" talk here is not what I remember.

We're in a stochastic era of scale where individual experiences do not matter. AI turning computers from predictable to not is in the same direction but with yet more velocity.

Re: The great software quality collapse or, how we normalized catastrophe

#53

> Every 10x increase in model size requires 10x more power Does it? I’ll be the first to admit I am so far behind on this area, but isn’t this assuming the hardware isn’t improving over time as well? Or am I missing the boat here?

Hardware gets faster but efficiency is stalling if not getting worse.

Re: The great software quality collapse or, how we normalized catastrophe

#54
The original Supaplex game is 287 kB (https://www.dosgamesarchive.com/download/supaplex). It was written in Assembly.

Its remake on Steam (precisely the same levels) weights around 200 MB. Not sure what goes there, but I bet there is more than one wrapper.

Re: The great software quality collapse or, how we normalized catastrophe

#55
post #31

I don't want to sound too dismissive, but all these arguments have been brought up time and again. The move from assembler to high level languages. The introduction of OOP. Component architecture / COM / CORBA / etc. The development of the web browser. The introduction of Java. 2018 isn't "the start of the decline", it's just another data point on a line that leads from, y'know, Elite 8-bit on a single tape in a few…

> If you plot the line it's probably still curving up and I'm not clear at which point (if ever) it would start bending the other way. I suspect when Moore‘s law ends and we cannot build substantially faster machines anymore.

But the machines aren't really "faster" in clock speed— for a long time now the gains have been in better and more local caching + parallelism at both the core and instruction level.

Re: The great software quality collapse or, how we normalized catastrophe

#56
A browser using 32 GB for 8 tab isn't necessarily wasteful, there is a lot of caching one can do to make back/forward buttons extremely fast. It would be wasteful to not allocate that memory if it is otherwise free and unused. Usually browsers use up what is available. The more interesting metric would be whether starting another high-RAM application will lead the browser to give up most of the 32 GB.

Re: The great software quality collapse or, how we normalized catastrophe

#57
post #31

I don't want to sound too dismissive, but all these arguments have been brought up time and again. The move from assembler to high level languages. The introduction of OOP. Component architecture / COM / CORBA / etc. The development of the web browser. The introduction of Java. 2018 isn't "the start of the decline", it's just another data point on a line that leads from, y'know, Elite 8-bit on a single tape in a few…

> If you plot the line it's probably still curving up and I'm not clear at which point (if ever) it would start bending the other way. I suspect when Moore‘s law ends and we cannot build substantially faster machines anymore.

Moore's law has kind of ended already though, and maybe has done for a few years, and even if you can make a chip which is faster there's a basic thermodynamics problem running it at full tilt for any meaningful period of time. I would have expected that to have impacted software development, and I don't think it particularly has, and there's also no obvious gain in e.g. compilers or other optimization which would have countered the effect.

Re: The great software quality collapse or, how we normalized catastrophe

#58
post #28

Unrelated but my current AI text flag is the use of "It's not X. It's Y." It's become so repetitive recently. Examples from this post alone: 1. "This isn't about AI. The quality crisis started years before ChatGPT existed." 2. "The degradation isn't gradual—it's exponential." 3. "These aren't feature requirements. They're memory leaks that nobody bothered to fix." 4. "This wasn't sophisticated. This was Computer Scie…

Yeah I can see this can be an irritating rhetorical device. It implies that the reader already has a certain judgement or explanation, and makes a straw man in order to turn around and then argue against it, throwing nuance out the window.

It’s not nuance, it’s intellectual dishonesty.

Re: The great software quality collapse or, how we normalized catastrophe

#59
I wouldn’t blame the “ever expanding” abstractions as the root cause behind lower quality. Adding layers of abstraction is how we make ever more complex software. It’s misleading to think that just because the main human interface idioms have remained similar (mouse, pointer, windows, task bars, etc), there hasn’t been an astronomical increase in depth and complexity of what one can do on one’s system.

And it’s not all bad. Yes, SwiftUI can be glitchy but at the name time, it gives us an extremely simple API to create everything from complex UIs to widgets. Yes you have “more control” with App/UIKit but that comes at the cost of extra learning curve and development time. And we live in a world that’s unfortunately still driven by money, so every app or system has some constraints that push the limits of what we can do.

Re: The great software quality collapse or, how we normalized catastrophe

#60
post #31

I don't want to sound too dismissive, but all these arguments have been brought up time and again. The move from assembler to high level languages. The introduction of OOP. Component architecture / COM / CORBA / etc. The development of the web browser. The introduction of Java. 2018 isn't "the start of the decline", it's just another data point on a line that leads from, y'know, Elite 8-bit on a single tape in a few…

> If you plot the line it's probably still curving up and I'm not clear at which point (if ever) it would start bending the other way. I suspect when Moore‘s law ends and we cannot build substantially faster machines anymore.

[deleted]
Post reply on HN