Jeff Taylor | August 20, 2004
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.
Help Reason celebrate its next 40 years. Donate Now!
Try Reason's award-winning print edition today! Your first issue is FREE if you are not completely satisfied.
Where does the H&R comment software fit on this list.
I keeed, I keeed.
Do they have a list of great software that failed for lack of
interest. I always like the Amiga OS, too bad it didn't do
better.
OS/2? Yeah, great OS, assuming you never wanted to print
anything, and wanted to buy whole new programs (that didn't exist)
to do the things you used to do before you dropped $400 on the new
OS.
Seriously, OS/2 was a disaster from day one, and I speak as a
person with 40-odd OS/2 installation floppies.
The only company that managed (barely) to sell a new OS that was
completely incompatible with its previous OS was Apple, and they
went from a 20% market share to a 4% market share.
Some of the early versions of WordPerfect had a good feature that I sometimes used, which was you could crash the computer at will with a three or four command macro that would use the 'flip screen' command, which was their early way of being able to keep two documents loaded at once. I used that feature a few times for unscheduled coffee breaks -- creash the computer, call up tech, gee man I don't know what it did, it just crashed...
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.
I can't recall the last time Dvorak turned out to be correct on
anything. Certainly more than a decade. This article demonstrates
his ability to grind an old ax rather than make useful
observations. Pretty much everything here is so dated that much of
the readership will lack the direct experience to contradict
it.
The fact is that Wirth's languages failed to catch on primarily
because they weren't championed within the companies that mattered.
If Microsoft had done a Visual Oberon it would have been
huge.
Bob was very overambitious for the hardware of the era but that
isn't why it failed. The biggest strike against Bob, a product
intended to make novices more comfortable, was that the non-novices
reviewing software didn't like it because it added a set of
training wheels after they'd made the effort to master the system.
Some of the same people thought the Mac GUI was a blight upon
effective use of computing resources. Never mind usability for
those who didn't care to pass the initiation into the club.
The funny thing is that many of the elements of Bob have become
commonplace and widely accepted.
Patrick says "I hear BeOS mentioned very often in that context
[great software that failed for lack of interest], but I never got
to try it out myself."
I did, while Be was still a separate company. It may interest you
to know that, even as late as 1997, movers-and-shakers inside the
Apple sphere were conducting investigations and straw polls, trying
to decide whether Apple should purchase Next or the BeOS, as their
foundation for what later became OSX. When my turn came to vote, I
went with BeOS. Unfortunately for me, when Apple went with Next, I
ended up on the outs with them. Fortunately for me, Apple didn't
purchase the assets, because later Palm did, for a relative song. I
had Handspring stock at the time, which later became Palm stock.
After a few sickening dips, that investment ended up doing fairly
well for me, speaking as a small-time dabbler.
I'm still looking forward to seeing the legacy of BeOS kick some
marketplace tail in PalmSource OS editions.
It is indeed funny how some technologies that are obviously
superior just don't make it in the marketplace. We end up having to
wait many years until those features make their way in to future
products -- if they appear at all.
I worked with OS/2 at home at at work for a couple of years. It was
a wonderful thing to work with -- especially considering that
alternatives at the time. Even the old 16-bit versions of OS/2 were
wonderful. In 1989 as a test we had a 10mhz 286 with 6MB of RAM
connected to a LAN, also connected to 3 modems
uploading/downloading at the same time, and with other applications
in memory. It ran without a hiccup.
We had to wait over a decade for that capability from Microsoft on
much faster computers. (I'm not an MS basher. I work exclusively
with MS products now after working mostly with *NIX for 13 painful
years.)
Modula-2 was another one of those technolgies. The computer science
department taught using Modula-2 when I was in school. No other
language was available to teach the programming concepts.
After college I had to use a number of more primitive languages. I
had to wait over a decade again before something as nice came about
in Java and C#. But beautiful syntax of Wirth's languages lost out
to the more macho and less readable C-style.
Even nice debuggers that I used in college didn't make it on to my
desktop until 1.5 decades after graduation.
Do they have a list of great software that failed for lack
of interest.
I hear BeOS mentioned very often in that context, but I never got
to try it out myself.
[from the article]
"The database manager [Microsoft Access] fared better, but
eventually languished as SQL-centric products became the
standard."
Huh? This passage made me think the author had idea what he was
talking about. Access still seems quite popular to me. And it most
certainly is "SQL-centric". Perhaps he meant to say "SQL
Server-centric"?
Site comments/questions:
Media Inquiries and Reprint Permissions:
(310) 367-6109
Editorial & Production Offices:
3415 S. Sepulveda Blvd.
Suite 400
Los Angeles, CA 90034
(310) 391-2245