Re: C++: The COBOL of the 90s
Subject: Re: C++: The COBOL of the 90s (Reply to RM)
From: IJ
Date: 1995/04/09
RM writes:
>MK writes:
>
>>HELP, HELP, HELP
>
>>An excerpt from the UNIX-HATER'S HANDBOOK ( reprinted in ADVANCED SYSTEMS,
>>November 1994 )is being circulated around to my company. It is feeding the
>>anti-C++ fires that already exist within management. The article bashes
>>C++ with the various arguments like:
>> NO AUTOMATIC GARBAGE COLLECTION
>> HARD TO LEARN
>> LOOSE SYNTAX CHECKING
>>
>>and others.
>
>>I need amunition to help fight for a language that I believe is well
>>suited for my needs as an embedded systems engineer. ( it gives me high
>>level constructs along with low level control )
Note C++ might well be suitable in your scenario. However, my arguments
against C++ is because it is as not generally applicable as its
proponents make out. Bjarne Stroustrup the languages inventor has
stated many aims for C++. However, I think the one stated in his "The
Design and Evolution of C++" (D&E of C++) on page 1 is worth noting,
"C++ was designed to provide Simula's facilities for program
organization together with C's efficiency and flexibility for systems
programming." This quite eloquently and excellently puts C++ in its
place. If you are doing systems level programming in C, then C++ will
naturally be one of the options on your list. However, C++ is not the
only choice for effective systems level programming. It is not
universally applicable in all systems environments, as C is not
universally applicable. The industry must understand that C++ is a
good extension to C where C is applicable, but it has very severe
problems beyond that, particularly in applications environments (which
is 80% of the market, and systems level programming is becoming a
smaller percentage all the time), and in systems environments where C is
in fact counter to efficient programming.
C and C++ are mainly suited to low level programming in the Unix and DOS
environments, based on Intel and Dec style architectures. If your
systems environment, or hardware deviates from this narrow mold, C
quickly loses its advantages. For example, if you are doing systems
programming on a Unisys A Series, you program in ALGOL (or its OS
extension NEWP). These machines have exclusively used high level
languages for systems programming since the early 60s. An assembler
would undermine the environment, and not provide any advantage over the
code generated by the ALGOL and other compilers. Because C is more
oriented to the assembler level, C has no advantage in this environment,
and in fact as far as performance goes is a liability, as you have to
emulate a flat systems environment provided by Dec and Intel style
architectures, and expected by Unix and DOS systems. Aside from Unisys
A Series, C will unfairly penalise other advanced environments, and
might even stall advance in the areas of architectures and operating
systems. This bodes badly for true open systems.
Furthermore, even in environments where C is applicable, C is losing
its advantage as a systems programming language. C will probably
continue to be used to implement those small areas where low level
interfaces are needed, but only as an external to other languages. It
will probably also continue to be used as an intermediate machine
language for the implementation of other languages. C++ will also
continue in those roles. However, as a tool for program organization,
C++ is considerably outclassed by its rivals.
Having said that, C and C++ still have their areas of applicability, and
you can obviously take your chances with the flaws and the traps to gain
efficiency in those areas of applicability. However, the advantages are
quickly evaporating, and C++ is not as widely applicable as the
proponents would make out. It is this attitude that C and C++ are more
widely applicable than their obvious domain that shows what a religious
following C and C++ have.
My recommendation is to seriously consider the alternatives of Smalltalk
and Eiffel (and others such as Ada, Oberon, Sather, etc).
>
> Why C++
>
> Robert C. Martin
> Object Mentor Associates
> rmartin@oma.com
> 708.918.1004
>
> 4 Apr 1995
>
>
>
> Abstract
>
>
> C++ is a language that seems to stimulate a tremendous
> amount of debate and religious furor. This paper
> attempts to cut through this "nonsense" and make a case
> for why C++ is a reasonable language for developing
> object oriented applications.
I would look at it this way. C++ is a controversial language. There
has been much legitimate criticism of C++. My criticism is based on the
point that OO is supposed to be a solution to complexity. It should
leave behind those techniques that have been shown to be problematic,
and bring a modern perspective to software development. Unfortunately,
C++ brings all of the baggage of the old world right into OO
programming. This is the cause of the controversy. The controversy is
not nonsensical. There has been an amount of religious furor, but I
would say that the religion has mainly been on the part of the
apologists for the language. (And I think by the end of this post,
you will have an insight into why this is.)
My abstract is that programming languages must support the economical
production of quality software. It is against this yardstick that I
find C++ is problematical, and not as applicable in as many domains as
it is promoted in.
>Introduction.
>
>Why is there so much controversy about C++? Probably because it has
>enjoyed so much success.
This is in part true. If it had remained a backwater language, and
remained within its legitimate area of application, there would
naturally be less public controversy. In view of what I say above, it
is quite understandable that the success of C++ beyond its natural area
of applicability attracts a lot of controversy. It is not applicable in
many areas, and it is these areas that become controversial, as C++
continues to be promoted in these areas. It is difficult to explain to
C people that C and C++ have problems when used beyond their bounds.
There needs to be more attention paid to the alternatives, particularly
by those who set themselves up as OO consultants. But it is probably
not as profitable to promote alternatives, since the C++ market is now
quite large.
> It is easy to believe that if C++ had remained
>a backwater language, the voices of its detractors would not be so loud.
>However, C++ *has* succeeded in a huge segment of the industry, and the
>proponents of other languages are quite vocal in bemoaning this fact.
Now don't just characterise C++'s detractors as proponents of other
languages with axes to grind. OO was making good progress in improving
the task of software construction. Other languages were naturally
developed to support OO. However, then came along C++, which on one
hand promoted the idea of OO, but on the other hand stunted OO, perhaps
crippling it incurably. Coupled with the fact that many proponents of
C++ promote it as the 'one language does everything' approach, so you
don't need to consider anything else, and with the attitude that 'C++ is
for the experts, and professionals, the others are just toys or teaching
tools, or are just trying to prove a point without actually doing
anything useful' means that there is a great deal of heated debate, when
those you are arguing with fervently believe those faulty axioms.
>But what are they really complaining about? Ian Joyner, one of the most
>vocal and prolific C++ detractors, has published and widely distributed
>his notorious "C++?? A Critique of C++, Second Edition" (write to
>ian@ssyacus.acus.os.au for a copy).
Thanks for the recommendation Robert. Firstly, however, the critique is
not 'notorious', just well known, and if I might modestly say,
reasonably well received and regarded. Secondly, here is a small
correction to the address:
ian@syacus.acus.oz.au
I certainly think that people should be aware of the issues surrounding
C++, before adopting it as a solution to programming problems. A good
look at the alternatives to C++ is recommended. I have recently read
another excellent appraisal of C++ vs Eiffel by Richard Wiener in
chapter 7 of his book "Software Development using Eiffel: There can be
life other than C++" (Prentice Hall). This is a very balanced and even
handed look at both the languages C++ and Eiffel, and I highly recommend
it.
Although Bjarne Stroustrup says on page 5 of D&E of C++ "Language
comparisons are rarely meaningful and even less often fair", I
believe that this is an interesting and fruitful endeavour. I
deliberately did not compare C++ to other languages in my critique,
but appraised it on its own deficiencies. One could speculate that
Bjarne feels this way, as C++ usually fares the worse.
There are two erroneous views of those who criticise C++. The first is
that C++'s critics are cranks and religious nuts, who have little
understanding of technical reality. This is not the case. Some of the
detractors of C++ are the most respected voices in OOP and the industry.
People like Bertrand Meyer (who puts his money where his mouth is by
providing a practical alternative to C++), Richard Wiener, and Markku
Sakkinen. Then there are people like myself, who criticise C++ from a
practical point of view because we have to do the programming.
The second erroneous view is promoted by Bjarne Stroustrup. On p177
of D&E of C++ he says, "Some C++ sales men will undoubtedly embarrass
the C++ community by emulating some of the sleazy tricks and unscrupulous
practices that salesmen and admen have used to attempt to derail C++'s
progress." This too is nonsense. The criticism of C++ has certainly
not come from salesmen and admen. Indeed, I have been contacted by
people promoting other environments to ask permission to pass my
critique onto their prospects. But this is part of making people
aware with what they are dealing with. Helping people become aware
of and assess the issues is certainly not unscrupulous. In fact the
typical response of 'merketeers' is the reverse. They see that C++
is big, and there is money to be made, so they resent that I should
hinder their progress at making money by 'trifling' technical arguments
that they cannot understand.
It was also this attitude of Bjarne's in a net posting years ago, that
convinced me that I should complete and publish the list of problems
that I was finding with C++. In it he was flaming someone who had dared
to question C++, and said that criticism only came from commercial
sleezeballs. I also wanted to end the ridiculous religious wars that
were waged on the net with a paper that stated the negative case
clearly. I don't know that many in the industry have indeed yet matured
to the point that they realise that a language is just a tool, and
worthy of appraisal. In fact very recently on the net Bjarne accused me
of 'hawking' my critique again. The critique has never been 'hawked',
it has always been freely and openly distributed.
The view that the detractors of C++ are just religious cranks, or
marketing sleezeballs is just a figment of paranoid imaginations.
> This is a generally well written
>(although in my opinion misguided) paper, and I recommend it to anyone
>considering C++ as a language. In this paper Ian says: "...the C
>base is C++'s greatest weakness." And this is a common thread through
>many of the arguments against C++. They say that C++ is a bad language
>because C was a bad language.
Well, I guess this is where we will continue to (I hope amicably)
disagree. I criticise C++ being based on C, because it brings all of
the bad old things straight into the OO world. It is a significant
'corruption' of OO. However, not all detractors of C++ see C as a bad
language. I can accept it in its place for low level programming on a
certain class of systems environments (Unix and DOS for example). But
there are others who support C, and the C base for OO languages who
criticise C++. For example P.J. Plauger in his "Programming Language
Guessing Games: If C++ is the answer, what's the question?" (Dr Dobb's
Journal, October 1993). Other variants of OO languages based on C
continue to be invented. For example Objective C, and the very
controversial C+@. The C world itself is very divided on the efficacy
of C++.
Bjarne Stroustrup in D&E of C++ gives reasonable justifications for
using C as a base: flexibility, efficiency (low level), availability,
portability (with a qualification). C is however losing its advantage
in these areas, due to the increasing availability of efficient
compilers for other languages. But Stroustrup also points out many
areas in which C is deficient. In some cases these deficiencies have
been rectified, or alleviated. But in many cases, the deficiencies have
been carried forward. As he says on D&E of C++, p48 "Dealing with
stubborn old-time C users, would-be C experts, and genuine C/C++
compatibility issues has been one of the most difficult and frustrating
aspects of developing C++. It still is."
>I don't think that C needs a defense. The last several decades have
>proven it to be an extremely flexible and productive language, suitable
>for building applications of nearly every kind.
You don't need to defend C, but you must know and admit its
shortcomings, as Stroustrup does. In fact the characterisation of C
being a powerful language is a characteristic that can be applied to
most programming languages. All programming languages have much the
same power. What the difference is is how easy it is to write different
styles of applications, and how the language supports the project
process as a whole. In fact you can build any application in assembler
or even machine language. But the point is that we need better tools
than those oriented towards low levels such as assembler and C for
modern software development. C is oriented towards the machine domain.
Other OO languages are oriented towards the problem domain. C++ also
makes progress towards that goal, but is compromised by its
low-levelness. The common counter argument is that you need low level
facilities to obtain acceptable performance. However, this argument is
erroneous. Compiler and optimiser technology provide you with more than
acceptable performance. (However, this is one legitimate way of
classifying languages, but it does not dismiss clean and 'pure'
languages as necessarily being inefficient.)
In fact building in low level details can work against efficiency, in
that if you port or migrate to a different environment you might find
all your assumptions are turned upside down. This is why compiler
technology is important, as to turn your program into a reasonably
efficient program, just rerun it through the compiler to retarget it to
the new environment. (Of course you could just have an interpreter for
the source language. That will be slow, and that is why we have
compilers.) This helps protect you against 'vendor lock-in', which is
now becoming a very real problem with certain large companies who want
to dominate the computer industry. Furthermore, optimisers have a much
better chance of working given a clean language.
> However, in the early days
>of C, there were many detractors who decried the ugliness of the language
>and promoted "pure" languages like Pascal. The current debate regarding
>C++ and other languages such as Eiffel, Obj-C and Smalltalk seems similar.
No. There are lessons to be learnt from Pascal. There are some great
implementations of Pascal. However, most Pascal compilers were
developed at Universities for teaching. These compilers found syntax
errors really fast, but produced awful code. Why not, it was never
going to be production code. (Perhaps I have been fortunate enough to
only used good implementations of Pascal. First Carroll Morgan's
excellent Cyber compiler at Sydney University, the Macintosh MPW Pascal
(Object Pascal), then A Series Pascal83 (slice compiler).)
Then I believe Wirth made the mistake of moving from Pascal to Modula-2
to Oberon. He left his loyal base behind, without much of a way of
moving forward. This is one clever thing about C++, and I hope all
other language vendors learn a lesson from it. C++ does not leave the C
people behind. They have a way of moving forward, and for this reason
C++ enjoys success. Not for any technical nicety of the language
itself. Languages such as Eiffel and Smalltalk cannot be compared with
Pascal because of those practical reasons. I don't think Eiffel and
Smalltalk developers will be left in the lurch. You cannot just expect
comparisons between Smalltalk and Eiffel, and Pascal to carry much
weight, or just to draw the comparison because they are all considered
'pure'. There are other reasons why Pascal has declined in prominance.
>Why did C succeed? Because it cut through all the crap.
What 'crap'? I don't see that the economic production of quality
software, and the techniques to support that aim are 'crap'. This is
the fictitious argument that the C community has been using against
other cleaner languages for 20 years. The fiction promoted is that
designers of other languages have a narrow, high minded and lofty
view of the world not based in reality, and that they intend to
imprison the lowly programmer with these ideals. Unfortunately,
this reasoning has had a very strong influence on those learning
programming for the first time, and has damaged a whole generation
of programmers into believing that C is the only true way. This
has established a very strong 'religious' following of C. This is
the nonsense that the detractors of C/C++ are so vocal about, and
often become the targets of unreasoned attacks about.
It seems that this widely held belief has come from a quote by Dennis
Ritchie, "Some languages are designed to solve a problem; others are
designed to prove a point." This remark and its subsequent adoption into
the beliefs of many needs to be explored. There have been languages
developed as research languages, which explore one or more concepts, but
are not meant for general purpose use. Perhaps these languages are
designed to prove a point. But this is what research is about.
Furthermore, the advancement of the software industry and research is
well and truly intertwined. All other languages are meant for
programming. They might just support one or another paradigm, and the
classifications of many programming paradigms is well known. Others are
meant as general purpose programming languages. In fact 10 years ago I
used to hear C people talk about what a lousy language Simula was, the
very language that inspired C++. Obviously Simula was just trying to
'prove' some 'point'. THe fact was they just didn't understand Simula.
So this belief (and deeply held suspicion) of the C community needs to
be dispelled as it is just an excuse to write off other programming
languages that are not in the C fold, without thought, understanding or
reason. (Again this is part of the reason why the defense of C is
religious in nature, as it is based on such simple minded creeds about
why the others must be considered wrong.)
> Instead of
>fighting for "purity", the authors of C created a language that could be
>*used*. They never contended that it was perfect or pure, certainly it is
>not. They wanted a simple, moderately low level language that they and
>other people could use. In that goal, they succeeded.
And those who were fighting for 'purity' were deliberately creating
languages that would trip up and obstruct programmers? I think not.
However, there are many things in C and C++ that really do trip up
and obstruct the path to completing software under budget, and of
good quality.
There is also the purity that the above Ritchie creed promotes in the
C world. That is that a language is only good if it is C based, and
that the others can just be written of as 'proving a point.'
>Why has C++ succeeded? For the same reason. It cuts through all the
>nonsense.
Again, what nonsense? C++ introduces a whole lot of nonsense. Just read
the C++ ARM about all the areas that are undefined (or produces
undefined results, in other words, nonsense). This is not acceptable in
a modern language standard. Sure if you know what to avoid, C++ is a
useable language. Such warnings do not remove the fact that the
nonsense is there. Then again, C programmers used to complain that
Pascal got in the way because of its typing, and extended this to the
thought that all typing was the work of the purists trying to prove a
point. (I'm not going to defend Pascal's implementation of typing).
However, perhaps the proof of efficacy of typing is that C++ adopts a
strongly typed approach. And I complement Bjarne for doing so.
> Instead of trying for some lofty goal of "purity", Stroustrup
>has created a language that can be *used*. None of the users or authors
>of C++ claim that the language is perfect, or pure. However the claims of
>its usability have been confirmed over and over again. The language *is
>being used* more than any other language in its class. And that usage is
>increasing at a geometric rate.
Widespread use is not a proof of quality. Neither does it invalidate
what the C++ detractors have to say.
>This paper is not an attempt to answer the complaints made by C++
>detractors. Rather it presents arguments for why C++ is a reasonable
>choice for the implementation of object oriented designs in a wide
>variety of application environments.
But it is the low levelness of C that precludes C/C++ from performing
effectively in all environments. A clean High Level Language design
coupled with well implemented compilers will ensure good performance
across a much wider platform set than C. There are environments where
C performs like a dog.
>Who am I that I should write such a paper? I am a user of C++, and the
>manager of a team of users. I have been using C++ since 1989, and have
>been involved with object oriented technology since 1986. I have
>produced, several large and successful systems in C++, and continue to
>enjoy such success. I am an international consultant who works with
>engineering teams, training them in object oriented design and C++, and
>helping them with their software designs. I am also the author of:
>"Designing Object Oriented C++ Applications using the Booch Method" by
>Robert Martin, Prentice Hall, 1995, ISBN 0-13-203837-4
>
>
>What the Deuce is Purity?
This is an easy question to answer. You certainly make a big issue
based around the word 'pure'. But you are setting up a strawman
argument against languages which are targetted towards the problem area,
rather than the machine area. You see proponents of such languages as
misguided 'purists.' Well, I think those who develop such languages for
good practical reasons are getting fed up of being 'set up' by the C
world like this, and it is high time that Ritchie's comment was
dispelled. If it was ever applicable, it no longer is, and it has
damaged the thinking of a whole generation of programmers.
So what is the definition of 'pure', at least in the OO sense? The two
languages that often have the term pure ascribed to them are Smalltalk
and Eiffel. Both are 'pure' in the OO sense, but both are pragmatic and
extremely *useful* languages. The term pure applied to these languages
simply means that they have been designed from the ground up around OO.
The term pure is a simple contrast to 'hybrid'. Firstly, the pure
languages aren't languages that have extended some pre-existing non-OO
language. Secondly, only OO constructs exist in these languages. You
do not have procedures outside of objects, nor do you have structs as in
C++ or records as in Object Pascal. You don't have globals. And don't
get me wrong, I would not condemn a language just because it is a
hybrid. Simula, the first OO language, is a hybrid, being a superset of
ALGOL (but even it removed problematic concepts such as 'own'). Simula
introduced the notion of class as a template for an off stack activation
record. I think that Object Pascal is a great language, but I just grew
out of it (I haven't seen Delphi yet). C++ however, is not such a clean
graft.
In short, you are making a big deal out of the word 'pure'. You simply
do not have a case here, when you realise that pure is a language
classification as opposed to hybrid. What's more is that languages that
are built to be pure OO from the ground up have quite a profound effect
on productivity, and ease of learning OO concepts. C++ has quite a
profound negative impact on these questions. You are too quick to
dismiss these effects, with no supporting evidence.
>Almost everyone can agree that C++ is not a "pure" OO language.
>However, this definition is problematic in that it implies that "purity"
>is a valid concept. Yet, there is no accepted definition of the term
>"pure OO language". Despite years of discussion and argument on the
>net, and in other circles, I have never seen anyone present a definition
>of a "pure OOPL" that met with general agreement by others.
Undoubtedly, there will be a lot of net flak over my definition of pure
vs hybrid in the attempt to discredit it, and reestablish the belief
that purists with a point to prove, actually do exist, so that it can be
'religion as normal,' with the hatred and suspicion of these fictional
purists reestablished. However, intelligent people will realise there
is no conspiracy to deceive the masses here.
>The fact that C++ is "impure" is often taken to mean that users are free
>to leave the golden path to OO and "backslide" into the unrepentant
>state of (gasp) procedural design. However, *every* OOPL must allow
>such "backsliding", because object oriented design is a *superset* of
>procedural design. It is *always* possible for a procedural design to
>be implemented in an object oriented language.
Well actually OO design and procedural design are quite different,
procedural design being top down, and OO design being more bottom up,
and using the building block approach. And this is where many of the so
called OO methodologies get it wrong. The old "structured design"
approach simply does not carry across. Sure a compiler can convert an
OO program into an equivalent procedural implementation, but the
programmer should not have to think in terms of procedural
implementation, as that breaks the OO abstraction. In doing the
translation to a procedural implementation, the compiler has stripped
away semantics, so it is not possible to convert a procedural
implementation back to an OO design (at least without manual
intervention). This makes the hybrid approach much harder to integrate
with other tools, like CASE tools which you might have in an OO
environment, and therefore C++ will not deliver as easily on these
important benefits.
>This assertion is easy to prove. A procedural design is a set of data
>structures and procedures. In an OOPL, one can create a single object
>which contains all the data structures and procedures of the procedural
>design. Thus, the procedural design is implemented within the confines
>of a single object. Don't laugh! I have talked to engineers who have
>done just this.
This is a good example. And I think it is an example of why people who
have written whole programs to do one function (eg compute sine (x)),
don't understand what it is to build systems with many and complex
functions. Once you get beyond the most simple, it is more natural to
break things up.
Lets consider where your example breaks down in a pure OOL. In a pure
OOL, you have no structures which are themselves not objects. Ie. as
soon as you want to introduce another structure, no matter how simple,
you have a separate object type. So without C structs, or Pascal
records, it is very difficult to implement a system as one homogenous
object. In a pure OOL, OO design tends to take over, and you much more
naturally break up your system into subobjects. That is without having
to resort to any formalised design methodologies. Some of these complex
design methodologies become less necessary. Of course you are right
that OO design is more than just breaking the system up into objects.
Once you have your classes, you must define the interfaces, and work out
the static properties and dynamic behaviour of each class. You need to
precisely describe any interactions that are going to take place. A
pure OOL will also tend to encourage you to write disjoint classes, with
small routines, both very important OO implementation techniques. C++
has in fact introduced nested classes and local declarations in blocks,
which work against disjoint classes and small routines.
>So what good is purity? I can't tell you, because I can't define it. I
>can tell you this, however. Purity, if it exists, does not force users
>to write good programs. And impurity, if it exists, does not force
>programmers to write bad programs. The main (possibley sole) ingredient
>required for good programs is good programmers.
But purity makes it more natural to write good programs. It makes them
more maintainable, extendable, reusable, easier to debug. The effect of
a pure language is quite profound, and you should not try to write off
this effect by claiming that you can't define 'pure'. In my view
'purity' helps the programmer focus on what's important, without
becoming distracted by details that are error prone and unnecessary.
Purity helps provide the programmer with a well balanced and useful
tool, a tool which cuts the 'crap' and nonsense, and avoids unnecessary,
confusing and problematic constructs. Purity has to do with good
language design and establishing a good set of programming principles.
Otherwise, we will never get quality software.
Besides good programmers are not going to use deficient tools, just to
prove that you can be a good programmer in any language. Good
programmers are going to adopt tools that more closely implement the
concepts they are using for design. Ie. they don't settle for poor
quality tools because of your above logic.
>The Benefits of C++ as a "Better C".
>
>Ignoring Object Oriented programming for the moment, probably the
>biggest benefit that C++ provides is type safety. C++ is a type safe
>language. What does this mean? Simply speaking it means this:
>
> void f(long l) {...} // function declared in one file.
>
> f(1); // in C, this can cause stack corruption since an integer
> // is passed instead of a long. However in C++, the
> // compiler knows that 'f' wants a "long" and so promotes
> // the '1' to the correct type.
>
>ANSI C makes type safety optional. C++ makes it mandatory. In C++ it
>is very difficult (not impossible) to violate the type system.
>
>Why is this important? Because type errors in C are often the causes of
>strange bugs that take weeks or months to find, and that exhibit
>transient and misleading behavior. They often foul the stack or heap
>and cause eventual failure several million instructions after the
>precipitating event. Such bugs are the hallmark of poor quality
>software. C++, in a single stroke, eliminates a huge percentage of
>them.
Absolutely. C++ is a better alternative to C. C as you point out has
lots of gotchas. But as my critique points out C++ has many gotchas as
well. You don't even need to read my critique, you can just read the
ARM. It is also a mark of 'pure' languages, that they will be largely
free of such gotchas, hence enabling the programmer to focus on the job,
not the tool. In fact one can walk into any bookshop and realise that
the industry is really focussed on C++ as a tool rather than the job, as
in any computer section, there are always multiple shelves dedicated to
C++ books. We need to get the industry focused on the job again.
>This advantage alone makes C++ a better alternative than C. C
>programmers don't have to learn any of the other features of the
>language to take advantage of type safety.
>
>
>C++ is a Low Level Language with High Level Features.
>
>When all is said and done, C++ is a language for the manipulation of
>bits and bytes. Although "purists" might rant and bemoan this attribute
>of C++, *engineers* sigh with relief.
Now who are these 'ranting' purists? They are only the figment of a
tortured C imagination, the 'filthy commies,' the 'reds under the bed.'
You cannot set up *engineers* as the good guys, against the purists.
This demarcation just does not exist. In fact in the past, I rejected
applying the term *engineer* to programmers (I don't mean it as an
insult to engineers). I reject it as hum bug on those who like to see
themselves as somehow respectable. Computer science and programming is
a respectable profession. However, in many ways, I am what you might
call a software engineer, as I have been involved with much systems
software, comms, networks, compilers. I am not an academic (I just have
a B.Sc Honours in computer science). However, I realise that you do not
need a low level language to implement such low level (well actually a
better word is fundamental) software elements. I have built lots of
system software, fiddled with bits and bytes, etc, etc. If I need to
bit fiddle, then I will. But it is so infrequently necessary to bit
fiddle that I would not consider having this facility riddled throughout
a high level language. If your environment requires frequent low-level
bit fiddling, then your environment is poorly designed (does this sound
like DOS and Unix?).
There are two factors that make bit and byte twiddling in your main
programming language unnecessary. Firstly, compiler technology means
that the compiler takes care of such target-oriented detail. Secondly,
if the compiler doesn't take care of it, in most languages you can
always write an external routine in a machine oriented language
(assembler, C, A Series Algol) to take care of the low level detail.
The advantage of this is that your low level bit twiddling and other
machine oriented details are centralised in a few places. This is much
better discipline. (Oh I'm sorry, discipline is a word that those nasty
ranting purists use).
If you don't do this, your code becomes less maintainable, harder for
those not familliar with the environment to understand, less portable.
It is good design to isolate this kind of code, and wrap it inside a
high level interface. And this means that 90% of the arguments in
favour of C++ just amount to nothing.
> All computer applications are,
>eventually, the manipulation of bits and bytes. We might not wish this
>were so, but it is.
No, that is not what we wish. I know only too well how hardware works.
However, it is not the level of abstraction at which it is profitable to
work. And yes bits and bytes are just another abstraction when you
think about it. Bits and bytes are just an abstraction that abstract
away the electronics of the computer. And bits and bytes do a good job
of abstraction, you never have to program in terms of gates, and
flip-flops, etc. If you did, the abstraction of bits and bytes would be
severely compromised. But similarly, higher level abstractions should
hide away the underlying bits and bytes. Otherwise they too are
compromised as abstractions. And C++ is a language that compromises OO
abstractions.
So how can I be so sure that we can completely hide away bits and bytes?
Because, that is what compilers do. I am willing to make the concession
to external routines for any really environmentally dependent stuff.
But I do not want this stuff in my language that I am using for design
abstraction, implementation, maintenance and extension.
There is an analogy here with building. When designing a house, an
architect doesn't worry about the individual bricks. Neither for that
matter does the builder. The architect is concerned with high level
abstractions such as space and light, and functionality. The builder is
concerned with walls, windows, doors, etc. The builder employs a
bricklayer to worry about the individual placement of the bricks. The
placement of bricks is a very computable thing, one after the other, one
on top of the other, extremely repetative. This is exactly what a
compiler does with bits and bytes. But the compiler can fully automate
this, as computers are indeed very powerful. Again, if your environment
precludes this kind of automation, there is something wrong with the
design and implementation of your environment (hence books like DOS and
Unix Haters handbooks are published, but even DOS and Unix don't
'preclude' this kind of automation.) If you have not realised that a
compiler can do this, then you have not realised what computers are good
at. You are forcing programmers to do mundane bookkeeping work that
they needn't be concerned with.
> And C++ provides the features that allow low level
>manipulations to be effient and easy. If, in the end, I need to store
>the bit pattern '10110100' in the byte whose address is FCA9DE, C++ will
>allow me to do so, without complaint.
And when you port this to the next environment, and find you have done
similar things in 30,000 places, you have one massive problem (made up
of 30,000 little ones). Then you will have complaints! Other languages
don't prevent you from implementing the functionality you want, they
just expect you to be more disciplined about it. That of course seems
like more work to the novice, but once you have explained how to do it,
then it is no big deal, and will save you lots of heartache in the long
run.
>But C++ also provides many high level features, so that the user can
>"pretend" that C++ is a high level language. This makes C++ useful in
>those places where a high level language is needed.
>
>As a user, and the representative of other users, I can attest to the
>fact that C++ succeeds in this dual role. I can implement high level
>abstractions in C++ using the high level structures of the language, and
>I can implement low level details using the low level structures of the
>language. It all works, and works quite well.
Sure it works. But that is not the argument against C++. The point is
that you end up with systems that are less maintainable, less robust,
less portable, etc. This is the effect of 'hybrid' programming
languages. In short you have not fulfilled the goal of producing
quality software economically. You are also dealing with a language
where the definition is not complete. C++ continues to evolve, and
some of these issues will have impact on current applications.
In fact you are presenting bits and bytes as the heart and soul of
programming. They are not. If you keep them below the abstraction
line, the elements of building systems and applications are abstract
data types (ADTs).
>Object Oriented Programming.
>
>Without a doubt, this feature of C++ is the most important. The reason
>is that well structured object oriented designs create applications that
>are robust, maintainable and comprised of elements that can be reused in
>other applications.
>
>It must be stressed that the use of C++ does not guarantee that
>applications will have these desirable attributes. In fact, C++ does
>not even "nudge" the user in the right direction. And neither does any
>other language! Bad designs are BAD DESIGNS, period. No language will
>correct them. No language, regardless of its "purity" will improve a
>bad design.
By this logic, there was no point in progressing past ENIAC's patch
panels. There will always be bad designers, but that should not stop us
creating better tools. We can only create better tools when we point
out the flaws in the current ones. As I pointed out above, actually
implementing clean designs will be more natural in a pure OOL. Your
designs will much more naturally tend to fall out. Your mistakes will
be more apparent, and what's more, easier to correct. The tools you use
to create a design, and the language you choose to express a design have
a profound effect on creating good designs. OO languages have made good
progress in helping programmers create good and correct designs. Of
course the 'methodologists' also deny the effect of languages on design,
but us programmers get tired of drawing imprecise boxes and lines, when
we can express the designs in a compilable language directly (and for
our employers, far more cheaply.) And we programmers have even less time
for those who can't program, but set themselves up as analysts, and
process managers with such diagramming tools, and then view programmers
as being some kind of low life.
>An Object Oriented design is a difficult thing to create. Using an OO
>programming language does not guarantee that the design will be object
>oriented. In fact, the design should be expressible indepedently of the
>language. It is for this reason that Object Oriented design notations
>(e.g. Booch, or OMT) have been developed.
But whatever methodology you use, you will express your design in some
language. Bubbles and squiggles on a page are a language. They are
just not a very precise language. These techniques can be useful, but
they will be far more useful when integrated with a programming language
that implements design concepts as well. This is another mark of a pure
OO language. This is not any high lofty ideal, it is extremely
pragmatic, and directly affects the production of quality software
economically.
On this point, I suggest that people read "Seamless Object-Oriented
Software Architecture: Analysis and design of reliable systems" by Kim
Walden and Jean-Marc Nerson (Prentice Hall). The key word is
"seamless".
>There is a large contingent of developers who believe that object
>oriented design is simply the partitioning of the application into
>representative objects. Such designs can be represented in the design
>notations, and can be implemented in OO programming languages. However,
>most often these designs do not follow the principles of object oriented
>design.
>
>Object oriented designs should have certain attributes. Those
>attributes include the structuring of source code dependencies such that
>source code modules that implement the detailed parts of the
>application are isolated from the source code modules that implement the
>high level policies, or business rules, of the application. Moreover,
>the detailed modules should depend upon the high level modules, and the
>high level modules MUST NOT depend upon any of the detailed modules.
^^^^^^^^
Now you are sounding like a purist. But the strange thing is that
earlier you said having dependencies on bits and bytes was OK. Well you
are being self-contradictory here, and this kind of contradiction is the
kind of problem that C++ will lead you to. If you set up a more
disciplined programming environment, then the careful engineer will
isolate the detail, without really even having to think about it.
>This management of dependencies is the key design activity needed to
>produce robust, maintainable and reusable designs. And yet very many
>designers that are new to OO do not understand this. No language,
>regardless of its OO "purity" will help a designer manage the
>dependencies between high level details and low level policies.
This I completely disagree with. This is exactly what the 'pure'
languages do. They help you 'separate the concerns,' minimise
dependencies. Your above misunderstanding indicates that you really
should get out of the C++ rut, and learn Smalltalk and Eiffel, and get
to understand how these languages help manage dependencies.
> -- [ I have written a paper that describes ]
> -- [ dependency management, and it is also well ]
> -- [ covered in my book. If you would like a copy ]
> -- [ of the paper, send me some email and I'll ]
> -- [ send it to you. rmartin@oma.com ]
>
>Once an object oriented design has been created, C++ is an excellent
>language in which to implement it. Once implemented, all the advantages
>of the design are exhibited by the source code. The modules created are
>robust in that they are isolated from changes made in other modules,
>they are maintainable in that the engineers need not fear that changes
>in one module will ripple to other modules, and they are reusable in
>that the high level modules do not depend upon the low level details,
>and so can be reused in a different detailed context.
Now you have hit the nail on the head. C++ is an 'implementation'
language. My major problem with C++ is that it is just that. What we
need in modern software engineering are languages that support design
and implementation seamlessly. We need languages that close the gap.
How many programmers have looked at structure charts and had to
laboriously translate them into an implementation? If you understand OO
principles, you realise this step is unnecessary. While C++ adds
classes, it is no where near as efficaceous as a pure OOL in this
respect. Besides having a complete and correct design before
implementation is in general unrealistic. I would rather a pure
OOL than a stringent set of style guidelines that programmers
have to stick to under threat of death. C++ style guidelines are
just no match for having such considerations naturally built into
the language.
>Run Time Efficiency.
>
>There are two broad classifications of Object Oriented languages:
>Statically typed languages like C++ and Eiffel, and dynamically typed
>language like Smalltalk or Objective-C. Both of these language types
>employ "run time binding" which is the attribute that makes object
>oriented design possible. However, the mechanisms employed by the two
>different language types are very different.
>
>In dynamically typed languages, every run time binding is looked up in a
>table of some kind. Although table lookups can be very fast, they still
>involve a loop, and a token matching algorithm. Hash tables are common,
>and some calls can even be resolved at compile time. Generally,
>however, it is impossible to precisely describe the time required for
>such an operation. And generally the operation requires dozens, or even
>hundreds of microseconds. Since a well designed object oriented program
>will make the majority of its function calls via this mechanism, the
>runtime overhead of a dynamic type system can be significant.
>
>In statically typed languages, run time bindings are performed by
>indexing into a table of pointers. This operation always requires
>exactly the same amount of time, and can be theoretically reduced to a
>single index into an array followed by a single pointer dereference. On
>most machines of today's calibre, these operations require less than a
>microsecond total.
>
>Most implementations of C++ come very close to achieving the theoretical
>limit, adding only one or two other pointer dereferences or index
>operations. For each implementation, the time required can be exactly
>specified.
>
>Thus, run time efficiency of run time bindings in statically typed
>language is always better than that of dynamically typed languages.
>What requires one or two microseconds in C++ may require dozens or
>hundreds of microseconds in a dynamically typed language.
>
>This makes C++ an excellent choice for applications that have intense
>real time requirements. It also makes C++ a good choice for component
>libraries that *might* be used in intense real time applications.
This section is true. However, since Eiffel is also statically typed,
and therefore lends itself to the same efficiencies as C++, and because
it is a language that supports the software engineering process as a
whole from analysis to implementation and testing, I suggest that Eiffel
is the better choice for the modern software engineer. (And you will not
have to waste time familliarising yourself with a stringent style
guide, except for being familliar with a few typographic principles
as laid out in Appendix A of Eiffel: the language.
>Memory Managment.
>
>C++ is one of the very few OO programming language that does not require
>dynamic memory management. Perfectly sound OO programs can be
>implemented without using the "heap" at all. This is extremely
>important to those industries that have regulations against "heap"
>usage. (e.g. Avionics.) Objects can be created on the stack just like
>auto variables, or they can be created statically. In such cases, there
>is no need for memory cleanup, and no risk of heap fragmentation or
>exhaustion.
>
>C++ is the one of the only languages that allows the programmer to have
>complete control over the way memory is managed.
Well, Eiffel also gives you a good deal of control without sacrificing
cleanness. It does not sacrifice having a garbage collector. To quote
Bertrand Meyer from "Eiffel: The Language":
"Authors of Eiffel implementations are encouraged (although not required) to
provide a garbage collection mechanism which will take care of detecting
unreachable objects. Although many policies are possible for garbage
collection, the following properties are often deemed desirable.
"* Efficiency: the overhead on system execution should be low."
"* Incrementality: it is desirable to have a collector which works in small
bursts of activity, being triggered at specific intervals, rather than one
which waits for memory to fill up and then takes over for a possibly long
full collection cycle. Interactive applications require bursts to be (at
least on average) of a short enough duration to make them undetectable
at the human scale.
"* Tunability: library facilities should allow systems to turn collection
off (for example during a critical section of a real-time application)
and on again, to request a full collection cycle, and to control the
duration of the bursts if the collector is incremental."
Also, I believe that if you disable GC completely, that if memory
becomes exhausted then GC will automatically be reinvoked, as this
is preferable to the application crashing with "no memory available,"
which would mean a considerable interruption to run time performance.
> If the user wants to
>use a heap, he can. If he wants to implement his own heap, he can. If
>he wants some objects to be created on the heap, and other objects to be
>created on a separately managed heap, he can. If he wants his heap to
>be garbage collected, he can implement or buy the appropriate collector.
>I know of no other language that provides such flexibility.
>
>C++ is often "bashed" because it does not provide garbage collection.
Well, on that count you had better include Bjarne Stroustrup among the
"bashers." In D&E of C++ he says on p198:
"Should a new language support garbage collection directly, say, as
Modula-3 does? If so, could C++ have met its goals had it provided
garbage collection? Garbage collection is great when you can afford
it. Therefore, the option of having garbage collection is clearly
desirable. However, garbage collection can be costly in terms of
fun time, real-time response, and porting effort (exactly how costly
is the topic of much confused debate). Therefore, being forced to pay
for garbage collection at all times isn't a blessing. C++ allows
optional garbage collection [2nd,pp466-468]. Several experiments
with garbage-collecting C++ implementations are in progress. I
expect to rely on garbage collection in some, but not all, of my
C++ programs within a couple of years (s10.7). However, I am convinced
(after reviewing the issue many times over the years) that had C++
depended on garbage collection, it would have been stillborn."
Further on p219, he continues:
"Also, garbage collection would make C++ unsuitable for many low
level tasks for which it was intended. I like the idea of garbage
collection as a mechanism that simplifies design and eliminates
a source of errors. However, I am fully convinced that had garbage
collection been an integral part of C++ originally, C++ would
have been stillborn."
"Garbage collectors have improved, and many of the techniques for
"home-brew" garbage collection that I had envisioned or used don't
scale up from individual projects to general-purpose libraries.
Most importantly, more ambitious projects are now done in C++.
Some of these could benefit from garbage collection and could
afford it."
Still some more quotes on pp221-222:
"The real problem is therefore whether optional garbage collection is
a viable option for C++. When (not if) garbage collection becomes
available, we will have two ways of writing C++ programs."
"In addition, it must not have unavoidable drawbacks that would make
C++ an unacceptable choice for significant applications. Given one
such successful experiment, implementers will scramble to provide the
best implementations. We can only hope that they don't choose mutually
incompatible schemes."
"I am under no illusion that building an acceptable garbage collection
mechanism for C++ will be easy - I just don't think it is impossible.
Consequently, given the number of people looking at the problem
several solutions will soon emerge."
This is a thorough and frank appraisal of the GC issue. But there are
already languages on the market that provide garbage collection, in an
optional form, and in a form that unifies application development. In
fact if you adopt one of these languages now, you will not face the
problems that you will eventually be faced with in C++ (probably, the
many applications that "are now done in C++" and "could benefit from
garbage collection and could afford it" will have to be substantially
rewritten.
My advice to those considering which OOL to use is to consider a
language that already has these facilities. Not only will you reap the
benefits NOW, you will save yourself the cost of always playing catch up
to C++, while Bjarne deals with "stubborn old-time C users, would-be C
experts and genuine C/C++ compatibility issues."
And on the subject of catch-up. Who pays for this activity? It is not
insignificant. In fact it is probably so significant that only the
large cash rich software companies (such as Microsoft) will be
able to fund it. This makes the software industry a less competitive
place as small companies just will not be able to afford entering the
software game. So companies should beware of the directions technical
people recommend, as they recommend what they are interested in at
the time, or what will be good for their career prospects, without
considering what the long term impact is for a company, which they
will be long gone from. And short term consultants are even worse,
as they often advise as far as analysis and maybe design goes, but
are long gone by the time implementation issues get in a mess.
>The argument proferred is often: "GC is intrinsic to OO. GC is needed
>to free the programmer from managing memory. The lack of GC imposes
>extra complexity on the design." Irrespective of the truth or falsity
>of these arguments, there is another argument to be made: "Programmers should
>have complete control over how memory is managed." I know of no
>language that provides more control over this area than C++.
No, memory is a low level implementation issue. You just do not need to
have control over it to implement the vast majority of applications.
Better support for memory allocation and garbage collection is now being
designed into hardware and operating systems.
The argument against non-GCed environments is that you get an intricate
network of dependencies between objects. These dependencies make
programs much more prone to programming error, harder to maintain, and
more difficult to isolate the components so that they can be used in
other environments. GC is to a large extent necessary. However, I am
willing to accept the pragmatic approach of Eiffel, where the GC can be
disabled for applications which have a more stable object environment,
and maybe need to run in real time. This is a much better solution.
Have GC as part of the underlying environment. In C++, you must add GC
on top of your program.
Yet another argument for GC is that in a stack-oriented language such as
ALGOL, all allocation of data areas and stack frames is done
automatically, below what the programmer sees. This adds no burden to
the programmer at all, it just happens. If OO is to be a success and
truly useful, then object allocation and deallocation must be as
painless as stack allocation in a stack-oriented language.
>The point is this. If you really think that you need garbage
>collection, then you can have it. It won't be neatly integrated into
>the language, and there will be a certain amount of difficulty involved,
>however you can gain the bulk of the advantages of a garbage collected
>environment if you absolutely need them. However, if you don't need
>them, (and very often you don't) you don't have to have them. In this,
>C++ is unique.
This is essentially solving the problem backwards. The better approach
is as above, to supply GC by default, and let the developer decide
whether to use it, and how much to use it. Right now its going to cost
you to work out how to do GC in C++. In the future it will cost you
again when you have to adapt to whatever scheme becomes standardised.
>But what about memory leaks? Yes, this is a problem. Any consciencious
>programmer should deal with this issue. There are several ways. First,
>you can get a garbage collector. Second, you can use a tool like
>Purify, or Bounds Checker. Third, you can use an environment like
>ObjectCenter for tracking heap problems. Fourth, you can write your own
>heap allocator and put your own tracing mechanisms in. Fifth, you don't
>need to use the heap at all.
>
>OK, then what about heap fragmentation? Yes, this too is a problem.
>However it is almost trivial to write an allocator that can't be
>fragmented. Stroustrup describes such an allocator in "The C++
>Programming Language" 2d. ed. And Rogue Wave sells one in the Booch
>Component library. C++ allows you to use such an allocator instead of
>the standard (malloc based) allocator.
But if the solutions to this are so easy and well known, why force each
individual programmer to have to think about it. Just provide these
facilities integrated with the compiler and the underlying run time
environment.
>Third Party Sources and Support.
>
>C++ is by far the most supported object oriented language. There are
>compilers for nearly every major platform out there. There are even
>cross compilers for embedded systems. Moreover there is a large and
>growing supply of third party tools and class libraries. No other
>object oriented language even comes close to the coverage and sourcing
>that C++ enjoys.
Perhaps so. But there are still major platforms that don't have C++.
And because of C's assumptions about certain things in the environment,
the implementation of C++ on these platforms is problematic. Other OO
languages also have wide deployment and support from multiple vendors.
You are just promoting the FUD line.
>C++ derives from C.
>
>Although this point is often counted as an argument against C++, I count
>it as an advantage of the language. It means that C++ programs can be
>easily integrated with legacy C code, and legacy code in other languages
>that are C callable. C++ programs can call C programs, and C programs
>can call C++ programs.
>
>Moreover, C++ inherits all of the attributes that make C such a
>successful and useful language. Although C++ is a bigger and more
>complex language than C, it still "feels" like C. This is a subjective
>point, but one that is not insignificant.
True, if you are a C shop then perhaps consider C++. But also consider
alternatives to C++ if you are intending to do OO seriously. If you are
a non-C shop, particularly a COBOL shop, do not be fooled by C++. You
will reap the true benefits of OO (not the hype) by choosing and
environment that implements OO in a clean fashion.
>Conclusion
>
>Wait a minute! Is that all? Aren't there more reasons to use C++ than
>that? Sure. There are lots of little details that I passed over. Why?
>Because they are details, and because they can be contentious. I could
>tell you how great templates are, or how wonderful operator overloading
>is, or how neat pure virtual functions are. But why?
Because these are not unique features to C++. And besides you will find
them implemented with cleaner syntax, less problematic semantics, and
more understandable ways in those horrible 'pure' languages.
> For every point I
>could make, someone else could refute it and say it is ugly or nasty.
>And who should you believe? Your best recourse is to find out about these
>features for yourself. I recommend that you do a lot of reading. Then
>examine the arguments, pro and con, and decide for yourself. Don't
>hesitate to drop me a line asking me what I think about this or that.
>(rmartin@oma.com).
>
>But isn't C++ ugly? Part of it, yes. So what? English is an ugly
>language too. Ask any Frenchman. Consider the word "garage". This is
>an ugly word. Listen to it. Yuck!
"Garage" is a perfectly beautiful French word! (Coming from garer, to
park). Garage does not even have an ugly dipthong. (Or did you mean to
type "garbage"?) I would love to get rid of many ugly dipthongs in
English, such as those who say rowt for route, and not root (after all
we say sub roo tine, not sub row tine). These ugly dipthongs have a
practical effect, as they cause problems with the english spelling
system. English spelling shows that ugliness in speech does have a
profound effect on a practical issue. In programming languages we can
do without issues analagous to spelling in English. I would also love
to get American English speakers to use round Os, rather than the flat
'ah' sound, eg 'god' instead of 'gard'. These effects arise from the
vaguaries of relating spelling to the sound system. We can do without
the vaguaries in programming languages. In fact having such vaguaries
in programming languages severely limits their effectiveness as
precision engineering tools.
The analogy that natural language is similar to programming language is
not even strong enough to be flimsy. Natural language, we have no or
very little control over. However, programming languages are something
we must define precisely, otherwise they are of little use.
> But we don't often see the "ugliness"
>of the word because we *use* it to represent a concept that is not ugly
>at all. The same is true of C++. Yes, I can understand why some people
>would think that some of the features or syntax of C++ are ugly. But
>the concepts underneath are not. Once you begin using the language, the
>"ugliness" evaporates.
In fact the ugliness does not evaporate. Just because you learn what
the traps are, and how to avoid them does not remove the traps, or this
ugliness. Just because you might eventually learn how C++'s obscure
syntax (eg '= 0' with abstract functions) does not suddenly remove the
impedence mismatch between C++ syntax and OO concepts. The ugliness is
still there, only your perception might have changed. The pure OOLs
implement OO in a way that is not ugly, in other words in an 'elegant'
way. Ugliness has nothing to do with making a programming language
practical. In fact the 'elegant' approaches to OO show a good deal more
pragmatism.
The ugliness of C++ relates to the number of traps that you can fall
into, and to how C++ obscures relatively simple and elegant OO concepts.
>I have not been trying to tell you that C++ is the only OOPL and all
>wisdom dies with it. I have not been trying to tell you that C++ is the
>language you should be using. I have simply been trying to tell you
>why I use it, and why I think it is a reasonable implementation language
>for object oriented designs.
Again the point is that C++ is an implementation language. We need
notations that support designs, which can be extended seamlessly to
implementations, and run through a compiler to generate correct and
efficient programs. (By the way, I think you have downplayed C++'s
attempt at introducing classes and design concepts into C. I recognise
that it has done so, but it is an uncomfortable match of opposing
paradigms. And besides it is not even finished yet.)
I cannot question that those are your reasons for using C++. However, I
would like to see more OO consultants consult in OO, and not just C++.
Again they are focused on the tool, and not the job. What companies
need is advice of how to move into OO, in order to reap the benefits of
OO, not just keep up with the latest fad. When consulting to a company,
the companies current position should be profiled. If they are a C shop
with lots of legacy code, then C++ might be the choice to progress to
OO. But probably is not the choice where they are intending to develop
new applications from scratch. If it is a non C shop, then Eiffel and
Smalltalk are the obvious choices to cover different ends of the OO
spectrum. C++ should not be considered for non C shops.
>If you want to use some other language, do so. It's no skin off my
>apple. But don't fall prey to the religious arguments of C++
>detractors.
No, don't fall prey to religious arguments, full stop. However, do
realise that the detractors of C++ are mainly reasonable (perhaps not
all of them, but you know who to ignore on the net.) But I do recommend
that you read chapter 7 of Wiener's "Software Construction Using
Eiffel", and my own critique.
> C++ is a great language. It will not corrupt you, nor drag
>you down into the hell reserved for mediocre programmers. Nor will it
>turn you into "Super-Programmer" able to leap tall specifications with a
>single switch/case statement. No language has such powers! Software is
>not a religion.
True, which means that no language or methodology is beyond appraisal or
criticism. It is strange how upset the C++ protagonists become when you
point out the deficiencies in their language, a very religious reaction.
>C++ is a language. It is a good language. It is a usable language.
>And if you are interested in implementing object oriented designs, it
>will work for you.
And if you want to do OO designs and implement seamlessly, then it is
not. And if you realise like so many of us that many design mistakes
only show up in implementation, and you need to recurse, rework,
redesign and modify along each step of the way, then you have begun to
realise the need to move past C++, without even considering the flaws in
the language.
There is one thing that C++ does. That is it sets a benchmark for
performance against which other OOLs can be judged. However, other
OOLs can achieve performance comparable with C++, even with the
inclusion of garbage collection. (However, C++ does not provide
a consistent benchmark over all environments. For example, I believe
that the A Series Eiffel compiler will outperform just straight C
on the A Series. It already compiles faster than C.)
Postnote:
It might seem that I have criticised Bjarne Stroustrup's book, Design
and Evolution of C++. However, I am not critical of the book. I have
quoted from it quite a bit as I think it is a valuable insight into
why C++ is the way it is, although it is obviously promoting C++,
and offering a defense for the state that it is in. Stroustrup
has given us in this book a valuable insight into the C++ process.
In many cases it is quite frank about the problems with C and C++,
for example the sections on garbage collection.
But it is some indication that it will take C++ maybe 10 to 15 years
to catch up to where OO technology now is, and even then because of
its C base, and its mixed mode programming, it won't catch up with
the pure design of competing languages. The question (that current
indications suggest will be answered in the positive) is will Eiffel,
Smalltalk, etc gain enough market prominence in 2 to 3 years? I do
believe that C++ has done a favour to the C world. It has however
done a disfavour to the OO world and industry as a whole.
>--
>Robert Martin | Design Consulting | Training courses offered:
>Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis
>2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design
>Green Oaks IL 60048 | Fax: (708) 918-1023 | C++
>
Up to Unix-Haters Archive Main Page
Next The Sons of Martha, by Rudyard Kipling
- The "Anti-Unix" Spirit