Live data from Hacker News

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

news.ycombinator.com

21–30 of 50 posts

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

#23
Constraints are what make puzzles interesting. Low memory/compute/throughput/etc availability makes software more like a good puzzle.

The more constraints you remove, the more something transitions from being a puzzle to being a canvas. Each end appeals to different kinds of people.

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

#24
Its still a huge concern. Cache today is what memory was in the 80s and 90s. Memory today is what disk was. And your L1 cache today might be 64kb! That’s basically what you can work with if you want to use your CPU at full speed.

For anything that isn’t IO bound you are very often bound by memory access time. CPUs are incredibly fast and feeding them data to work on is very difficult, more so today than before!

The big difference is that a category of programming jobs has appeared where this is almost never a concern because it’s about shoving text around between servers.

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

#25
a huge amount of effort went into managing "soft loading" assets in RAM pre-1995 or so, even later. To swap allocated blocks in and out well was very much a thing. Games got away with different tricks since forever, then secondly desktop work apps with non-trivial parts included things like this. Does it make you sharper or the work more interesting to have to jump through hoops on a regular basis? YMMV

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

#26
post #5
post #3

It still is cool because of memory and CPU (power) and code constraints for embedded computing.

I do want to get into that but where I am at embedded computing jobs are kind of rare. I do like programming in C quite a bit.

It's nearly the exact opposite of resource-constrained computing, but HPC / exabyte-scale storage type stuff has some of the same vibe of needing to know your hardware and wanting to squeeze the most out of it that you can. Consistently saturating a 100GbE link is a very different problem from dynamic data structure allocation on a microcontroller or whatever, but you have to care about some of the same sorts of things.

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

#27
In many ways it's still a problem. Sure you've now got xx-GB of RAM and zz-TB of storage, but you now live in a world where images and video are used for day-to-day comms, instead of text.

Compared with (say) 20 years ago, you've got 20-50 times more memory, and your data is 20-50 times (or more) bigger.

We're doing the same as always, but using more bits, because bits are cheaper.

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

#28
It is still cool. An easy path to success: find a medium to large company with a strong engineering culture, join, and start memory profiling things. You will likely end up with 1-2 line commits that reduce memory usage across the entire fleet of services by 20-50%.

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

#30
The first programming job I had was programming operating systems for Micom 2000 word processors, back in 1979, two years before the IBM PC was released.

The machine had an 8-bit Z80 processors, 128k of bank-swappable memory (64k address space), and two 8" 240kb floppy disk drives.

The 8080 assembler source for my module was spread over 14 floppy disks. Compiling involved meticulously swapping floppies in the correct order for about a day and half. Inserting the wrong floppy in the wrong order would cause the build to fail, and you'd have to start over from scratch.

Despite that, one had a breathless sense that you were working with a technology that was about to change everything. The implications of the coming technological age were unmistakable. And the only limit was imagination and ingenuity.

Having a MILLION instructions a second to play with seemed limitless; but having to fit things into 16kb memory pages felt a bit constraining. For the most part, user data had to fit in a 16kb memory page because that was all that was left over after the operating system was loaded.

In retrospect, there's only so much you can do with a 4Mhz processor when you only have 16kb of data to work with, so processing power wasn't the constraint.

Probably exactly the same as what it's like to be working with AI technology today. Everything is going to change. And the future is going to be unrecognizable. And you're sitting in the middle of it.

So yes, absolutely, it was way cooler back then. Unless you're currently working on AI projects.

Post reply on HN