Ask HN: Was programming more interesting when memory usage was a concern?

For the people who found that interesting, yes, it was more interesting back then. Most projects were tight on memory, so those skills were needed, and easy to find comrades in the struggle.

However, people go into programming for many reasons. For those who were not interested in squeezing out every word, it was not interesting. Probably some people realized their tasks couldn't be done in the limited hardware of the time, so didn't even try until memory became significantly cheaper.

The past can seem like a golden era of mythic heroes.

Some from the generation you envy are themselves envious of the previous generation, where programmers were expected to write their own operating system - the vendor didn't provide one - and pull out a soldering iron and oscilloscope for debugging.

When many were writing yet another COBOL program for accounts processing.

Memory stopped being a big limiter on the desktop way before 2014. You'd want to go back to the 90s for it to be a major change in how things were done. So, back when people had 8mb of RAM or maybe 16mb if the machine was high spec and in theory Windows could run in 4mb. Swap existed but disks were so slow that if you actually hit swap then your machine would drag to a halt.

Anyway. No, it really wasn't cool.

The thing to realize is that software wasn't really that much better optimized for RAM than today. Maybe a bit, but mostly it just created a lot of pain:

- Every single API was specified to be able to fail due to OOM, and a lot of programmers tried to check for this and recover. However, there were no good ways to simulate or test it, and unit testing was in its infancy as a practice (e.g. no widely adopted frameworks for testing), and so in practice this just yielded a ton of codepaths and boilerplate that never really got tested and probably didn't work.

- Because RAM was so tight, you pretty much had to use the operating system's APIs for everything, even if they sucked or were full of bugs. It wasn't just RAM of course, it was also disk space, CD space, nearly non-existent network bandwidth. Duplication of what Windows had wasn't feasible. It meant everything was pretty consistent, which had its upsides, but it also meant that everything was consistently quite ugly and the horrible Windows/macOS APIs were all you got.

- Memory limits resulted in awkward APIs. No type safety, no enums (only bit flags), no reflection, lots of annoying (and by the late 90s obsolete) memory locking protocols that were holdovers from win16, and "rerendering" literally meant re-drawing small areas of the screen because pixels weren't cached. In particular a lot of APIs required you to call them twice, once to figure out how much memory something would require, and then a second time to fill out that memory once it was allocated.

- Error messages? Logging? Hah no. You get 32 bit error codes because there isn't enough memory or disk space for all the strings proper logging and errors would require. So you got really good at decoding HRESULTs.

- Garbage collection existed as a tech but because swap was so slow and RAM so tight it was very easy for it to trigger swap storms, so in common practice automatic memory management (when it existed) was all based on refcounting. So you couldn't quite just forget about it because you could still leak memory pretty easily even using a higher level language like VB.

The transition towards relative memory abundance was fairly painful. For example, Java because popular with devs because it had all those nice things that used a lot of memory but it led to slow/swappy apps that were painful for users. You still see the same complaints w.r.t. Electron apps, though today machines can take it and so it's more about people feeling it's wasteful rather than it literally killing the responsiveness of the machine like it used to be.

Of course in the above I say "was" and "used to be" but if you ever have to do any Win32 or low level POSIX programming you'll be right back in that world.

There are still some performance-sensitive niches that you might enjoy. Large scale numeric simulation workloads can have a variety of bottlenecks, and the difference between the easiest solution and the fastest solution can be orders of magnitude. Smart contract development also requires tight memory management, otherwise the fees can become prohibitively high.

Yes, knowing your hardware always helped. Subroutines used frequently and placed early in the code helped reduce memory use and improve speed. Back in the early 1980's "80 Microcomputing" magazine ran an annual competition for BASIC one line programs. Some entries proved just how clever some coders could be. https://en.wikipedia.org/wiki/80_Micro