[xhkkffbf]

I watched this happen decades ago. Smart coders knew about memory allocations. Okay coders just assumed that the garbage collector would handle it. One friend of mine wrote code that was 1000 times faster than the people in the next cubicle over. Why? Because he was careful with memory usage and didn't trigger the virtual memory thrashing.

AI is just another form of automation.

[Karellen]

Yeah, these new-fangled "compilers" will never catch on.

Programmers who rely on them will stop learning machine code, and won't know how their program really works. That's if the compiler actually compiles your code at all, without throwing an internal error, making you change your (correct) code around arbitrarily until it actually accepts it. But at least with an internal compiler error you know the compiler has broken - rather than it silently miscompiling your code to do the wrong thing.

But even then, even if the compiler accepts your code without barfing, and generates correct machine code from it, it still won't generate as efficient machine code as you could write by hand yourself.

Nope, these compilers will never catch on, and never get reliable enough to be useful for serious software engineering.

-- Some programmer circa 1975, probably, who lives in my head mumbling this to themselves whenever I'm sure generative-AI-based "programming" is a crock of shit. Although, to be fair, the 2005-era developer who is drunkenly ranting that UML diagrams will make programming 100x more productive any day now, is a handy counterpoint.

[SR2Z]

I mean, the difference between a computer and an LLM is correctness. The compiler MUST conform exactly to a spec. An LLM is useful precisely because it does not.

[feoren]

> One friend of mine wrote code that was 1000 times faster than the people in the next cubicle over

And did that 1000x speedup make a difference to users? Are we talking about an on-click event that now took 10μs instead of 10ms? Was this a 1000x speedup in a hot critical-path bottleneck, or was it an already quick in-memory post-processing operation that fired after waiting 30 seconds on a sluggish database query?

Sorry to doubt so much, but the vast majority of times someone boasts about a speedup like this, it turns out to be done for bragging rights rather than for the benefit of the project. A 1000x speedup is only impressive if you can show that the time you improved upon was actually a problem.

[jbreckmckye]

There must be a name for the self-balancing phenomenon where any improvement in productivity is soon swallowed up by an equal increase in waste

[tjalfi]

Are you referring to Jevon's Paradox[0]?

[0] https://en.wikipedia.org/wiki/Jevons_paradox

[jbreckmckye]

I guess it's a variant of that, Jevon's Paradox being that increasing supply counterintuitively increases demand

[cpeterso]

Nathan Myhrvold said “Software is a gas; it expands to fill its container.”

[jxjnskkzxxhx]

Must be it be swallowed up? Is it not possible that an improvement in productivity increases but still be net positive? I believe that's what happens in the real world.

[UncleEntity]

> Must be it be swallowed up?

Yes.

Because user CPU cycles are cheaper than developer brain power.