Old Programmer Rant Warning
Moore’s Law notwithstanding, some things in the programming world do not change. The ratios of cost between CPU cycles/Memory/Long-term Storage may shift slightly, but the hierarchy of cost seems to remain the same. The physical speeds of each also change, but seem to remain in the same hierarchy too—cache memory is faster than RAM, RAM is faster than ROM, ROM is faster than long-term access.
I’ve been writing code since 1973—I’d have to look up what a kilobyte of memory cost then, but the machine I started on had 8K. When the first microputers came on the scene in the late seventies, we paid around a $1,000 per K (about $4,000 current dollars.) In those terms, my current working machine (1gig) would be worth about $4,000,000,000 in memory alone.
In the mid-80’s I remember being pissed at a software vendor because their minimum memory configuration for their spread-sheet was “trying to keep it under 1 megabyte”—I remember asking the rep if they were selling memory chips with the code, since at the time a machine with the full 640K was not real common.
In the really really old days, the 1960’s, mainframers had developed something called code-swapping—a technique in which only the portion of code currently needed or projected to be needed was actually loaded into core, the remainder staying cheaply on the disk. This routine was widely used in early minicomputers, and again in CP/M systems. With the advent of microsoft’s DOS and Windows OS’s, it seemed that this entire generation of elegant, money saving, time saving hacks had been ignored—suddenly, every commercial program assumed that you owned lots of memory, and that it was all available and ready for their use—and with each new price drop, the programmers got more and more profligate with your memory.
Granted, in many cases it is no longer worth squeezing every last microcent worth of waste space out of your code, but short & sweet is still of value. It has never made sense to pay programmers (or writers for that matter) by the word—that merely incourages wasted space, often at the expense of readability and in the case of code, mainatainability.
It ought to be obvious by now to even the densest user, much less programmer, that there is seldom such a thing as “too much memory”, “too fast a cpu”, or “too much long-term storage.” Such things may, of course reach uneconomical levels. I seldom buy or recommend buying the hottest, fastest, newest processor or memory—it is seldom worth it for me or my clients to be trail-blazers. This month’s processor will cost several times what last year’s version cost, and offer only a slight increase in function—with a higher probability that it will have some sort of built-in problem. The same goes for nearly every component.
Still, there are always reasons to write efficient code. Smaller code uses less of everything, and no matter how cheap stuff becomes, it is unlikely to become free—resources always have some cost.
Everyone (under CP/M & DOS for certain) used to run one application program at a time. Multi-tasking was not a microcomputer task. Of course, it rapidly became possible to do so, but it was uncommon until processors reached a reasonable speed and memory reached a reasonable cost. It is still very common for most naïve users to run a single application at a time (or at least, to think that they are—today the number of background jobs run by the OS and various apps is truly spectacular.) I myself tend to beat the heck out of software, running hundreds of open applications simultaneously. (My current favorite browser, Opera, became my favorite initially because as well as being small, it didn’t open a new version of itself with every new window—I normally have over a hundred windows open, and have counted up to three hundred—over a 28.8K dialup connection!)
Besides saving space (money) of course, smaller code is (to a point) more readable code, which means easier to understand, maintain and modify. This also translates into money. Some of the early code-generation programs were awful at code-bloat, I remember taking a program, running through a conversion program and having the final code-generated version (executable) expand to 400% with now changed functionality. The expanded source code generated was 800%, and nearly unreadable. Optimizing compilers help, but since software generations are considerably longer than hardware generations, they do not improve very rapidly. And code has long lifetimes. There is still LOTS of COBOL, RPG & FORTRAN code out there, much of it written 30-40 years ago and mission-critical to the business. Old code doesn’t die, just the people who understand it.
I’ve always felt that part of the problem is that developers historically have been provided with the “latest & greatest” hardware, under the proper assumption that they will need all the resources that they can get. This is fine, and usually appropriate—I’ve spent years sitting at a terminal waiting for compiles on miniputers. In fact, I’ve had clients where I took the entire afternoon off and came in before the factory started because I had to run compiles on production machines on which an afternoon compile would take all afternoon, an the same compile would run in a minute or two in the early morning. Even editing was slow enough to make you doze off. (Believe me, at the equivalent of $3,000 per day current money, the customer is not happy to find you asleep at your machine!)
For development it makes sense to use the best equipment you can throw at the process, developer time is expensive in both direct and marketing terms. What I’ve always felt needed to happen before releasing the software is to test it on the then-current customer hardware—usually a machine based on hardware at least 2 years old. Software which runs adequetly on today’s hardware may well be irritatingly slow on last year’s model. This will affect the customers—and sales!
Smaller code will always load faster from long-term storage too. Of course, segmented code can load even faster, and there are tricks to use to bring up the user-interface while still loading the other portions of the program. Unfortunately these (ancient) devices seem to be underutilized by most commercial software—despite decades of proof that sub-second response time is important to user productivity. Most likely this is because the purchasers of software do not complain about the loading speed, there is a tendency among all users (even programmers) to believe that such things are “just the way things are.” Poppycock! A programmable device is just that programmable which means that nearly any aspect of how it works can be modified by a programmer! I can forgive the naïve end-user of this—they really cannot do much about such things except boycott the product and demand that it be fixed. But programmers should know better! But programmers too often act as naïve end users for such things as OS’s and programming tools, and you do not have to settle for inferior products (at least not long term.) Insist that the manufactures spend the time and money to correct the problems which affect you on a constant basis—sure, it only takes 5 minutes to reboot your system (in your dreams,) but if you do it daily that is a lot of wasted time. And if you have to load an application hundreds of times a day, even a wasted couple of seconds is unacceptable. Of course, many applications now pre-load in the background, but this has a cost in resources too (for starters, its part of the reason it takes so long to boot your machine.)
In the 1980’s I ran all the data processing for a $10 million in sales manufacturer on a machine with 256K of memory and 256Meg of hard-drive space. The machine itself was obsolete at the time, but the replacement I bought, which was about 3 times faster and twice as much space, cost about $55,000. I’m writing this on a machine I build last year for about $300 which has 1gig of memory and only about 30 gig of hard-drive. Yes, the hardware & software have gotten cheaper (the software on that monster cost $250,000 plus a year’s worth of labor to install it.) None of it is yet free, and it still costs money to operate it. And the ratios are still about the same, hardware is the cheap part of the system. Installation, training and maintenance of software are still the expensive parts.