From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.0 required=3.0 tests=BAYES_40 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 22 Jan 93 20:37:06 GMT From: seas.gwu.edu!mfeldman@uunet.uu.net (Michael Feldman) Subject: Re: Why and how do organizations select the OO Message-ID: <1993Jan22.203706.29355@seas.gwu.edu> List-Id: In article <1993Jan22.144817.23862@mcc.com> breland@cobweb.mcc.com writes: > >In conclusion, I must add that OO in the hands of the uneducated can be a >dangerous thing. It is not to be dictated just because "OO is the currently >accepted methodology, so do it." Instead, it must be applied judiciously >and in concert with other approaches suitable to the application domain. >Don't forget the domain encompasses project programmatics, as well as the >technology itself. > Two anecdotes about the faddishness of OO at the moment. (1) I was approached by a graduate student who wanted to write a masters thesis. I should add that this student works for a very large government contractor on a very large project, an Ada one as it happens (not that it matters!). The student had a proposal in hand: "prove that OO is less efficient". The following (abridged) dialog ensued: MBF: Less efficient than what? Student: Than traditional methodologies MBF: Less efficient in what sense? Student: Slower and bigger executables MBF: You think you can prove that? Student: Well, that's what the folks at work say MBF: But how do _they_ know? Have they tried comparing apples to apples? Student: I don't know, but I don't think so. They are interested in seeing my results. MBF: How about if we re-write your proposal so that you are _investigating_, for some appropriately boiled-down piece of your project, the run-time behavior of that program developed in OO fashion but also by a traditional methodology? Student: Oh, you want me to do the thing in two different ways, then compare? MBF: Yup. Student: Hmmm....that's a good idea. MBF: Yup. You might even be surprised by the outcome. The second draft is a bit closer to an honest assessment. (2) I had occasion recently to visit some folks in one of the military services, starting to develop a non-hard-realtime system. They are in a frenzy to sort out whether to use OO or not, and whether to use Ada or break their backs to get a waiver for C or C++. They hired a _really_ big-name consultant (NOT a professor, Mark!) to teach them his OO methodology and take a first crack at a design for them. After collecting a very large fee, he walked away from the project, leaving behind what they say is an unworkable design. Conceivably we (I and another professor friend) will get involved helping them sort it all out. Might be fun. In this group, the battle over both OO and Ada is purely religious. Seemed to me to be pretty devoid of technical content. And no, I won't tell you what group it was. I was there, though. And other friends have told me that this is typical of the state of things right now. OO is defined in these circles as "I don't know much about it, but it's that stuff that C++ does and Ada doesn't." And nobody can say for sure whether it will "work", whether it will improve cost-effectiveness, and by how much. Same old handwaving. Just thought I'd jump in with my $0.02. Mike Feldman PS - Read J-P Rosen's paper in the November CACM. ------------------------------------------------------------------------ Michael B. Feldman co-chair, SIGAda Education Committee Professor, Dept. of Electrical Engineering and Computer Science School of Engineering and Applied Science The George Washington University Washington, DC 20052 USA (202) 994-5253 (voice) (202) 994-5296 (fax) mfeldman@seas.gwu.edu (Internet) "Americans want the fruits of patience -- and they want them now." ------------------------------------------------------------------------