jer@peora.UUCP (J. Eric Roskos) (12/09/85)
In a debate about upward-compatibility, the following assertions have been made: >> Thus, Joe Insurance Co. hasn't had to change its software for the last 15 >> years. CPU upgrades are a joke [easy to make in an environment that >> provides upward compatibility]. At Waterloo recently ... [IBM proved this >> by a software-transparent CPU upgrade]. Someone else replied: > The point about Joe Insurance Co. is not a particularly valid one. I > suspect that most software written 8, 10 or 15 years has long since > outlived its usefulness. ... I don't think maintaining the bridge between > applications on microprocessor driven systems is as important as it once > was (any may still be) with mainframes. Applications software simply > changes too fast. [See note at end regarding selection of newsgroup.] The reasoning in the paragraph marked by the single ">" represents a significant flaw in the current philosophy of microcomputer software design. Microcomputer software has started to stagnate, I suspect, and I suspect might even begin somewhat to die out, because so far the only applications being produced are the "easy to write, but interesting" applications like the word processor, spreadsheet, and **simple** database. Already we see companies differentiating themselves not by particularly new functionality, but rather by how well-integrated their products are. (Microsoft seems to be an exception; their most recent applications seem to incorporate new functionality.) And, already, if you look on the cover of the November 11th InfoWorld, for example, you can see some of the companies dying out as a result of this. If the microcomputer is going to make the jump to fill the role of the mainframe (which most people seem to want it to do), then it is necessary that it be able to perform more traditional processing. [Alternately, they could be used only for "new" things, and I'm not saying that new things are not needed; not at all.] I don't think the machines will sell voluminously in the long run until they can be made to perform "heavy duty" data processing. And probably this will require significant work, and heterogenous networks of processors of differing capabilities. I definitely think this can be done, but it's not easy. One of the things that has to be done to head in this direction, though, is to realize that not all applications are spreadsheets and word processors. Most applications are not even theoretically interesting (except for concepts like atomic actions, etc.). They are just plain programs. And once Joe Insurance Co. writes them, he may want to use them for as long as Sam Smith, Account Manager, is in charge of the data processing dept... which in a traditional, stable company (unlike software companies with their high turnover) may be for the entirety of Sam's life. About 10 years ago, when I was a student working in Data Processing, I worked with companies that had accounting machines made with discrete transistors hand-soldered onto bus bars, because the company was afraid to buy a "real" computer because of the overhead involved in converting! And no wonder; their business was construction, not accounting. Upward compatibility is one of the hardest things to do in machine and software architecture. It gets maligned a lot among people developing the new generation of machines, and to some extent that's good, because it's time a lot of new ideas got incorporated into the machines; but you can't go to the other extreme and throw out the upward compatibility issue either. Look at Apple... one of the reasons the Macintosh has had so much trouble in the business world is that they didn't have the machine out for 6 months before they started changing it. [A number of people will probably think the above is an argument for making microcomputers just like mainframes, making them do trivial data processing tasks. It's not at all. Rather, I am saying that whereas people seem to always want simple answers and simple solutions, ultimately you have to do a lot of hard work to make a useful system, and such solutions are not usually the sort you'd find in the "best of all possible worlds;" and the upward compatibility issue is an example of this.] -------- The above is entirely the author's opinion (the result of working in many different environments and different roles), and does not necessarily reflect the opinion of Concurrent. Note: I have posted this to net.arch and net.micro. I tend to feel that net.micro is concerned more with concrete issues like "when will 1-2-3 come out for the TRS-80", and am reluctant to discuss abstractions there. Most of the systems people read net.arch, and many, I suspect, don't include net.micro. It really should go in net.systems, or something of that sort, but with all the difficulty of creating net.os... Please edit your followup Newsgroups: line, if you followup, to go to an appropriate newsgroup. -- UUCP: Ofc: jer@peora.UUCP Home: jer@jerpc.CCC.UUCP CCC DNS: peora, pesnta US Mail: MS 795; CONCURRENT Computer Corp. SDC; (A Perkin-Elmer Company) 2486 Sand Lake Road, Orlando, FL 32809-7642