Re: What is wrong with OO ?

[bs@research.att.com (Bjarne Stroustrup)]

Bart Samwel <bsamwel@wi.leidenuniv.nl> writes:

 > 
 > Bjarne Stroustrup wrote:
 > 
 > > Only where I couldn't find a solution that fitted in C++'s general
 > > framework and met my criteria for run-time efficiency, ease of
 > > implementation, ease of teaching, etc. (see D&E Chapter 4), did I
 > > feel compelled to try to invent something.
 > 
 > When I read this, a lot of questions pop up in my head. I'll ask only
 > one: You've only included features that didn't compromise ease of
 > teaching (at least, that's my interpretation of what you wrote). Why is
 > it then, that C++ contains so many hidden 'features' (or rather,
 > non-explicit rules) that confuse people, at least at my university?

In addition to giving an answer to you ``only one'' question, I will
comment on some of the pretty strong statement you made afterwards -
lest silence should be taken for agreement, lack of counter arguments,
or arrogance.

I'm not sure which hidden_features/non-explicit_rules you are referring
to, but I do have some experience with the teaching, learning, and use
of C++ that might be relevant.


First, here is the way I phrased the "learning" criteria in "The Design
and Evolution of C++":

	If in doubt, pick the variant of a feature that is easiest to teach

	This is a secondary rule for choosing between alternatives.
	It is tricky to apply because it can be an argument for logical
	beauty and also for sticking to the familiar. Writing tutorials
	and reference manual descriptions to see how easy they are for
	people to understand is a practical application of this rule.
	One intent is to ease the task for educators and support personnel.
	It is important to remember that programmers are not stupid;
	simplicity mustn't be achieved at the expense of important
	functionality.

It is one of about twenty such rules of thumb I rely on.


C++ is a language primarily aimed at creating production software. Like
all such languages, it together with its associated libraries, tools, and
programming techniques is too large to learn quickly (unless you happen
to be experienced in rather similar languages and techniques - and most
students and programmers are not when they first encounter C++).
Consequently, it must be learned in stages starting with some suitable
subset (and a suitable subset of tools, libraries, programming techniques).

Many are too ambitious and try to learn too much too fast. In particular,
many programmers focus on learning every obscure language detail rather
than overall principles because mastery of programming language details
is what has traditionally been valued in many programming communities.
That way, people get lost in details.

That, together with the common mistake of chosing "all of C" as the
initial subset of C++ to learn have led many into trouble. These problems
are avoidable. In particular, only a relatively small part of the common
C and C++ subset needs to be understood before one can approach the
abstraction mechanisms that are the essential part of C++.

Traditionally, C++ has been blessed with a mass of useful libraries, and
cursed by the absence of a good standard library. The lack of a standard
library supplying basic types (such as string, list, and map) reinforced
the bias of some teachers and some teaching materials towards low-level
features and techniques that don't rely on standard library facilities.

C++ now has a nice standard library and most implementation now are shipped
with a reasonable approximation to it. However, the effects of its initial
absence (primarily my fault) still lingers in teaching methods and teaching
materials.

C++ caught on very fast. This led to people "joining the bandwagon"
without actually understanding what the important ideas were. Many times,
I have cringed seeing what riduculous statements were made about C++
and its proper use. For example, an early textbook proudly gave an
airplane derived from an engine as its first example of object-oriented
programming. Naturally, that author had never written a real C++ program
in his life or a real program in any other programming language supporting
object-oriented programming. Fortunately, he later jumped on another
bandwagon and is now pushing some other OO language.

I have no idea if any of this apply at your university, but I have seen
all of those phenomena repeatedly. Usually, people manage in the end, and
if not they try something else - which they may or may not find more
suitable.

I provide more details about learning and teaching C++ in "The Design
and Evolution of C++" (D&E) and on my homepages. C++ can be - and often
is - taught effectively to people of a wide variety of backgrounds and
with widely varying needs.


 > As far as I'm concerned, C++ is not a language for teaching. It has too
 > many of these implicit rules to be logical, and the fact that it
 > doesn't have garbage collection and does have pointers really makes it
 > error-prone; especially for beginning programmers, this is not a good
 > thing. They should be writing WHAT should be done, and ALL that should
 > be done; they shouldn't be bothered with the 'how' part of programming,
 > like (with alternatives): memory management (garbage collection),
 > pointers (references), virtual functions (can be detected by the
 > compiler). They should not be bothered with implicit rules (like the
 > multiple inheritance rules, for instance) that they have to know of,
 > before using multiple inheritance.
 > 
 > C++ is an excellent language as an extension to C, but C is altogether
 > obsolete and much too low-level, except for systems programming, and
 > other languages are now available for writing high-level software.
 > Many people make the (IMO huge) mistake of using C++ for high-level
 > software projects, leading to buggy results and, often, lots of core
 > dumps. Programmers are not perfect, and C++ expects them to be so by
 > providing too many ways of making mistakes.

I'm not sure about what you call a "high-level software project" but
C++ has been applied successfully often enough for your description
of the results of using C++ to be a carricature. There has been failures
involving every programming language that has ever been used for
production code. Since there has been more use of C++ than for any
other comparable language, I would expect there to have been more
with C++. However, I use C++ software daily that doesn't dump. There
are many C++ programs out there that works correctly month in and month
out. Reliability and mainatainability can be eased by a programming
language (such as C++) but is the result of a more comprehensive
process.

C++ is a programming language, so it doesn't have expectations, but I
- as its designer - never suffered from the delution that programmers
were anywhere near perfect. Nor did I suffer from the delusion that
I knew enough to put restrictions in place to constrain every programmer
without exception or escape.


 > Languages like Eiffel (my personal favorite) are much more suitable for
 > high-level projects; Eiffel, for instance, does not burden the
 > programmer more than needed, and has a clean, clear syntax that can
 > even be immediately understood by people that don't know the language.

I do not personally find it so, and such claims reminds me unpleasently
of the similar claims made for COBOL. A non-programmer can sometimes be
convinced that he/she can read simple code, but it is far from obvious
that this is relevant - or ever true - for production code (that will only
be seen by programmers anyway). 


 > > Much of C++'s success has to do with fitting into existing
 > > environments and being compact and fast (yes, I know that these are
 > > not the aspects of C++ that are currently emphasized in the
 > > MS Windows world). The speed and compactness of code generated from
 > > C++ depends on a few fundamental design decisions that I think were
 > > novel at the time:
 > 
 > Speed and compactness is certainly a goal that C++ has achieved. But it
 > did not achieve one major goal: ease of use.

I wonder how you would measure ``ease of use'' objectively. For starters:
``ease of doing what kind of work?'' ``ease for whom?'' C++ isn't the
easiest programming language to learn and to use, but for a rather large
range of systems, a large range of applications, and a large range of
developer communities, it seems to be the easiest language out of those
that can actually help get the work done.

Had C++ not been relatively easy to learn and use reasonably well, it
would have disappeared long ago. By relative I mean the amount of effort
needed compared to the amount of benefit gained.


 > >         C++ offers inline member and non-member functions with zero
 > >         overhead compared to macros.
 > 
 > You shouldn't bother programmers with inlining. Inlining can be done
 > automatically by the compiler.

Not really. Some compilers can do some inlining well, but for larger
programs the compiler is hampered by having incomplete information
and by not having a particularly good idea of what optimizations are
relevant in various part of the code. Explicit inlining is a pretty
good way of giving programmers some control for the common cases where
a compiler isn't smart enough without tying users up with proprietary
and non-standard control features. Used well, inlining can make a major
difference in speed and code compactness.


 > >         C++ offers its form of dynamic (run-time) resolution, virtual
 > >         functions, with low and fixed overhead compared to ordinary
 > >         function calls (20% to 100% dependent of implementation).
 > 
 > Virtual functions must be explicitly specified. This can be done by the
 > compiler. And, virtual functions must be specified in the ancestor
 > class; this means that when a class designer forgot to put that in
 > (and this happens often), I can't redefine the function correctly.

Deciding which member functions should be virtual is a design decision,
not an optimization. If a designer has provided a poor base class, you
will typically have problems beyond what can be fixed by overriding.


 > > Over the years, C++ has evolved within a framework that was reasonably
 > > well understood early on.
 > 
 > Well understood, yes. But the framework is now obsolete, and it has
 > some serious design flaws that also bother C++ users.

Certainly there are flaws - I don't know of a language that doesn't have
flaws, and I consider the idea of a widely-used flawless language nonsense.

Once a language is used by diverse user communities, one person's serious
flaw becomes another's essential feature. Some of the aspects of C++ that
I dislike most are deemed essential by very competent system builders.
However, C++ has no flaw and no feature lacking that is so serious that
it cannot be managed with reasonable effort in a project - even if they
can be a bother and experienced programmers recognize them as such.

I do not consider C++ or its basic conceptual framework obsolete nor
do I know an alternative that could replace it in the next few years.
Like it or not, programming languages have lifecycles that span decades,
and "obsolete" often means little more than "not in accordance with the
latest fad." For most builders of real-world software a ten-year-old
language is a newborn. ``OO'' itself is more than 25 years old and we
are still learning about it - even those of us who have been part of the
process through most of those years.

The world is a whole lot messier than we would like it to be, and some of
that messiness is reflected in every successful programming language.

Good luck with your projects and the language you favor, and remember
that the world is more complicated that any of us can imagine and that
there are ways of succeeding that we would not personally have chosen.

	- Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html
	
 
 >    Bart Samwel  (bsamwel@wi.leidenuniv.nl)
 > 
 >