Worst 'Ware -- Ever
Jeff Taylor | August 20, 2004, 1:30am
For techie rubber-neckers, here's a list of the worst "software disasters" for PCs. Pretty solid, although I note that MS Bob was an interesting idea poorly done. It still needs to be done.
I'd also consider sticking all of OS/2 on the list as a penalty for what-might-have-been. Great PC OS from a company that, deep down, really didn't want the world to become PC-centric.
James Anderson Merritt | August 21, 2004, 5:25am | #
I haven't trusted Dvorak's opinions or his standards of journalism since he tried to wheedle gossip out of me when I was working for personal computer pioneer
North Star Computers in Berkeley, back in the late 1970s. (This was at a time, when Bill Gates was still coming to Homebrew Computer Club cocktail parties in the region. I always wondered what might have happened in the PC industry, had someone set Bill up on a life-changing date back in those days. Would we all be using OS/2 now?)
I think Dvorak is way off on his estimation of the
UCSD P-System and the subsequent development of
Modula-2. First, there is no way you can call programs in p-code "bloated." They executed relatively slowly, because they were interpreted, just like BASIC programs of the day. Later Pascals, such as
Borland's Turbo Pascal (which was eventually folded into their
Delphi integrated development environment), produced actual, executable machine code; although such executables ran much more quickly than the equivalent p-code programs, they also tended to take up more room in memory and on disk. P-code programs were extremely compact, one of the qualities that allowed a complete operating system and development environment to fit in
a tiny Apple II computer, for example, with room left over for a significant application program to run along with its data. If Pascal encouraged bloatware in any way, it was through the ease with which developers could add features to their programs, and assemble together very large and ambitious software systems in a shorter length of time than before.
By Dvorak's own standards, I think that his inclusion of the Modula-2 programming language is mistaken. He freely admits that some software wasn't bad, it was merely disliked, and I think that Modula-2 falls in that category. M2 had its quirks and unfortunate aspects (as does Pascal, as does C, as does Java, ad infinitum), but it also had a compellingly great power: to allow the developer to encapsulate and organize code into separate modules that could be individually tested and debugged, then put on the shelf as part of an ever growing software "parts bin." From that bin, the developer could assemble final application packages of arbitrary functionality and complexity, similar to the way in which someone could assemble an electronic kit from a handful of integrated circuits and a few other components. Because all of the constituent parts would be pre-tested and pre-qualified, and their interfaces well-defined, final software would be more quickly realized, and would need less rigorous (read, "costly, time-consuming") testing before a sturdy, reliable product could go to market.
I programmed in Modula-2 for several years, myself, and found that it realized all of the aforementioned hopes, at least better than any other language of the day. As I alluded above with Pascal, however, that very strength might have been the language's downfall. Because it was so easy to put a solid product together with Modula-2, people rarely stopped with something solid. Instead, they decided to invest the time they saved using Modula-2 into creating ever-more baroque functionality, ever larger and uwieldy systems. Eventually, systems grew so large and complex, both for the user and the developers, that they collapsed under their own conceptual weight, despite the considerable ability of Modula-2 to mitigate the problems of over-ambitious design.
It is said, "a poor workman blames his tools," and boy, did Modula-2 take hits for disasters such as MicroPro Easy and a couple of others I can recall. Yet all the key concepts of Modula-2 eventually found their way into languages that later achieved some stature in the developer community: C++, Java, Delphi, and others. So, I don't think Modula-2's faults were as much in its design or implmentation, as in its marketing, and its misfortune to be associated with (and to ENABLE!) some of the more arrogantly ambitious projects of its day.
On the other hand, people who already thought in terms of component-based hardware development adopted Modula-2 as the vehicle for creating embedded software (automated factory control, microprocessors in cell-phones, microwave ovens, automotive control systems, etc.). They used the tool properly and got excellent results. You don't hear much about those success stories, because it is not a winning marketing strategy to hype the internals of a washing machine, a refrigerator, or a family sedan, beyond the gee-whiz aspect of mentioning that various systems are "intelligently controlled," I suppose.
One of the great qualities of both Pascal and Modula-2 that I most regret losing in the developer rush away from that family of languages, is the ability to pick up and readily understand code written months or years before, perhaps by other developers. Readbility of the program text was a value of the Pascal/Modula programming community. Features in the languages supported that value, assisting with the deciphering of even poorly written code. In contrast, it is a struggle to go back and makes sense of C or BASIC code that I once wrote, not to mention code written by others. This kind of difficulty raises the cost of maintenance and increases the pressure simply to scrap the existing code and create (at great expense) a completely new system. That process of churn is a large part of the explanation why 1) we still have horrendous levels of defects in modern software packages; 2)the industry has spent tens or hundreds of billions of dollars in the last three decades, without developing a viable market in software componentry -- too many developers continue to burn resources, re-inventing the wheel; 3) you need gigahertz processor speeds and gigabytes of RAM and hard-drive to get anything useful done. About this last, sad state of affairs, read on...
After Modula-2 fell to earth, creator Niklaus Wirth and colleagues went back to the drawing board and tweaked the language into a truly "object oriented" version (i.e., amenable to software development paradigms that were new and trendy at the time, and have since become established). He called the new language Oberon, in homage to the astonishingly lean, but capable and rock-solid software that had allowed space probes to reach the outer planets safely and send back impressive data. Wirth's motto was Einstein's old quote, "make it as simple as possible, but not simpler." So impressive was the result, that students at the Swiss Federal Tech Institute (ETH) were able to create a reliable, high-performance operating system and program development environment for modern computers, which nevertheless ran quite snappily on the old 386 computers with clock speeds of just a few hundred MHz, and RAM of just a couple of hundred megabytes or so. The entire assemblage -- operating system, graphic development environment, networking and web-browsing support, etc. -- fit comfortably on a single floppy disc. That's right, not a CD, a floppy disc. No sluggishness or bloatware there. That's not to say that the Oberon OS and tools would necessarily pass muster in these days of heightened security concerns or "total quality" initiatives, but I would say that the first versions of the Oberon system were probably as trustworthy and capable as the first linux systems, and as amenable to improvement along commercial and industrial lines as linux has proven to be.
You don't believe me? That's one of the great things about the web: You don't have to! Oberon is still a going concern at ETH in Switzerland. Just visit
the ETH Oberon website. You can download the Oberon system and play with it for free, and read more about the features and history of the system, to verify the Oberon-related assertions I have made here (and also to get another angle on the Pascal/Modula-2 story). Which is apparently more journalistic research than Mr. Dvorak ever did on this topic. His bottom 10 list is in the same league with the top- and bottom- 10 TV star/program lists that TV Guide publishes now and then, or the "Top 10 worst song" list that I believe was the object of a VH1 special recently. In other words: "infotainment"; unauthoritative fodder for conversation. And for the record, I happen to like the "Worst Song Ever," Starship's "We Built This City." I look forward to hearing it when the group plays at the Santa Cruz Boardwalk in a couple of weeks. That's always a good time, which is more than I can say for the majority of what passes for computer industry punditry.