polarity wrote:
Old days: the memory and CPU was limited, so computer code had to be written to a very high standard to reduce it's memory footprint, and optimise the number of CPU cycles it used.
Present day: programmers just look at the amount of memory and CPU power available, and don't make the slightest effort to optimise anything.
If programming was done to the same standard as it was when 8 bit was the norm, computers would probably be 10x as fast. But then programming would be a much harder job. Writing windows in optimised assembly language would take decades.
The reality is vastly more complex and I can quickly add a few extra considerations to chew on.
One is the level of craftsmanship that exists within the programmers, themselves. When I started out, the level of training and skill of even the more modest programmers was fairly high. I still have some of the books used by manufacturers, whose job was not necessarily to teach but to sell products, and they include quite a range of detailed instruction on subjects as wide as operating systems, coroutine design, runtime program design, as well as various compiler skills. Most folks making a profession of it quickly acquired programming skills in a wide variety of languages, not only assembly of course, which at the time would usually include algol, basic, fortran, pascal, c, and cobol. As well as that, many bits of equipment wasn't entirely reliable and much of it very, very slow (magtape drives, for example) so even more effort was spent understanding highly technical and some ways similarly mathematical techniques required to apply these devices effectively and efficiently. When such programmers are faced with new challenges, they bring to the table a much wider range of skill sets and often are better positioned to fashion efficient designs from the outset. For example, because they are much more familiar as a rule with a wider base of mathematics, it isn't uncommon for them to be familiar with techniques such as Chebyshev and the application of minimax techniques to improving the performance of some transcendental problems; or the use of quaternions instead of basic rotation matrix methods for many motion problems found in 3D game systems; to name a few. This doesn't mean more coding time. It means bringing more to the table. And the base of programmers today are simply not as well trained, as a rule, now. Most are well below the base of the pyramid that used to exist "back in the day" and choose programming as an alternative to, say, accounting... more because they are looking for less stress than because of it "being in their bones," so to speak. I've taught undergrad classes of students at university level and I have seen the changes over my lifetime in those considering this avocation. This isn't the fault of the students, but instead a fault of the tremendous success a prior generation of well trained programmers have had in making computers more accessible to all, business and personal use alike, and the growing demand for any skill at all, whether it be merely HTML and PHP or something more. The "tent" is much bigger now and a much greater difference between the most skilled and the least skilled within it is now possible. Programmers no longer need to understand how to implement serialization, for example, as Microsoft's engineers have nearly removed this problem and spun off languages that completely hide the problem. .NET is one such example, I'm thinking of. Lots more people, with less skill, can program fairly competent programs with very little real training, as a result. This wider tent of programmers means less average skill, which necessarily also requires more sophisticated and broad-based hidden support for otherwise difficult situations and because that support needs to cover a great many possible ills in order to be sufficiently general purpose to not require specialized skills to apply it, is also necessarily overburdened by excess layers of software -- both to provide general skill that is lacking in the programmers and also to provide a maintainable base of software by companies such as Microsoft in the face of a deepening complexity. (Layering helps keep things small enough to understand and deal with, piecemeal.)
Another point is highlighted by the fact (and it is my own direct experience, if no others') that some operating systems use the resources existing in the hardware better than others do. And some features are not in the users' direct interests. The case of Vista is manifest. In Microsoft's rabid desire to both satisfy some content providers, such as Sony, as well as to muscle into that business in their own right, they have burdened their own operating system with very significant and complex hurdles just to get something as modest as music to play. There is a carefully crafted degradation of digital signals which must also be supported not only by the software, but also by hardware devices connected to it. These things cost processing power. By design, not by some lack of effort applied (quite the opposite, really.)
Also, while one can argue that the price for software has greatly declined (I would pay, gladly, some $3000 to $5000 for a compiler from DEC, back when a young worker might expect some $600/month as a reasonable salary) in the intervening years, it's also true that the customer base has greatly widened and that total software revenues are astronomical by comparison, even using a "standard dollar" by which to compare. There is so much more money to be made in the business, now. So it isn't possible to argue that less real programming effort should be expended to cut costs. Instead, there is simply a lot more money available for performing good programming. Were it that you could actually find highly skilled programmers to perform it.
There are many "user desired" features which are superfluous to purposes intended but add to the sales "bullet marks" in magazine comparison articles and help sell products. "Docking toolbars" are an example. The IDE programming environment, almost assumed as a must these days, is nearly entirely excess baggage that takes away good programming skill of the vendor and borrows it from advancing the compiler tool itself -- which is the real core value.
To add to your point, though, the software development cycle has definitely shortened in the competitive environment. Nowhere is this easier to see than in gaming. Software life cycles on the shelf, except for some exceptionally good cases, are measured in mere months. Often, 3 or 4 months. Sometimes, much less. How much time can anyone afford to invest in some piece of software that will be yesterday's history in half a year? That fact also tends to drive large, complex, and slow libraries that provide a cornucopia of features to attract the widest possible audience. In meeting that wide need and providing general services not scaled down to any particular use, they are slower than needed even when very well written.
Not all operating environments make the same use of the hardware, so it is a given that better can be done since we have manifest examples to show us that fact. Anyway, the basic point I wanted to leave with is that while I don't disagree with the thrust you made, that more effort at programming can pay off in terms of efficiency of execution, that doesn't necessarily justify a "whatever will be, will be" attitude about it. Programmers need to work hard to improve their skill sets, too. That still pays off, as well.
Jon
12 Jan 2008, 1:01 pm
