IMO, that quote's garbage and really "back in my day". Our resources are just more powerful today. We still run into performance issues with things like bulk updates and computation times (MapReduce / distributed computing) quite frequently.
The really interesting thing about the quote is that it is from 1986 but could have been stated the same way in 1996, 2006 and likely in 2016 with the same "10 year back" qualifier and nobody would bat an eyelash. Systems are way more powerful but we're also pushing a LOT more data (in terms of depth of the data, breadth of the data, and types of data).
To be fair though, these days a lot of people see "spin up 25 more AWS instances" as a perfectly valid way of solving a bottleneck when compared to months of developer time whereas back in 1986 the decision would be a no-brainer in the other direction given that the equivalent of spinning up 25 AWS instances today would be economically infeasible back then for almost any commercial entity (even if you scaled back the amount of processing needed to fit in the context of that era).
Which is the whole point if the quote. And the "back in my day" is 100% true in the field of programming. Ever heard of Moore's law? Ever tried to program with 8K RAM?
>We still run into performance issues with things like bulk updates and computation times (MapReduce / distributed computing) quite frequently.
Yes, we still run into "performance issues". But with MILLION times the data they ran into performance issues with.
Heck, we can now do a whole computer of the time interpreted in a web browser in Javascript and still get acceptable speed to play games in it.
Perspective man.
You've just fully booted linux in your browser. That Linux sees 16 MB RAM for itself. If you are a web programmer, do you even try to see how much memory the browser spent for this, or any other page you click to?
edit: but yes, it's amazing.
Do you really think developers these days are just as good at optimizing for limited system resources as they were in 1986?
"We still run into..." Who? Maybe you - but most developers aren't running into map/reduce problems every day. And when they do, they certainly aren't coding a solution from scratch.
Yes boxes are faster and easier to spin up. The 'downside' to that is that many website on the internet are blazingly fast: Google, Amazon, Dropbox, etc. Because they are so fast (or perceptibly fast via tricks), the rest of the web is held to that higher standard. Twenty years ago, things taking a long time on a computer screen with no updates was acceptable. Today it really isn't because there are N other websites that are selling your exact product or experience.
Have you ever programmed a embedded system? Every worked on a 8-bit micro controller?
There are hard, very hard problems that come up which have to solved in with really limited resources.
My point is that those problems aren't any harder. They're just different. (in many cases it's because the toolchains stink by modern standards--embedded systems tend to just crash with no helpful debugging information) BG and co stood on the shoulders of the guys who made their chips 'just work' just as we stand on their shoulders. To complain about how 'kids have it so easy these days' just makes you sound crotchety.
Not really. The problems are made a lot harder by finite memory being more in play. Even with a good tool-chain when you actually have more data then you have RAM then you'll run into problems that are completely unique to an embedded world.
Code shrinks are very hard.