Notes from the Architect picks up Varnish as his application example to highlight that things have changed since then. You can extrapolate from his examples to, say, Python or Java versus BASIC or C.
I have spent many years working on the FreeBSD kernel, and only rarely did I venture into userland programming, but when I had occation to do so, I invariably found that people programmed like it was still 1975.
…
So what’s wrong with 1975 programming? The really short answer is that computers do not have two kinds of storage any more.
…
And people program this way.They have variables in “memory” and move data to and from “disk”.
Take Squid for instance, a 1975 program if I ever saw one: You tell it how much RAM it can use and how much disk it can use. It will then spend inordinate amounts of time keeping track of what HTTP objects are in RAM and which are on disk and it will move them forth and back depending on traffic patterns.
Well, today computers really only have one kind of storage, and it is usually some sort of disk, the operating system and the virtual memory management hardware has converted the RAM to a cache for the disk storage.
In other words, a critical part of 1975 programming was about memory management and temporary data storage on the machine. In modern applications programming, this is best left to the operating system. This is why garbage collection is such a big deal in modern programming languages. Application memory management in applications is a major source of bugs and can provide an access point for malicious code injection.
Of course, 1975 programming isn’t dead. A microcontroller is much like a 1975 computer in terms of memory management needs and there isn’t an OS to handle everything as the program itself directly deals with hardware. So there’s nothing wrong with 1975 programming. Like all software efforts and any other craft, tools and methods all have their place and a good craftsman chooses the right tools and methods for the task at hand.