Path: utzoo!utgpu!attcan!uunet!husc6!cmcl2!rutgers!att!ihwpt!ihnp4!poseidon!ech
From: ech@poseidon.UUCP (Edward C Horvath)
Newsgroups: comp.lang.c++
Subject: Re: Can we hide the private part of a class ?
Message-ID: <528@poseidon.UUCP>
Date: 4 Oct 88 17:25:26 GMT
References: <1358@stratus> <1988Sep29.044111.16104@utzoo.uucp>
Reply-To: ech@poseidon.UUCP (XMRJ50000-Edward C Horvath;LZ 3F-315;3005)
Organization: AT&T Bell Laboratories, Lincroft, NJ
Lines: 51

Henry Spencer observes:
> Remember, C++ is aimed primarily at the C community, which has a long
> tradition of caring A LOT about efficiency.  There are many, many people
> who are willing to adopt C++ only because they can be fairly sure that
> they aren't losing significant efficiency by doing so.  C++, like C,
> specializes in being fast rather than pretty.

Deja vu.  In the mid-70s, Berk Tague (the first manager of the
Bell Labs Unix Support Group) said that he didn't really believe that
the choice of language was important.  However, C was the only language
he had found that would woo the diehards away from assembler.

I suppose I'm a diehard, too.  I suspect that stems from 20 years of
hearing the same argument that "the next generation of hardware will let
{LISP, SNOBOL, shell scripts, smalltalk, your language here} run fast
enough to obviate the efficiency issues."  And 20 years of seeing the
demands placed on the programs increase as fast as the hardware power.
And 20 years of seeing the efficiency freaks eat up the market share.
So I still code the innermost loops in assembler.

The reality is that each new level of abstraction in the programming
process has to prove itself ECONOMICALLY.  I hear the arguments about how
much more efficient object-oriented programming is, in terms of reuse of
code and better maintainability.  But if there's an efficiency penalty,
it's going to cost me market share EARLY, and maintainability is moot to
a company that's folded.  When a 5- or 10 year old software product team
reports the continuing evolutionary quality of their product, and the
reduced maintenance costs, without an efficiency penalty, everybody will
jump on the bandwagon (or already be beyond it).  But end-users just
can't see the internal cleanliness, although they've become better about
demanding timely updates and fast response to bug reports.

Bjarne Stroustroup clearly recognizes these issues.  The C++ book
apologizes, and properly so, for the "unclean" aspects of the language.
His apologia, however, almost invariably involve allowing the compiler
to do a better job of generating code.  The result is a compromise,
enlightened by the SmallTalk experience, but tempered by a recognition
of the reality "real" programmers face.  I'm switching to C++ just as
soon as I have a compiler for my Mac (maybe even when there's a
preprocessor, we'll see), because it looks like it will help me more
than it will cost me.  I'm not switching to SmallTalk, it just isn't
fast enough for production-quality applications.

Ultimately, I do believe that we'll program in an evolutionary fashion
that exploits the strengths of what-has-gone-before.  I have not been
persuaded that we know enough to construct that ultimate programming
environment.

But I've started reading about Eiffel...

=Ned Horvath=