From: newman@theory.TC.Cornell.EDU (Bill Newman)
Subject: Re: What is Object Oriented Programming? Is C doomed?
Organization: Cornell Theory Center
Date: Sat, 19 Dec 1992 19:01:10 GMT

In article <1992Dec17.185838.10564@rchland.ibm.com> lwloen@rchland.vnet.ibm.com writes:
>In article <id.KBWV.ZGK@ferranti.com>, peter@ferranti.com (peter da silva) writes:
>|> 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?

Numeric support isn't just an issue of squeezing out a few cycles.  In
principle (I think..), a C++ compiler should be able to produce numeric 
code just as efficiently as a FORTRAN compiler, and in most projects,
micro-efficiency isn't an issue.  However, FORTRAN has the support of
a large base of library routines:  LINPACK, EISPACK, 
NAG, and IMSL are the ones which come to mind, plus a zillion
specialized "dusty decks" containing routines to evaluate special-purpose
functions, lay out finite element meshes, select random numbers from
esoteric distributions, and so forth.  When you want to 
decompose a matrix into eigenvectors, or evaluate an Airy function, 
or integrate a differential equation, it's extremely useful to be 
able to call a standard routine to do it efficiently, accurately, 
and reliably, instead of having to re-implement the state of the 
algorithmic art in C or C++.

As far as I can tell, the C world still doesn't have the same depth
of math library support as the FORTRAN world.  (Maybe f2c will make
this difference irrelevant for C and C++ programmers?  I hope so.)

>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.

For problems where I'm free to choose my language, I choose from C, 
C++, or the higher-level specialized languages (Maple, awk, TeX, 
whatever) perhaps 90% of the time.  You don't need to convince me that
FORTRAN is an obsolete pig.  But for pure numeric programming,
existing FORTRAN code can be so valuable that FORTRAN is my
first choice.  (Especially if I can structure the project so that
I/O and data structures are simple throughout the FORTRAN
program.)

  Bill Newman
  newman@theory.tc.cornell.edu
Newsgroups: alt.amateur-comp,comp.lang.c,comp.lang.c++,comp.misc