Path: utzoo!attcan!uunet!husc6!mailrus!ames!elroy!jpl-devvax!beowulf!david
From: david@beowulf.JPL.NASA.GOV (David Smyth)
Newsgroups: comp.lang.c++
Subject: Efficiency of OOPLs
Message-ID: <3514@jpl-devvax.JPL.NASA.GOV>
Date: 14 Nov 88 14:58:25 GMT
References: <8335@nlm-mcs.arpa> <6590068@hplsla.HP.COM>
Sender: news@jpl-devvax.JPL.NASA.GOV
Reply-To: david@beowulf.JPL.NASA.GOV (David Smyth)
Organization: Jet Propulsion Laboratory, Pasadena, CA.
Lines: 49

In article <6590068@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes:
>
>And among object oriented languages, only C++ seems to have the
>runtime efficiencies to make it viable for most commercially 
>developed code.

I hear this over and over.  And it just is NOT true.  Sit down at a
LISP workstation, and do som ewindowing stuff.  Sit down at a SUN, a Mac,
something running Smalltalk, Mesa, or what have you, and you will find
comparable performance.  The problems we are solving today are MUCH larger
than the problems we used to solve, when compiler efficiency mattered
so much.  Now, it is the efficiency of the human to language communication,
NOT the language to machine communication.

There is no way that a half million lines of code is going to be programmed
as intelligently as 22000 lines of code (approximate UNIX + Window system
+ compilers + tools + debuggers + editors + mailers + ... .vs. Smalltalk).

In C++, one spends too damn much time writing garbage collectors, 
making sure constructors are being called when they should be, ...
Things which have NOTHING to do with really solving the problem.
Think how painful your C code would be if you had to set up and
destroy the stack every time.  Barf.  And think how hard it would
be to really make your stuff run fast.

>Part of this difference comes from the C++ implied claim that there
>is not just one best way of doing these tasks -- that in more
>critical cases programmers are going to have to make informed
>choices as to what memory management schemes to use, ...

You probably remember one of the reasons why so many of us "real
programmers" were unwilling to use any HLL about 10 years ago: you
had to use the stack so much.  If you hand coded your routines, used
macros instead of subroutines, ...

What happend then was that the assembler coded systems were micro-optimized,
macro-stupid.  The same thing is and will happen with C and C++ when
used instead of a REAL object oriented language.
>
>Certainly, anyone who intends to become shall we say "professional"
>at writing Object Oriented code is going to have to become
>proficient in a lot of "new" issues that don't come up as often
>in C code writing -- memory management schemes, garbage collection
>schemes, multiple inheritance, container schemes, try/recover
>schemes, constructors, destructors.

Why?  Right now, people don't have to become proficient in serial port
programming, device drivers, schedulers, etc., even though we all use
them over and over, all day long.