psrc@mtunq.ATT.COM (Paul S. R. Chisholm) (07/09/90)
(I'm going to start by reacting to Brad Cox, and then talking about structured design and other software design efforts. I may ramble a bit, and scare some people off, so let me start off by quoting someone who knows, by his own admission, not one darned thing about computers, and who still manages to summarize my quest better than I can.) "Genrty was convinced that cyberspace had a Shape, an overall total form. Not that that was the weirdest idea Slick had ever run across, but Genry had this obsessive conviction that the Shape mattered *totally*. The apprehension of the Shape was Gentry's grail." --William Gibson, MONA LISA OVERDRIVE, 1988 chapter 10, "The Shape" In article <5337@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: > But I absolutely do not agree that software's complexity has to be > greater than that of hardware. Admittedly, it certainly is today, > but isn't that precisely because we still invent and implement > everything from first principles, rather than by relying on and > supporting a marketplace in interchangeable software components? Dr. Cox suggests (here and elsewhere) that we need a paradigm shift, from software *design* to software *construction*. (Dr. Cox, if I'm wrong, please don't hesitate to correct me, by posting or personal e-mail [but note that I've moved slightly].) Personally, I think that having a base of less primitive "primitives" would be nice; and, as Dr. Meyer does, I'd like to never implement a linked list or a table look-up again for as long as I live. But I don't like Dr. Cox's analogy of electrical components (at various scales); that is, I don't think it applies to the problems he, or Dr. Meyer, or Dr. Stroustrup, hope to solve. The design of electronic (hardware) systems works because there are standard components at *all* scales, and customer components at a greater variety of scales can be created and integrated. Dr. Cox's efforts with Objective-C are aimed at supporting the creation (and dissemination) of software components at a higher level that C or C++. He may be successful, and that would be nice; but it's still a single scale. Let me change the analogy, from electronic components to Lego(R) brand childrens' building components. Everything can be built from one and two "peg" blocks. Dr. Cox would like to introduce standard door and window blocks. That would be a wonderful time saver, in a lot of cases; but it doesn't help me when I try to think, "What am I building?" (Duplo blocks are bigger, but don't help, unless I happen to need big blocks.) When I design a Lego construction, I don't think about components of any scale. (That's exactly what I do when I'm playing around, trying to see what I come up with; but that analogy to most software development breaks down fast.) I come up with an overall *shape*, a high-level design that, in the long run, affects how I assemble the pieces; but that is *not* affected by the shapes of the components I happen to have. Architects and engineers (the real ones who design houses and bridges and stuff) do the same thing. They may factor strength-of-materials rules of thumb into their highest level designs, and do the appropriate calculations later; they *don't* think about two-by-fours, I-beams, and concrete forms when they say, "I think I'll put the hallway *here*." (Their customer specifications are also vastly simpler than ours.) Software designers have nothing like that at all; software has no shape. The best thing we have is structured design. (If you haven't read Yourdon and Constantine's book on the subject, log off and pick up a copy; parts of that book are invaluable.) Even so, structured design is a handful of rules of thumb, and a notation based on code structure that breaks down quickly as programs get non-trivial. (Their main contribution is as an intermediary form for going from the data flow diagrams of structured analysis to code; if you don't use data flow diagrams, structure charts aren't likely to be very useful. I'd *love* to have someone argue this point with me.) In software, we have super detailed blueprints that show every stud, every wire, every pipe, and most of the nails; we have nothing similar to an artist's sketch for design. Object-oriented design isn't a solution. It's a very helpful philosophy, and I like what comes out of it. But it can't compare with top down design in terms of being an algorithm for developing software; to do OOD, you think about the problem until you understand it all, and then you implement it from the design in your head. Thanks loads. I've been thinking hard on this subject for over a decade, and haven't come up with anything much. If someone asks me to deliver a software design to them, and I *had* one, I don't even know what I'd hand over. > Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 > The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482 Paul S. R. Chisholm, AT&T Bell Laboratories att!mtunq!psrc, psrc@mtunq.att.com, AT&T Mail !psrchisholm I'm not speaking for the company, I'm just speaking my mind. Lego is a registered trademark of somebody in Northern Europe.
jacob@gore.com (Jacob Gore) (07/09/90)
/ comp.object / psrc@mtunq.ATT.COM (Paul S. R. Chisholm) / Jul 8, 1990 / > ... [object-oriented design] can't compare with > top down design in terms of being an algorithm for developing software; > to do OOD, you think about the problem until you understand it all, and > then you implement it from the design in your head. OOD does not rule out top-down design. The difference is that in functional decomposition, you are decomposing actions, and in top-down OOD, you're decomposing actors. Jacob -- Jacob Gore Jacob@Gore.Com boulder!gore!jacob
jcg@iris.brown.edu (James Grandy) (07/10/90)
In article <1174@mtunq.ATT.COM> psrc@mtunq.ATT.COM (Paul S. R. Chisholm) writes: > In article <5337@stpstn.UUCP> cox@stpstn.UUCP (Brad Cox) writes: > > But I absolutely do not agree that software's complexity has to be > > greater than that of hardware. Admittedly, it certainly is today, > > but isn't that precisely because we still invent and implement > > everything from first principles, rather than by relying on and > > supporting a marketplace in interchangeable software components? > > Dr. Cox suggests (here and elsewhere) that we need a paradigm shift, > from software *design* to software *construction*. (Dr. Cox, if I'm > wrong, please don't hesitate to correct me, by posting or personal > e-mail [but note that I've moved slightly].) Personally, I think that > having a base of less primitive "primitives" would be nice; and, as Dr. > Meyer does, I'd like to never implement a linked list or a table > look-up again for as long as I live. > > But I don't like Dr. Cox's analogy of electrical components (at various > scales); that is, I don't think it applies to the problems he, or Dr. Meyer, > or Dr. Stroustrup, hope to solve. The design of electronic (hardware) > systems works because there are standard components at *all* scales, > and customer components at a greater variety of scales can be created > and integrated. Dr. Cox's efforts with Objective-C are aimed at > supporting the creation (and dissemination) of software components at a > higher level that C or C++. He may be successful, and that would be > nice; but it's still a single scale. I couldnt agree more, but I would go further and say that the Software-IC analogy is inappropriate for a large part of what OO design is good for: designing generic structures that are intended for more than just reuse, but also extension. Most really useful OO systems are designed to be reused in a dynamic way. The best example is an application framework, which may export functionality, but which also exports a generic structural definition which is meant to help the designer frame her own problem. An application framework includes generic classes corresponding to the common elements of all applications, but more than that it defines communication protocols and constraints between those elements. Reusing this structure involves more than plugging in a component and connecting it to other components, it means extending a generic structural definition to fit a particular need. I cannot think of a good analogy for this process; but still the Software-IC analogy rings hollow to me. James Grandy (401) 862-1610 jcg@iris.brown.edu IRIS Brown University Box 1946, Providence, RI 02912