Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!att!cbnews!cbnewsm!lfd From: lfd@cbnewsm.att.com (Lee Derbenwick) Newsgroups: comp.software-eng Subject: Re: Reusability considered harmful??(!!) Summary: Complex hardware components are programmable. Complex software components must be, too. Keywords: Reusability, Division of Labor Message-ID: <1991Feb11.225546.15269@cbnewsm.att.com> Date: 11 Feb 91 22:55:46 GMT References: <6108@stpstn.UUCP> <4842@cui.unige.ch> <318@smds.UUCP> <27B2EADB.5840@tct.uucp> Organization: AT&T Bell Laboratories Lines: 57 In article <27B2EADB.5840@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: > According to sw@smds.UUCP (Stephen E. Witham): > >Someday soon we'll have "component software" (as distinct from software > >components) by analogy to component stereo ... > > That's already here -- cf. UNIX tools. The question is, will _all_ > programming eventually be cookbook work? Only when all problems are > cookbook, i.e. never. Exactly. Component stereo does a very limited set of activities, with a very simple interface. As a result, you can just plug them in and they work. The UNIX tools (filters, anyway) have a similarly simple interface: a stream of ASCII characters with newlines every so often. They just plug together, too. But I think a lot of people advocating "chip-level" and "board-level" software components haven't been paying attention to what really happens in hardware. The simplest components (quad nand gates, etc.) just plug together, but they are so simple as to be the equivalent of assembler language. More complex devices used to be tied together with lots of these "glue" chips -- sort of the equivalent of writing a C program using a subroutine library that does some of what you want, but not all, and with incompatible data structures that require conversion. But hardware has been moving much closer to taking general-purpose, complex chips and just plugging them together, with relatively little glue logic. The key to this is that general-purpose, complex chips are now usually programmable. Microprocessors are obviously programmable. But many I/O devices are now general-purpose, with a bus interface over which they take commands that will configure them into the desired behavior. And programmable gate arrays have taken over much of the function of random logic; you either specify the programming and the manufacturer builds you 10,000 of them with your program built in, or you buy a user-programmable one and burn your program into it. What does this mean for software components? If we want reasonably- sized, plug-in components, they are going to have to be made more general, then "programmed" or configured in some fashion either before or after plugging them in. Database systems are an example of this; so are the Unix tools, which are general-purpose and become specialized to use in a specific pipeline by command-line options. The arguments over exactly what the semantics and implementation of a stack should be might be subsumed by a "list application generator" that gives the user their choice of stack, queue, and dequeue implementations for a limited range of specifications (e.g., error-checking in the application vs. in the stack itself; fixed-maximum-size vs. dynamically allocated, etc.). In that scenario, you wouldn't buy a _stack_ from the Reusable Software Shop; you'd buy a _stack builder_. -- Speaking strictly for myself, -- Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ -- lfd@cbnewsm.ATT.COM or !att!cbnewsm!lfd