Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!uflorida!beach.cis.ufl.edu!tws From: tws@beach.cis.ufl.edu (Thomas Sarver) Newsgroups: comp.society.futures Subject: Re: what to do with all those MIPS Message-ID: <15368@uflorida.cis.ufl.EDU> Date: 5 May 88 02:05:59 GMT References: <3bbda74b.44e6@apollo.uucp| Sender: news@uflorida.cis.ufl.EDU Reply-To: tws@beach.cis.ufl.edu (Thomas Sarver) Organization: UF CIS Department Lines: 106 Keywords: Software, Engineering, Software Engineering, MIPS, Hardware, Software Summary: Sofware is, again, the bottleneck. In article <3bbda74b.44e6@apollo.uucp> nelson_p@apollo.uucp writes: | | One point that has been made on this topic is that we | are not just technology-bound in getting more use out | of computers. We are so far behind using even the | *existing* technology that if hardware development were | to be frozen at its current level, major improvements | in the use and productivity of computers and related | technology would continue for years and perhaps decades. [He talks about a flexible encyclopedia access program with comments about how best to do so over 1200 baud phone lines.] | There is no technological reason why this could not be done | today over existing phone lines or with existing PC-class | computers. The limitations are primarily lack of standards, | lack of software, and lack of having the data organized appropri- | ately for easy retrieval and cross-referencing. | | I'm not saying that overcoming lack of standards or agreeing on | how we want things to work is *easy*. All I'm saying is that, | until we do, a lot of neat technology will be very under-utilized. | | --Peter Nelson | The main problem is not standards. Although that is a valid problem, the real problem is the software bottleneck. Since the advent of the computer, there has been what I call the hardware/software cycle. First, there was a problem that people thought the computer could solve. However, the current hardware was insufficient for the task. So the hardware was upgraded/updated. The software was written for the task and everyone was happy. Then someone came up with another task that the current hardware couldn't properly handle, and the cycle started over again. However, now we have reached a point where building new hardware is a matter of waiting for demand. Designing new hardware is simply filling out a list of features w/ some tradoffs (excepting peripherals like CD-ROM, laser printers, etc.; they are another story). It's not quite as easy as this but once one is done, it is done. Whatever flaws exist are because someone didn't ask for the right features. Software is the bottleneck. What a designer asks for is not necessarily what the product will become. Software engineering is still more an art than a science. The cost associated with building the software is dwarfed by the huge cost of maintaining it. Fixing bugs and making the program do what the user _Really_ wanted in the first place is the bulk of the expense in the software industry. Imagine a Apple Co. coming to each Apple owner's house and doing the latest fix to his Apple ][+ . Once Apple puts another model out the door, that's it, finito, the only things left are 1) hardware add-ons, (probably already thoughtout) and 2) *SOFTWARE SUPPORT*! The hardware/software cycle has broken down because software can no longer keep up with hardware development. One route that IBM took was compatibility between hardware updates. Software that took a year and a half to develop runs on hardware that came out yesterday. Look at any microcomputer and you'll see that it took about three years for software packages to take full advantage of the hardware. Meanwhile, a new model could come out every year (case in point: Atari, 1982-1985). Compatibility is one way to lessen the effects of the hardware/software disparity. Another is modularity. In most microcomputers, graphics are built in to the system. IBM was the first to decide to make graphics a different card. This allowed one to upgrade their graphics without buying a new machine. It also enabled them, because the newer cards were compatible with the old, to run their old software on the new cards or buy new software that took advantage of the new card. ***TURN ON FANCIFUL/FUTURE-LOOKING MODE*** I predict that software will become modular. Object-oriented programming is the craze today in the software industry. It will revolutionize program development the way that structured programming did more than a decade ago. With a new graphics board, one would receive a new object definition. Today it is called a hardware driver, but in the future its use will be unlimited. Imagine having a relational database that does simple queries. Then imagine being able to add SQL (a gee-whiz-bang query language). A good example of a crude attempt at what I am suggesting is the Lotus 1-2-3 add-ons. Some add new macro commands; some add pull-down menus and mouse support. It really is a matter of time before developers start committing their livelihoods to object oriented design/implementation. ***TURN OFF FANCIFUL/FUTURE-LOOKING MODE*** BTW, I a working for the Software Engineering Research Center, and we are looking at some ways to minimize the bottleneck. One might say we are trying to get the machine to do more for us much like hardware designers did for their field. For more discussion about the possibilities for object-oriented languages see: Bertrand Meyer, "Reusability: The Case for Object-Oriented Design," in IEEE Software, March 1987, p. 50-64. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ But hey, its the best country in the world! Thomas W. Sarver "The complexity of a system is proportional to the factorial of its atoms. One can only hope to minimize the complexity of the micro-system in which one finds oneself." -TWS Addendum: "... or migrate to a less complex micro-system."