goldfain@osiris.cso.uiuc.edu (03/31/89)
] Written 7:09 am Mar 28, 1989 by woolstar@cit-vax.Caltech.Edu ] One of the side effects of all these bigger and faster computers ] are that more options and effects are being added, and this is good ] but it also allows less efficient and sloppier code. Given, that ] all applications don't need to be written in assembly any more, ] but there are quite a few programs that I have looked through, ] that are incredibly sloppy. Another effect is that layer upon layer of shells, languages, and environments are beginning to grow. This contributes to inefficiencies as well.
bzs@BU-CS.BU.EDU (04/01/89)
Judging software quality by sheer size is mindless. It's the same confusion between quantity and quality that let Maxwell House sell coffee because it had a "cup and a half of flavor", what *did* that mean? The early pressures were obvious, by today's standards machines were unbelievably tiny. A minicomputer with 10-15 people time-sharing had a maximum logical address space of 64KB, perhaps 1 or 2MB of physical space, and that would be a fairly big machine. I was quite pleased for years with our machine which had 28KB of physical memory, no virtual. Small systems were prized. Unix was hailed as the ultimate small is beautiful system. It *was* an incredibly tiny kernel, but it wasn't a small system. Other systems gave you a few built-in system commands (DIR, DELETE, etc.) and an editor, assembler, linker-loader, librarian, FORTRAN and perhaps a BASIC and a call library. Unix came with much more, flip thru a V6 manual some time, it's still far richer in useful software than micros today (right out of the box that is.) Unix offered fortran, C, as, troff, compiler-compilers, sort, file comparators, file management and a powerful, general purpose tree-structured directory, etc etc etc. Most of it did fit on a 2.5MB hard disk (right, two-and-one-half, RK05), full sources used another one of those, but the functionality was big. Pipes let you run multiple address spaces in one task. Small was beautiful not because small has magical properties, but because it represented reduced complexity, modularity, MAINTAINABILITY. And that's the real point, big software tends to be buggy! And impossible to modify and maintain if you do get the sources because it's impossible for one person to grasp. Small systems like Unix made heros out of individuals (the "Unix Guru"), big systems like MVS made heros out of teams, organizational efforts, management coups. So big is not the problem, at best it may be symptomatic of a problem, big for big's sake, organizational behavior merely trying to justify its existence rather than accomplishing anything of use. But there has to be a better way to judge software than merely asking how many bytes it consumes. -Barry Shein, Software Tool & Die There's nothing more terrifying to hardware vendors than satisfied customers.