guthery@acw.com (Scott Guthery) (02/04/90)
In a recent posting, Dan Weinreb argues essentially that since
controlled experiments to test validity of the claims made for
object-oriented would be so expensive these claims must be taken to
be true until contrary evidence is presented. When presented with
such evidence ... the CAD/CAM disaster at MCC, for example ...
Weinreb argues out of the other side of his mouth that since the
experiment wasn't controlled no inferences can be drawn from it.
I'm not sure where the alternative reality is in which the all the
claims for object-oriented programming are true but I am sure that
neither I nor any of the programmers I know live or work there. My
first and second hand experience over the last five years is that
when applied without discipline object-oriented techniques yield
gratuitious complexity and full employment for programmers and little
else. The kicker is that no one seems be willing or able to describe
the discipline that must be applied to make it otherwise.
IMHO it's time that software development methodology was based on
solid empiricism rather than the chant-of-the-day. Failed fads
are becoming a noticable litter on the programming landscape.
Cheers, Scott
+*+*+*+*+*+*+*+*+*+*+*+*+ Austin Code Works +*+*+*+*+*+*+*+*+*+*+*+*+*+*+**+*+
NET Domain: guthery%acw.uucp@uunet.uu.net Post: 11100 Leafwood Lane
COM Domain: guthery@acw.com Austin, Texas 78750-3464 USA
US Domain: guthery@acw.austin.tx.us FAX: +1 (512) 258-1342
Usenet: {uunet}!acw!guthery Voice: +1 (512) 258-0785
Work: guthery@asc.slb.com TELEX: 446370 (austincodewrks)
Packet: N5MDE @ KB5PM EasyLink: 62752994
Fidonet: 1:382/12 Prodigy: KSWS89A
CompuServe: 70240,221 BIX: sguthery
+*+*+*+*+*+*+*+*+*+*+*+*+* The Source of C +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (02/06/90)
In article <31.UUL1.3#913@acw.com> guthery@acw.com (Scott Guthery) writes: >be true until contrary evidence is presented. When presented with >such evidence ... the CAD/CAM disaster at MCC, for example ... My impression from various reports has been that the MCC CAD/CAM incident was a case of unacceptable performance (caused by such things as a homegrown, untuned OOP system and a homegrown, untuned OODB) and unacceptable politics (caused by the use of Common Lisp and Symbolics workstations instead of the politically powerful C++ and Suns). I do not recall any disparagement of the CAD/CAM system's functionality or the programmers' productivity. I would certainly welcome a more complete, preferably firsthand, account of the event and its circumstances. Lawrence G. Mayka AT&T Bell Laboratories lgm@ihlpf.att.com Standard disclaimer.
rfg@ics.uci.edu (Ronald Guilmette) (02/10/90)
In article <13335@cbnewsc.ATT.COM> lgm@cbnewsc.ATT.COM (lawrence.g.mayka,ihp,) writes: >In article <31.UUL1.3#913@acw.com> guthery@acw.com (Scott Guthery) writes: >>be true until contrary evidence is presented. When presented with >>such evidence ... the CAD/CAM disaster at MCC, for example ... > >My impression from various reports has been that the MCC CAD/CAM >incident was a case of unacceptable performance (caused by such >things as a homegrown, untuned OOP system and a homegrown, untuned >OODB) and unacceptable politics (caused by the use of Common Lisp >and Symbolics workstations instead of the politically powerful C++ >and Suns). I do not recall any disparagement of the CAD/CAM >system's functionality or the programmers' productivity. I would >certainly welcome a more complete, preferably firsthand, account >of the event and its circumstances. I can say (second hand) that while I was at MCC (Jan-June '89) I was told by people who should know that (a) Lisp was part of the problem, and (b) the *whole* problem was that somebody in MCC management told the shareholders "Please don't bug us. We're doing great things and we will deliver a groovy thing to you someday soon". When the delivery day came (so the story was told) the Shareholders looked at the groovy thing delivered and said (in effect) "That's great. But it's not what we wanted, needed or expected." Part of the reason that it was not what they wanted was that the code was in Lisp, but there were other reasons also. Anyway, that is the way the story was told to me. The moral was that it was everybody's fault (including the shareholders) because there was a lack of communication during development. What would you expect? Cooperative research is not something that most companies know how to make work for them yet. P.S. I don't think that C++ was yet "politically powerful" at the time of that project. It is amazing how much difference a year or two can make. Disclaimer: I am just repeating a story told to me. I have no firsthand knowledge of these events, so if somebody says that I'm full of s*** and that I don't know what I'm talking about, they are probably right. // rfg
sof3@ztivax.UUCP (Walter Meyer) (05/31/90)
In article <31.UUL1.3#913@acw.com>, guthery@acw.com (Scott Guthery) writes: > In a recent posting, Dan Weinreb argues essentially that since > controlled experiments to test validity of the claims made for > object-oriented would be so expensive these claims must be taken to > be true until contrary evidence is presented. When presented with > such evidence ... the CAD/CAM disaster at MCC, for example ... Being an OOD enthusiast who reads comp.object for the first time, I am interested in more detailled information about such "disasters": - What kind of problems did they want to solve by OOP ? - Any explanations, excuses ... besides " We used the wrong methodology " ? Oliver Rothe sof3@ztivax.siemens.com