From: ········@bayou.uh.edu
Subject: Re: What is wrong with OO ?
Date: 
Message-ID: <5dgboh$1g7@Masala.CC.UH.EDU>
Paul Campbell (·················@lucent.com) wrote:
: Jose Castejon wrote:
: > 
: > Travis C. Porco wrote:

[Snip]

: C++'s intended target audience is programmers who on large projects,
: often in teams. To anyone who has worked in such an environment 
: the extra features of C++ over c offer huge advantages in areas of
: modularity and code reuse.

With all due respect that's a load of BS.  C++'s faults become
ever more acute *WHEN* you are on a large project working with
a team.  C++ becomes an even bigger liability in that case
than it already is!  Have some folks use C "features", do
funny things in constructors and/or destructors and throw
in some friend functions and see how quickly it takes for
your project to break down.

The one language that I've seen, which can truly claim the
honor of being developed with the team in mind is Ada.
Take a look at Ada and you'll see what a *REAL* language
is like.  This isn't some dirty hack thrown together
and pushed off on a hapless public, this is a well thought
out system.  You can see the reasoning behind features,
and the use for them rather than flaws and blunders
that are the definition of C++.


: In other words the one of primary design aim of C++ was to address
: well known large-scale software engineering problems (The same problems
: that OO is trying to address) while making use of peoples existing 
: C skills. It is really not possible to get a "feel" for these 
: issues unless you have been there so you will just have to take
: it on faith that the advantages are real.

The advantages are not real.  If this was C++'s goal, then it is
an even greater failure than I thought.  C++ makes it tremendously
easy for you to get lost in a maze of code, and have your code
do things behind your back.  No way on Earth that such a system,
which is the pinnacle of danger could be designed for TEAM work.

In a group project you want *CONTROL* and *CLARITY*.  You
want to be able to read and maintain the code produced by
others, and to discourage them from trying funny things.
C++ just opens a whole new pandora's box of tragedies.  


: >         I would be very grateful if somebody can provide examples of
: > the convenience of using C++ instead of C: what kind of problems,
: > techniques, and programming approaches. The books I have consulted
: > fail to do so.


: It is difficult to give convincing trivial or small demostrations
: of these advantages because the advantages in these sorts of cases
: are indeed often marginal. But it is precisly because the examples
: are *small* that the advantages of using C++ do not  appear to be 
: that great.

When the examples are small, it's hard to see what benefits C++
has over C.

When the examples are somewhat larger than trivial, then it's
easy to see what benefits C++ has over C.

When the examples are large, it's easy to see what benefits C++
does not have over C.

And the sad thing is that C is a miserable joke to begin with.

Comparing C++ to C is like comparing a dung beetle to a maggot
infested carcass.  Niether can be considered desirable
by any stretch of the imagination, it's only in comparison
to each other that any illusion of quality can be brought
forth.


: Paul C.
: UK.

--
Cya,
Ahmed
From: robert fielding
Subject: Re: What is wrong with OO ?
Date: 
Message-ID: <01bc21fd$0bbb5480$cb6660cf@ozric.erols.com>
Chris Bitmead <·············@Alcatel.com.au> wrote in article
<······················@Alcatel.com.au>...
> In article <··········@Masala.CC.UH.EDU> ········@Bayou.UH.EDU
(········@bayou.uh.edu) writes:
> 
> >With all due respect that's a load of BS.  C++'s faults become
> >ever more acute *WHEN* you are on a large project working with
> >a team.  C++ becomes an even bigger liability in that case
> >than it already is!  Have some folks use C "features", do
> >funny things in constructors and/or destructors and throw
> >in some friend functions and see how quickly it takes for
> >your project to break down.
> 
> I do agree. C++ does tend to impose more structure and order on large
> projects. Trouble is, eventually too much time is spent trying to keep
> the structure and order coherent (not to mention compile times), and
> too little time actually making real progress and it all breaks down.
> 

The biggest problem of all is that you can't neglect the human aspect of
programming language design.  The discipline is not in the language itself,

so you have to waste a good chunk of time and money on imposing it.  In 
the design of C++ is a punishment/reward system that is heavily in favor of
violating OO.

True programming freedom is having a language that is strict enough to make
certain classes of programming errors unthinkable, and real optimization is
using better
algorithms (which may be too unwieldly to write in a really raw language
like C++).

For example:
O(n^2) algorithms written in optimized assembler can't compete with
O(n*lg(n)) algorithms
written in ...say pitiful VB... if you give it enough data to chew on. 
With 32M-64M becoming standard on PCs, that day is coming very soon.  The
capacity of PCs is changing the whole meaning of 'optimization' and it is
making less and less sense to haggle on bytes and CPU cycles.  Really good
algorithms can be a pain to write in
C++ because it's too close to the metal, so you see silly people trying to
save bytes
and CPU cycles within an algorithm that is wasting an order of magnitude
more than it 
ever should in any language whatsoever.  C++ should not be used for most
types
of applications because of its promiscuity, inconsistency, and complexity.

rob