Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.object
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu!caen!usenet.cis.ufl.edu!usenet.eel.ufl.edu!news.uoregon.edu!engineer.mrg.uswest.com!cherokee!da_vinci!lookout!tblanch
From: tblanch@lookout (Todd Blanchard)
Subject: Re: C++ Productivity
Message-ID: <D3FuGq.Kwv@da_vinci.ecte.uswc.uswest.com>
Followup-To: comp.lang.c++,comp.lang.smalltalk,comp.object
Sender: news@da_vinci.ecte.uswc.uswest.com (IT Netnews)
Nntp-Posting-Host: lookout
Organization: US WEST Information Technologies
X-Newsreader: TIN [version 1.2 PL2]
References: <1995Jan23.193745.7044@boole.com> <jim.fleming.84.00133AB6@bytes.com> <1995Jan25.201226.28856@rcmcon.com> <jim.fleming.75.0003AF13@bytes.com> <3gls1u$p2l@osfa.aber.ac.uk> <1995Feb1.184049.16332@rcmcon.com> <D3E33s.DCp@da_vinci.ecte.uswc.uswest.com> <1995Feb3.172403.2977@rcmcon.com>
Date: Fri, 3 Feb 1995 19:07:38 GMT
Lines: 178
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:110809 comp.lang.smalltalk:20319 comp.object:26081

Robert Martin (rmartin@rcmcon.com) wrote:
: tblanch@lookout (Todd Blanchard) writes:

: >Here, perhaps is the point.  The C++ language is entirely too large and
: >complex.  

: Certainly it is large and complex.  But not "too large" nor "too
: complex".  If it were, then it would not be selling as well as it is.
: You can claim that the purchasers don't really know what they are
: buying, but that is a pretty weak argument.

I could argue that if Windows wasn't a technically elegant architecture
then no-one would buy it either.  Technical excellence has never driven
the market.  Your claim "It sells, therefore it must be wonderful" is
clearly false.  In the software market, worse is better frequently
prevails.

And I submit that C++ is at least an order of magnitude larger and more
complex than C, Pascal, Cobol, FORTRAN, or whatever.

: >It is *hard* to use correctly.  

: Yes, C++ is hard to use correctly.  So is Smalltalk.  So is Pascal.
: So is C.  So is any computer language.  Why?  Because software is
: hard.

Yes but C++ is *so* much harder than Smalltalk, Pascal and C.  It is
hard relative to other tools.  Or, rather, perhaps Smalltalk, Pascal,
and C are *easy* compared to C++.

: If you are saying that C++ is harder to use than other languages, I
: agree to a point.  There are projects for which the C++ learning curve
: could not be justified.  However, for large, industrial projects, C++
: provides tools which pay back the learning curve.  For these kinds of
: projects, C++ is finally easier to use than many other languages would
: be. 

I have heard these claims for years now.  I have seen no metrics in my
personal 3 years of large scale C++ development.  It is simply not
suited to programming in the colossal.  It is good for smaller things
like OpenDoc components, shrink-wrapped apps, and similar.  I wouldn't
build a large information architecture with it.
: >It takes at *least* two years
: >for a person to become expert at its use.  

Well, from my vantage point I look out at about 100 programmers.  They
have been working in C++ for over a year.  I think about 5 of them are
actually good at it.

: 6 months is more in line with my experience, and that of my
: associates.

You run with a brighter crowd than I do then.

: >If you are not expert, you are not likely to be successful.  

: I think this is unfounded.  I know of several projects where the
: programmers were new to C++, and yet managed to create successful
: projects. 

Me too, some of the nicest C code I've ever seen is usually the result.

: As for type conversions, yes, it takes a while to get used to strong
: typing.  However the benefits are significant.  Many of us prefer to
: use strongly typed languages.  In the end, one learns how to design
: software without the need for lots of type conversions.

On the contrary, I spend most of my time coming up with clever tricks to
allow type conversions among different vender packages.  The old

void f(cons foo&)

class foo
{
public:
   foo(const char*);
   ...
};

const char* c = "I want to be a foo";

f(c);

is not so good.  Also, C++ gets huge what with templates and all.  A
recent program compiled to 40M.  30M was RW list class instantiations.
The answer was to go back to void*.  Lovely type safety.

: >If they come
: >from a C background, they do not properly use the OO capabilities.

: >Now I don't know about you, but the average person I meet is simply not
: >that bright.  And it takes a *very* bright person to become expert at
: >using C++.  

: It takes a very bright person to design software.  Anybody that can
: create a credible software design will find C++ trivial in comparison.

This is simplyu bogus.  Your average DP cobol programmer is not as
bright as you think.  Again, I think you run with a brighter  crowd than
I typically encounter.  You give the programmers too much credit.  If
your thinking is correct, then why do electricians use insulated wire.
Certainly a competent electrician can properly run bare wires if he
knows what he is doing (this used to be the way it was done BTW).  OTOH,
insulated wire allows him more leeway in his design and has been shown
to reduce the number of electrical fires and injuries.  

You suffer from UNIX thinking I think.  Screw safety rails, I'll just
drive a road-huggin Ferrari and since I know what I'm doing, I'll be
fine.  Right.

: >C++ is not an evil language, but it is not for the masses.

: No computer language is for the masses.   Not even Basic.

I mean the DP professional programming masses.  Our brother/sister
programmers.  Of course I don't mean my mom.  She's still grappling with
which end of the disk is up.

: >That C++ is so hard to use correctly *is* a weakness of the language.
: >The language is too big, too much code gets called unexpectedly.  A
: >perfect example is a program where I had to inherit from a vender
: >supplied class.  The class had a const char* operator.  I thought this
: >would get used when I said:

: >cout << myObject << endl;

: >It was, sort of but my object was first copied onto the stack, then
: >converted.  The vender code was not copy safe and had pointer based
: >memory.  The app went down in flames and I spent 2 days figuring this
: >out.  This happens all the time in wonderful C++. 

: Certainly this happens.   That it happens "all the time" is contrary
: to my experience.  

I guess you lead a charmed life.  Our work plan and time tracking shows
we spent about 50% of our time tracking down these lovely gotchas.

: >The language attempts to do too much, type conversion and copying go on
: >all the time, usually without the knowledge of the programmer.  

: Only if the programmers supplies the conversion operators.  And if he
: does, then let it be on his head to be aware of when they will be
: used.

See foo example above.

: >Why does
: >the compiler write a copy constructor and op= for everything?  This
: >feature alone is most likely responsible for hours of grief.

: Once you learn the language, this ceases to be a problem.  You code
: your own copy constructor and assignment operator unless you are
: absolutely sure that the once provided will be appropriate.

No it doesn't.  When you are writing code quickly to meet schedules,
this sort of thing is easy to forget.  Better the compiler force you to
write one if it needs it than just quietly do it on its own.  I don't
generally want any code executed that I didn't explicitly specify.

: >In my experience, C++ costs more, takes longer, and is much less
: >dependable than C because of all of the unexpected little behaviors.

: In my experience, C++ has allowed me to create designs that are
: reusable and maintainable, and to greatly reduce the development
: effort on significant projects.

Clearly, our experience is different.  I resent your condescending tone.
I have been working in C++ a *long* time.  I know it better than anyone
I know.  And it is still a bit like wiring a house with bare wires, its
easy to get zapped unexpectedly unless you can maintain extraordinary
discipline at all times.  It is not a good language for enterprise
computing.  I could not recommend its use to a client trying to build a
business information system.  Its really not that reusable.  Perhaps SOM
compilers will help fix this.

Time will tell.

Todd Blanchard
