From: lwloen@rchland.vnet.ibm.com (Larry Loen)
Subject: Re: What is Object Oriented Programming? Is C doomed?
Date: Thu, 17 Dec 1992 18:58:38 GMT
Reply-To: lwloen@rchland.vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

In article <id.KBWV.ZGK@ferranti.com>, peter@ferranti.com (peter da silva) writes:
|> In article <1992Dec15.201954.10831@rchland.ibm.com> lwloen@rchland.vnet.ibm.com writes:
|> > I agree.  But, that's mostly a learning curve discussion, which is a one or
|> > two project cost.  Once mastered, it can't be a distraction any more than any
|> > other formerly new idea is.
|> 
|> I don't know... I've been involved with too many projects that ended up mired
|> in the mud to become convinced that the "silver bullet" problem will ever go
|> away. I'm still seing structured design being abused like that, and it's hardly
|> new. I don't know what it's going to take to break this cycle, but I don't
|> think object oriented *languages* are necessarily going to help.
|> 

I agree heartily that the 'silver bullet' problem (I assume you reference
Brooks' article in Datamation a while back) is not going away.  In fact, I
often think it is just a higher level manifestation of the halting problem.
But, that's a far cry from saying one's tool set has no economic effect.  It
seems to me you still aren't convinced even about structured programming.  But,
I've been around long enough to remember what we did before it and I have
generally experienced _greater_ failures without it than with it.  If you're
looking for s.p. or o.o. to "clear the chessboard" of problems, of course you
are going to be disappointed.  By that level, I am, too.  The question is, does
OO (or, structured programming) _on average_ make programs cheaper to produce,
with no/an acceptable run time performance penalty over current practices?  Even
a five or ten percent improvement (hard to notice unless you measure carefully)
will have an enormous influence over time.  And, that's ignoring maintenance,
which is eating a lot of shops alive.  S.P., on balance, is a big help, there.
OO will be, too, though we have some things to learn, first.  Like, how to
document them properly.  But, that will come. 

|> You compare object oriented languages and structured languages, and consider
|> both practical necessities. I disagree in both cases. They're highly
|> desirable, but in the face of external requirements (like, you don't have
|> a structured language available with good numeric support, so you use
|> Fortran) I wouldn't hesitate to abandon either.
|> --

For "practical necessities" substitute "economic necessities".  The fastest
running program is not always the "best" program in my experience.  Performance
is never forgotten, but I hear and read a lot more complaints about how slow
program development is, not how slow programs are nowadays.  Even a couple of
percent difference in development time will beat the competition, long term.

We can argue if the improvement is real, yet, but the idea that whatever affect
it has can be lightly set aside seems rather unlikely to pass a businessman's
muster, once the issue is understood.

Fortunately, one is seldom left with these kind of either/or choices nowadays.
I have no opinion on C++/C for heavy floating point, but I rather doubt it is
all that much behind good ol' FORTRAN (which I left behind in 1974).  Even if
it is, I would rather write the bulk of the logic in a modern language and do
the number crunching in FORTRAN subroutines that I managed to link into, even
if I had to put in an assembler stub or two in to make it happen.  I'll bet that
even in your hypothetical case, I can hold the FORTRAN to 20% of the total code,
with little or no performance penalty.  In some cases, it probably makes net
economic sense to take the performance hit and simply code it up in a modern
language anyway, even with mediocre floating point, and have done with it.  If
OO really works, I'll bet one or both approaches tend to outperform a straight
"get all the cycles you can" FORTRAN approach in terms of total satisfaction to 
the user.  There's always another program they need written, right?

The key issue is:  Do structured programming and object orientation make good
design easier to express?  Does it lead to more programs being able to be
written with fewer bugs?  Can it allow programs to be maintained more easily?
For structured programming, the answer is long in; for OO I suppose it still
can be questioned, but I am ready to bet on it.  I agree it is not a silver
bullet, but one doesn't always have to hit a home run to win a baseball game.
Collect enough singles and doubles along the way and you can still win.

The argument for OO is not an either/or, black/white kind of argument.  It is
a "what method gets me done with the work" faster argument were "work" is
writing or maintaining code.
 
|> Peter da Silva                                            `-_-'
|> Ferranti International Controls Corporation                'U` 
|> Sugar Land, TX  77487-5012 USA
|> +1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

-- 
   Larry W. Loen        |  My Opinions are decidedly my own, so please
                        |  do not attribute them to my employer
Newsgroups: alt.amateur-comp,comp.lang.c,comp.lang.c++,comp.misc