From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: piercarl@sabi.demon.co.uk (Piercarlo Grandi) Subject: Re: What is wrong with OO ? Date: 1996/12/08 Message-ID: X-Deja-AN: 203014290 x-nntp-posting-host: sabi.demon.co.uk x-disclaimer: Contents reflect my personal views only references: <32A4659D.347A@shef.ac.uk> <32a5ceba.81462731@news.nstn.ca> <32a7ae3c.11882739@news.nstn.ca> content-type: text/plain; charset=US-ASCII mime-version: 1.0 (generated by tm-edit 7.94) newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng Date: 1996-12-08T00:00:00+00:00 List-Id: >>> "tbushell" == Tom Bushell writes: tbushell> On 05 Dec 1996 22:30:40 +0000, pcg@aber.ac.uk (Piercarlo tbushell> Grandi) wrote: pcg> *If* analisys and design efforts were conducted in resonance with pcg> each other and implementation, then spending more effort on those pcg> than coding would be all fine and actually rather useful, tbushell> I agree that the effort is useful. But my gut feeling is that tbushell> with better (and apparently undiscovered, as yet) processes tbushell> and tools, the high level design activity should be about 10% tbushell> of the total project, not around 50%. Perhaps the reverse: if the tools were really advanced, perhaps including a program generator (and despite claims to the contrary no such thing has been yet produced), then high level design activity would be almost all the project. As things stand, human work on the ``lower'' levels of a project is indispensable, and communication problems between the humans doing the various levels of abstraction, if the total effort is divided in groups corresponding to such levels of abstraction, can cause embarassing problems, as Robert Martin has always observed. tbushell> Contrast this with doing the blueprints for a bridge - the tbushell> design effort is orders of magnitude cheaper than the tbushell> construction. (Or so I believe - a civil engineer might tbushell> correct me on this). pcg> It is usually _cheaper_, but on the other hand it might take pcg> _longer_. tbushell> I assume this is because the design is the work of a much tbushell> smaller team, whose only physical output is computer models or tbushell> paper. Not quite, because while _building_ the bridge is an almost-mechanical project, designing it requires a lot of hard thought, and consultation with users, and in particular lots of iterations and refinements. However designing a bridge and building it are not a good analogy for analysis/design and vs. coding; more like an analogy for all three of analisys/design/coding vs. execution. Naturally building a bridge from blueprints is not quite as mechanical as executing a program, for bridges are built by human teams using quite but not-so-precise blueprints. Still it has the characteristics of execution: an abstraction is turned into an instance (and potentially many instances, in the case of things other than bridges of course). tbushell> This is my point - other engineering disciplines appear to tbushell> routinely put much less total effort into design, with much tbushell> greater success. I guess this is just the positive result of tbushell> greater maturity as a discipline. Well, my impression is exactly the opposite: that the design of material entities like a new car or an airplane model requires immense amount of money and time, as compared to almost any software project, and as many iterations, and as much debugging, if not more, and then there are as many *design* bugs (as opposed to manufacturing defects) in the finished products. The saving grace is that cars and other physical systems like a building (but surely not airplanes) are usually, but not often simpler than doing software. Even in *cost* designing a new car or airplane can be a significantly large part of the cost of each instance of the design. I would even argue that the percentage of the sale price of instances that repays the development cost can be significantly higher for cars or airplanes than for software. Then while a large part of the sale price covers instantion costs for cars and airplanes, the instantiation costs of software are very small, and most of the sale price covers marketing expenses and profit; in this software is more like soft drinks and perfumes, physical products sold on their intangible value, than cars or airplanes. tbushell> Also, the OO design models I've studied don't seem to be very tbushell> good maps of actual real world systems - there seems to be a tbushell> big gap between high level architecture and running code. I This is a good reason why architectures as maps of real world system are not such a good idea. tbushell> believe there should be a fairly smooth continuim from high tbushell> level to low level of detail. piercarl> Why? tbushell> Why not? ;-) (Don't know what you're asking here...) I am asking for any argument to support the statements you make. You support your observations with reference to "my gut feeling", "Or so I believe", and "I believe there should be". This is all fine, but then you should provide some argument as to why your gut feelings or beliefs are; for they are about some points where plausibility can work either way, and it's hard to trust one's own instincts in such matter. pcg> But OO is in large part about this: the ``high level'' pcg> modules/classes/prototypes are supposed to capture the essence of pcg> the design. Pointing some sort of OO program browser to a program pcg> source and removing from the picture the lower levels of pcg> abstraction *ought* to reveal the design. This *ought* to be the pcg> case with structured programming methods in general, and with OO in pcg> particular it should be even more pleasant because of the pcg> disciplined modularization of the program it entails. tbushell> Absolutely! But why doesn't it work out that way? Because achieving this requires hard thinking. This is typically beyond the state of the art. Or perhaps because the rather vague statements by those who believe in ``silver bullets'', in particular those with ``real world modeling'' on them, mean that many people don't focus hard enough on the structure of programs _as such_; there is evidence as to what is a good structure for a model of the ``real world'', and then that this would also be a good structure for a program. There is instead some sparse but good evidence about what is a better structure for a program as such.