Re: What is wrong with OO ?

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

"Matt Telles" <matttelles@sprynet.com> writes:

 > Bjarne Stroustrup <bs@research.att.com> wrote in article 
 > > 
 > > 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
 > 
 > I certainly agree with this statement.
 > 
 > > 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).
 > 
 > I am curious. Does this imply that you think people should learn another
 > language before C++? Or is it simply that C++ is taught without the proper
 > emphasis on techniques. In my experience, the language is taught
 > syntactically, with little regard for the OO behind it. 

I don't really mind, you can learn C++ as a first language - and use it
as a vehicle for learning sound concepts, principles, and techniques
- or learn it later. I have seen both paths work well - and I have seen
both fail. I have a natural bias for "C++ first" especially for people
who aims at becoming professional software developers, but I am strongly
of the opinion that every programmer should be comfortable in more than
one language.

I do object to the "toy approach" to teaching programming: Give people
a tool that is great for writing little demos, let them produce a few
of those without hitting any hard conceptual barriers, any efficiency
problems, and any limitations of the tool/language. Then let them go
on to something else - such as "high-level design" or management.

That is the way to produce non-programmers with unrealistic estimates
of their own ability and a total lack of understanding of the problems
faced by people who produce production code.

The "the language is taught syntactically, with little regard for
the OO behind it" is exactly what I'm arguing against - as I have
done consistently over the years.


 > > 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.
 > 
 > True. Isn't it important then to emphasize the aspects of the language
 > which make it 
 > a) Maintainable and
 > b) Reusable?

I think I do.


 > > 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.
 > 
 > Agreed. But where else to begin? If you are teaching C++, they say, learn
 > to write a linked list class, learn to write a string class. I annoyed one
 > of my professors long ago by handing in a linked list class that said
 > simply "refer to chapter xxx in the text". After all, wasn't reuse the
 > point we were trying to stress? How would you teach C++ without emphasizing
 > the low-level functions?


Here is one way:

Initially, you supply people with a good set of basic classes: vector,
list, map, string, iostreams, simple graphics. Nothing too fancy or
daunting. Based on that, you teach the basics of writing small programs
using variables, constants, loops, functions. Then teach how to write
simple classes - such as dates and strings. Then teach how to add classes
to a class hierarchy and how to build a class hierarchy.

Templates are first simply used where needed, and defining new ones is done
wherever the examples need parameterization. The initial set of classes
provides a good set of examples for "dissecting" to understand class design
and implementation. During that "dissection" you introduce the lower-level
facilities as needed to explain the implementation.


 > > 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.
 > 
 > This is really less of an issue that the "Object Oriented Programming can
 > save the company" bandwagon, in my estimation.
 > 
 > >  > 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). 
 > 
 > My question is: Does the tool matter? Or is it simply an extension of the
 > concepts behind it. I can write object-oriented code in FORTRAN. It is
 > harder, but it can be done. The amount of work doesn't necessarily make it
 > less possible.

Tools matter. Languages matter. If I didn't think I was seeing evidence of
significant improvements I would have stopped working on C++ years ago.

A good language helps solve some of our problems building good systems,
but it is only part of a solution. This is one reason that there has been
much more good software written in languages deemed bad than in languages
proclaimed great. Often people who focus on language issues are blindsided
by the non-language issues.


 > > 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.
 > 
 > Tell that to COBOL programmers. Or Pascal, or any of the other languages
 > that I have learned at one point or another in my life.

Actually, I have. I have taught C++ to people with COBOL and Pascal
backgrounds (it is easier to those with Pascal background - on average
as easy as to teach it to people with a C background though the problems
faced by Pascal and C programmers tend to differ in interesting ways).

However, it is important to remember the difference between learning
enough to write a student exercise and enough to write a piece of code
to be used by others. I tend to be strongly focussed on the latter -
and sometimes underestimate the importance of the former.


 > The amount of
 > effort to learn the language becomes secondary when the boss tells you to
 > learn it. Why use the Microsoft compiler over the Borland compiler? Because
 > the company standardizes on it...

In an ideal world, people would choose their own languages and their own
tools. I have had the priviledge to deal primarily with people who did
have a choice. There are more of those than is sometimes claimed. Often,
the problem is not lack of choice but that the choice is conditioned by
what others are doing (or what others are perceived to be doing or what
other people are perceived to soon be doing ...).

To be useful, a piece of software has to fit into a very complicated mesh
of real-world concerns - of which the choice of programming langauge is
typically not the most important.


 > > 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 have a problem here, but it is not with C++. There are certainly flaws in
 > the language. No serious programmer would argue that there are languages
 > which are flawless. The problem is that C++ lets me shoot myself in the
 > foot. In some cases, it aids in loading the gun and aiming it for me. The
 > issue is not the language, but the poor programming practices which
 > encourage it. Why, for example, allow the continued use of void pointers
 > when they lead to nothing but pain and agony in the long run (this is an
 > example, I understand why they were necessary).

As you point out, they are unavoidable so how could I ban them without
saying "go and use C whenever you need to do low-level stuff?" I do not
believe in making a language prettier by making it incomplete and leaving
programmers to write significant parts of their code in a language with
no support for abstraction.


 > Why let me use
 > uninitialized pointers? Do you have any idea how many programs I have
 > debugged for hours because someone failed to write something as basic as:
 > 
 > char *p = NULL;

If I had designed C++ today, every variable that did not have a default
constructor would have to be initialized. When I wrote the first C++
compiler, I had it issue a warning whenever you tried to use an uninitialized
variable. However, I could not ban uninitialized variables without getting
into an unwinnable fight with the C community. I have been quite annoyed
that the quality of warnings against legal but almost certainly wrong
constructs have on average declined. I can hope that they will improve
again now we (almost) have a standard but there is typically no way of
forcing people to do what they really don't want to do.

See "The Design and Evolution of C++" for a discussion of such issues.


 > > 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
 > 
 > I certainly won't argue with someone who created the language. My point is
 > simply that until we solve the problem of programmers believing they are
 > artists, rather than engineers, we will never have quality software.

Maybe, more programmers believe that they are artists than actually are,
and more programmers believe they are engineers than actually are.

I suspect that I'll take the artist and the engineer any time I can find
them, but the real issue is than many aren't even craftsmen yet. We are
seeing progress, but we have a long way to go. In my opiion, education
has to be major part of any solution. This may sound obvious, but there
seems to be no shortage of people in industry who would prefer to reduce
software production to a semi-skilled activity - in which case we would
have to reduce the amount of education and replace most current programmers
with people with less education and more training in following rules.

	- Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html