Re: What is wrong with OO ?

["Matt Telles" <matttelles@sprynet.com>]

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

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

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

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

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

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

Matt Telles