What is wrong with OO ?

What is wrong with OO ?

[Ahmed]

Hello Every Body

I am a new  research student working at the field of Object Oriented Technology...I have several 
critical opinions about Object Oriented in general, and I like to participate it with you and hear 
you expert comments and opinions

Object Oriented Technology came with quite promising claims that if achieved can benefit the software 
development companies and organisations millions of pounds.

Some of these claims for instance
1 - high reusability of objects and frameworks
2 - Resilience to change, i.e. low software maintenance and evolution cost
3 - Easier understanding by the user and Natural transition between the analysis, design, 
implementation because they all use tangible perceived objects.

However the reality is not so bright as claimed..if so, then nobody today thought to  develop a
software on the traditional structural methods...

My question is what is wrong with OO ? why it did not achieved its targets yet.?
What are the main obstacles? 

Is the problem with the immature OO methodologies ( OO analysis and design in specific ) ?
or is it the deficiency in the development  tools used like C++ or Smalltalk ?
or is it the steep difference in thinking between the traditional and OO schools ?
or is it  related with the difficulty of object classification ?
or is it  because of vast legacy systems done using the traditional methods ?
or is a combination of many other factors...?

I know that giving a precise answer is very difficult for such a complex question, but I like to
hear the comments of people working at the feild and who suffered from many difficulties..

I would really appreciate any participation, response or even leading to a good reference ,
and would be very grateful if the opinions are supported by some evidences...


Thanks

Yours 
Ahmed Alkooheji
University of Sheffield
UK

Re: What is wrong with OO ?

[Bill Gooch]

Ahmed wrote:
> ....
> Object Oriented Technology came with quite promising claims that if achieved can benefit the software
> development companies and organisations millions of pounds.
> 
> Some of these claims for instance
> 1 - high reusability of objects and frameworks

While this may be claimed about specific frameworks, it is
not IMO a valid generalization about OOT.  It is feasible
and important to design and implement objects which achieve
immediate *reuse*, general *reusability* is quite rare, and
exceedingly difficult to achieve, IME.  Typically the costs
outweigh the benefits.

To be clear what I mean by "immediate reuse" - it is most 
often fine-grained (method and protocol level) reuse of 
behavior via inheritance, delegation, etc. which is readily
achievable and most important.  Medium-grained (class level) 
reuse is also feasible, although it requires greater design
effort and foresight (and/or prior experience in the domain).
Large-grained (framework level) reuse is much harder (I think
somewhat exponentially with the number of classes/protocols/
relationships involved), and much more rarely achieved.

> 2 - Resilience to change, i.e. low software maintenance and evolution cost

This depends entirely on the quality of the analysis, design
and implementation.  Objects effectively *support* resilience
by allowing implementations to mirror problems in a way that
minimizes unwanted dependencies, thereby limiting the scope of 
changes.  However, such results certainly aren't automatic, 
and the misconception that resilience is an inherent attribute 
of OOT works against the accomplishment of it.

> 3 - Easier understanding by the user and Natural transition between the analysis, design,

I'm very unclear what you mean by "Natural" here, but again,
ease of understanding by anyone is entirely dependent on the 
quality of analysis, design and documentation.  Again, OOT
used effectively can facilitate ease of understanding, but
that doesn't happen by itself.

> implementation because they all use tangible perceived objects....

Sure, software objects are "tangible perceived objects" 
(sometimes perceived anyway), if only inasmuch as we've 
decided to *call* them "objects."  The more I think about it,
the more this choice of a name for software entities strikes
me as having been a mistake.

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: What is wrong with OO ?

[Bill Gooch]

Bill Gooch wrote:
> 
> Ahmed wrote:
> > ....
> > Some of these claims for instance
> > 1 - high reusability of objects and frameworks
> 
> While this may be claimed about specific frameworks, it is
> not IMO a valid generalization about OOT.  It is feasible
> and important to design and implement objects which achieve
> immediate *reuse*, general *reusability* is quite rare, and
> exceedingly difficult to achieve, IME....

Sorry, that last sentence should have read:

"Although it is feasible and important to design...."
 ^^^^^^^^

Re: What is wrong with OO ?

[Fred Parker]

Ahmed wrote:

> chop
> My question is what is wrong with OO ? why it did not achieved its targets yet.?
> What are the main obstacles?
> chop
	"We don't suffer from a Deficiency of Knowledge, 
 	We suffer from a Deficiency of Execution"

fjparker@ix.netcom.com

Re: What is wrong with OO ?

[Ell]

Bill Gooch (bill@iconcomp.com) wrote:
: Bill Gooch wrote:
: > 
: > Ahmed wrote:
: > > ....
: > > Some of these claims for instance
: > > 1 - high reusability of objects and frameworks
: > 
: > While this may be claimed about specific frameworks, it is
: > not IMO a valid generalization about OOT.  It is feasible
: > and important to design and implement objects which achieve
: > immediate *reuse*, general *reusability* is quite rare, and
: > exceedingly difficult to achieve, IME....
: 
: Sorry, that last sentence should have read:
: 
: "Although it is feasible and important to design...."
:  ^^^^^^^^

How about all of the objects that are reusable in PowerBuilder?  Things
like Window, SQLCA, MLE, SLE, etc. objects which one uses time and time
again.  Similarly with other frameworks like MFC, where one uses
CDocument, CDialog, CView etc classes time and time again.  With these
objects and classes one has "immediate reuse" and "general reusability",
it seems to me.

Elliott

Re: What is wrong with OO ?

[Ell]

Ell (ell@access4.digex.net) wrote:
: Bill Gooch (bill@iconcomp.com) wrote:
: : Bill Gooch wrote:
: : > Ahmed wrote:
: : > > ....
: : > > Some of these claims for instance
: : > > 1 - high reusability of objects and frameworks
 
: : > While this may be claimed about specific frameworks, it is
: : > not IMO a valid generalization about OOT.  It is feasible
: : > and important to design and implement objects which achieve
: : > immediate *reuse*, general *reusability* is quite rare, and
: : > exceedingly difficult to achieve, IME....
: : 
: : Sorry, that last sentence should have read:
: : 
: : "Although it is feasible and important to design...."
: :  ^^^^^^^^
 
: How about all of the objects that are reusable in PowerBuilder?  Things
: like Window, SQLCA, MLE, SLE, etc. objects which one uses time and time
: again.  Similarly with other frameworks like MFC, where one uses
: CDocument, CDialog, CView etc classes time and time again.  With these
: objects and classes one has "immediate reuse" and "general reusability",
: it seems to me.

Sorry, I missed the "not IMO a valid a generalization about OOT".  Still
it seems to me that most everyone uses frameworks nowadays - their own, or
pre-made.  I agree with you that given the mechanics and language
differences it's almost impossible to reuse a class/object from one
environment in another.  But that doesn't make the goal for reuse within
the same environment any less important.

Elliott

Re: What is wrong with OO ?

[Harry Protoolis]

On Tue, 03 Dec 1996 17:38:37 +0000, Ahmed <ACQ95AA@shef.ac.uk> wrote:
>Hello Every Body
>
>I am a new  research student working at the field of Object Oriented Technology.
> ..I have several 
>critical opinions about Object Oriented in general, and I like to participate it
>  with you and hear 
>you expert comments and opinions
>
>Object Oriented Technology came with quite promising claims that if achieved can
>  benefit the software 
>development companies and organisations millions of pounds.
>
>Some of these claims for instance
>1 - high reusability of objects and frameworks
>2 - Resilience to change, i.e. low software maintenance and evolution cost
>3 - Easier understanding by the user and Natural transition between the analysis
> , design, 
>implementation because they all use tangible perceived objects.
>
>However the reality is not so bright as claimed..if so, then nobody today though
> t to  develop a
>software on the traditional structural methods...
>
>My question is what is wrong with OO ? why it did not achieved its targets yet.?
>What are the main obstacles? 

I think this is overly negative, OO has not been and never will be a
'silver bullet' to solve all software development problems, but no-one
but a few spin doctors ever claimed it would be.

However, the real question should be 'has OO made a significant positive
difference', and in my experience the answer is a resounding 'yes!'.

I have been a professional software engineer for 10 years now, the first
half of which was spent fighting against traditional structured
techinques, it was only despite them I was able to get anything
finished.

The traditional techniques all suffered from a number of significant
flaws. Perhaps the most damaging one was what I (rather unkindly) think
of as 'The glorification of idiots' phenomenon. What I mean by this is
that projects were typically infested by a group of people who never
wrote any software, but spent most of the budget drawing diagrams that
the implementors never used.

The main contribution of OO has been was could be termed 'The
glorification on the implementor'. This has been achieved by the
effective marriage of Analysis, Design and Implementation. The result
is that every member of the team does all three of the key tasks.

In fact IMHO an OO team has no place for anyone who cannot do all
three tasks. Jim Coplein wrote an excellent pattern called
'Architect also Implements' which covers very nicely the reasoning
behind not allowing non-implementors to design systems.

Certainly the mecca of automatic reuse has not been achieved, but the
quantity and quality of 3rd party components available for most OO
languages already exceeds that available for their non-OO counterparts,
and IHMO this suggests a bright future.

Certainly OO has not made writing software trivial or automatic, but
then, *nothing ever will*.

Cheers,
Harry
-
alt.computer pty ltd                    software development consultants

Re: What is wrong with OO ?

[Robert C. Martin]

In article <32A4659D.347A@shef.ac.uk>, Ahmed <ACQ95AA@shef.ac.uk> wrote:

> Object Oriented Technology came with quite promising claims that if
achieved can benefit the software 
> development companies and organisations millions of pounds.

Those claims were not made by the engineers and researchers who "invented"
OO.  They were made by marketeers who found a new way to differentiate 
products, and by engineers who had shut off their ability to employ
critical thinking.

> 
> Some of these claims for instance
> 1 - high reusability of objects and frameworks
> 2 - Resilience to change, i.e. low software maintenance and evolution cost
> 3 - Easier understanding by the user and Natural transition between the
analysis, design, 
> implementation because they all use tangible perceived objects.
> 
> However the reality is not so bright as claimed..if so, then nobody
today thought to  develop a
> software on the traditional structural methods...
> 
> My question is what is wrong with OO ? why it did not achieved its
targets yet.?
> What are the main obstacles? 

The claims were too grandiose.  Software is still software; and it is still
hard.  There are still bugs, still ambiguous specifications, still volatile
specifications, still improperly trained engineers, still engineers who 
shouldn't be engineers, still managers who don't understand the technology
they are trying to manage, still arbitrary completion dates, etc, etc, etc.

In any case, you shouldn't be surprised when highly publicized claims are
not achieved.  Generally those claims are just part of the overall hype 
associated with any new idea.

The truth is:  (If I may be so bold as to claim to know the truth ;)

  1-  OO, when properly employed, does enhance the reusability of
      software.  But it does so at the cost of complexity and design
      time.  Reusable code is more complex and takes longer to design
      and implement.  Futhermore, it often takes two or more tries
      to create somthing that is even marginally reusable.

  2-  OO, when properly employed, does enhance the software's resilience
      to change.  But it does so at the cost of complexity and design
      time.  This trade off is almost always a win, but it is hard to
      swallow sometimes.  

  3-  OO does not necessarily make anything easier to understand.
      There is no magical mapping between the software concepts and
      every human's map of the real world.  Every person is different.
      What one person percieves to be a simple and elegant design, another
      will percieve as convoluted and opaque.

  4-  If a team has been able, by applying point 1 above, to create 
      a repository of reusable items, then development times can begin
      to shrink significantly due to reuse.

  5-  If a team has been able, by applying point 2 above, to create
      software that is resilient to change, then maintenance of that
      software will be much simpler and much less error prone.

In short.  Nothing has gone wrong with OO.  It is a technology, and it
delivers everything it was designed to deliver, and perhaps a bit more.
That it doesn't live up to the naive claims made by naive or insincere people
is unfortunate, but not unexpected.

> 
> Is the problem with the immature OO methodologies ( OO analysis and
design in specific ) ?

No, these techniques have been a major contribution to software engineering,
and have gone a long way towards improving the way we build software.

> or is it the deficiency in the development  tools used like C++ or Smalltalk ?

No, the tools are more or less adequate for the job.  IMHO, someone
who blames a language for a failure should be looking a bit closer to 
home for the cause.

> or is it the steep difference in thinking between the traditional and OO
schools ?

I don't think it's the steepness of the difference, although the difference
can be very steep.  Instead I think that it is the disagreement by OO
authorities on the endpoint of that learning curve.  

For example, some folks will tell you that the secret of OO is think of the
world in terms of objects.  Others will tell you that it is to think
of the structure of the software in terms of polymorphic interfaces.  Still
others will tell you that it is to decouple the domains of the problem
by describing them using macros that can be statically bound at compile time.

Which is right?  Which is real?  There is a *lot* of confusion out there.
That some folks might not be experiencing any of the benefits of OO does 
not surprise me.  (BTW, my own choice is one about structuring the software
in terms of polymorphic interfaces)

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Robert C. Martin]

In article <slrn5a9o60.okl.harry@matilda.alt.net.au>,
harry@matilda.alt.net.au (Harry Protoolis) wrote:

> The traditional techniques all suffered from a number of significant
> flaws. Perhaps the most damaging one was what I (rather unkindly) think
> of as 'The glorification of idiots' phenomenon. What I mean by this is
> that projects were typically infested by a group of people who never
> wrote any software, but spent most of the budget drawing diagrams that
> the implementors never used.

Much to my dismay, there are some OO methods that are promoting 
the same scheme.  The "analyst" draw nice pretty little diagrams, and
even run them through simulators to "prove" that they work.  These
diagrams are then run through a program that generates code.  Programmers
who maintain that code generator have to make sure that the "right" code
is generated.  They have to make the program work.

In another case, I have worked with a client who had a bunch of
"architects" doing nothing but drawing pretty Booch diagrams and
then throwing them over the wall to a bunch of programmers.  The
programmers hated the architects and ignored what they produced.

> 
> In fact IMHO an OO team has no place for anyone who cannot do all
> three tasks. [Analysis, Design, and Implementation] 

Agreed, emphatically.

> Jim Coplein wrote an excellent pattern called
> 'Architect also Implements' which covers very nicely the reasoning
> behind not allowing non-implementors to design systems.

Software architects who do not implement will be ignored by the
people who actually *do* implement.  An architect cannot be effective
unless he/she really understands the problems that the implementors
are facing today, now, this minute.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Bill Gooch]

Ell wrote:
> 
> : Bill Gooch wrote:
> : >
> : > Ahmed wrote:
> : > > ....
> : > > Some of these claims for instance
> : > > 1 - high reusability of objects and frameworks
> : >
> : > While this may be claimed about specific frameworks, it is
> : > not IMO a valid generalization about OOT.  [Although] It is feasible
> : > and important to design and implement objects which achieve
> : > immediate *reuse*, general *reusability* is quite rare, and
> : > exceedingly difficult to achieve, IME....
> 
> How about all of the objects that are reusable in PowerBuilder?  Things
> like Window, SQLCA, MLE, SLE, etc. objects which one uses time and time
> again.  Similarly with other frameworks like MFC, where one uses
> CDocument, CDialog, CView etc classes time and time again....

Sure, there are generally reusable thingies out there,
but mostly they are either of a very generic nature (like
dialogs and documents), or they are targeted at a vertical 
niche market.  In either case, the effort to develop them 
is much greater than that required for quality application-
specific code, and their reusability is still limited.  If
you hit their limits, then you have to either extend them
at your own expense, or start from scratch.  This can be a
very painful experience, depending on the circumstances (a
few years ago, I had the misfortune of needing to extend 
Borland's OWL/C++ in Windows 3.1 - what a nightmare!).

The bulk of OO code does not achieve general reusability,
or any reusability at all outside of a very narrow scope.
OTOH, immediate reuse is fairly common (I'd say it's a key
characteristic of quality OO software).  

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: What is wrong with OO ?

[Ahmed]

Bill Gooch wrote:
> 
> Ahmed wrote:
> > ....
> > Object Oriented Technology came with quite promising claims that if achieved can benefit the software
> > development companies and organisations millions of pounds.
> >
> > Some of these claims for instance
> > 1 - high reusability of objects and frameworks
> 
> While this may be claimed about specific frameworks, it is
> not IMO a valid generalization about OOT.  It is feasible
> and important to design and implement objects which achieve
> immediate *reuse*, general *reusability* is quite rare, and
> exceedingly difficult to achieve, IME.  Typically the costs
> outweigh the benefits.
> 
> To be clear what I mean by "immediate reuse" - it is most
> often fine-grained (method and protocol level) reuse of
> behavior via inheritance, delegation, etc. which is readily
> achievable and most important.  Medium-grained (class level)
> reuse is also feasible, although it requires greater design
> effort and foresight (and/or prior experience in the domain).
> Large-grained (framework level) reuse is much harder (I think
> somewhat exponentially with the number of classes/protocols/
> relationships involved), and much more rarely achieved.
> 

Actually immediat reuse can be acheived to a certain extent with
the traditional structural methods if they adopted a good design

What I understand from this is that it is not convinient to reuse
objects of other applications because they are built with different
perspectives..

Does this mean,If two organizations developed almost typical applications
does not mean that the objects developed can be reusable between them..
Is not this a deficiency in OO.
Every programmer is tackling the same problem using his own perception
of the problem..his own abstraction..
The concept behind OO is that it deals with peices of software as
tangible objects exactly as real world works..however in real world
every object has a clear behaviour and perception by every body,
while in the OO software each object has a behaviour according to
the perception of his designer..!!

The problem is that many organization avoid moving toword OO because
the transfter cost to OO ( training programmers / organization change in
standards / new tools / new analysis and design methods / legacy
system/ etc. ) are much higher than the benifit of "immediate reuse"

Another point regarding inheritance, we know that Visiual Basic does not
have the capability of inheritance, however you can build a system
much faster  compared to using visiual C++ with much less code.

I am not saying that we should move to the traditional structural methods
No, I have suffered enough from it, I actually like OO because of its
strong features..But I want to know why it is not moving so fast..
Regardless of the huge amout of push it got by the major players in the 
software
industry..I believe that OO is still not mature enough in certain 
aspects.
and this is what I am trying to find..


Cheers
Ahmed

> 
> --
> William D. Gooch             bill@iconcomp.com
> Icon Computing               http://www.iconcomp.com
> Texas liaison for the International Programmers Guild
> For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "ACQ95AA" == Ahmed  <ACQ95AA@shef.ac.uk> writes:

ACQ95AA> Hello Every Body I am a new research student working at the
ACQ95AA> field of Object Oriented Technology...I have several critical
ACQ95AA> opinions about Object Oriented in general, and I like to
ACQ95AA> participate it with you and hear you expert comments and
ACQ95AA> opinions

ACQ95AA> Object Oriented Technology came with quite promising claims
ACQ95AA> that if achieved can benefit the software development companies
ACQ95AA> and organisations millions of pounds.

ACQ95AA> Some of these claims for instance
ACQ95AA> 1 - high reusability of objects and frameworks

Of objects? What do you mean?

As to ``frameworks'', which I choose to interpret here as ``libraries of
software modules'', there is no guarantee that by using OO one _does_
achieve _high_ reusability; one _can_ achieve _higher_ reusability.

Whether higher reusability _is_ achieved depends on many factors other
than the adoption of OO technology, and whether the reusability achieved
is _high_ depends among other things on the problem domain.

That it is _possible_ to achieve _higher_ reusability with OO than other
approaches is substantiated by some sparse but compelling evidence.

ACQ95AA> 2 - Resilience to change, i.e. low software maintenance and
ACQ95AA> evolution cost

As a _possible_ consequence of _possibly_ _higher_ reuse. Again, there
is some sparse but compelling evidence that this actually happens.

ACQ95AA> 3 - Easier understanding by the user and Natural transition
ACQ95AA> between the analysis, design, implementation because they all
ACQ95AA> use tangible perceived objects.

This is not a claim in OO technology, but in OO speak, in other words it
is purely marketing hype unsubstantiated by any evidence whatsoever. You
won't find any such claim in anything but marketing drivel.

Any such claim, as you write it, is also manifestly absurd: the very
notion of something that is both "tangible perceived" is amusing to say
the least.

ACQ95AA> However the reality is not so bright as claimed..

Indeed, because most all OO-speak salesmen paint a rosy picture as you
describe it above.

OO in and by itself does not magically and necessarily "achieve" the
magic of "high reusability", and in particular because there is no
reason why the use of "tangible perceived objects" should give any
benefit like "Easier understanding by the user".

ACQ95AA> if so, then nobody today thought to develop a software on the
ACQ95AA> traditional structural methods...

Software technologies depend more on sociological than technological
factors. In particular on the twenty-year cycle of induction of new
generations of computer scientists in industry, and their reaching
``manager'' status.

ACQ95AA> My question is what is wrong with OO ? why it did not achieved
ACQ95AA> its targets yet.?  What are the main obstacles?

Inflated expectations? Marketing drivel? Facile abuse of OO-speak?

Thsoe that do practice OO as a technology and not as the promise of the
age of Acquarium in CS find it a very useful concept that does deliver
some measurable benefits.

I find the discussion of OO and other issues in the second edition of
"The Mythical Man Month" a rather good argumentation of some of the
issues involved.

Re: What is wrong with OO ?

[Ahmed]

Harry Protoolis wrote:
> 
> On Tue, 03 Dec 1996 17:38:37 +0000, Ahmed <ACQ95AA@shef.ac.uk> wrote:
> >Hello Every Body

> >Object Oriented Technology came with quite promising claims that if achieved can
> >  benefit the software
> >development companies and organisations millions of pounds.
> >
> >Some of these claims for instance
> >1 - high reusability of objects and frameworks
> >2 - Resilience to change, i.e. low software maintenance and evolution cost
> >3 - Easier understanding by the user and Natural transition between the analysis
> > , design,
> >implementation because they all use tangible perceived objects.
> >
> >However the reality is not so bright as claimed..if so, then nobody today though
> > t to  develop a
> >software on the traditional structural methods...
> >
> >My question is what is wrong with OO ? why it did not achieved its targets yet.?
> >What are the main obstacles?
> 
> I think this is overly negative, OO has not been and never will be a
> 'silver bullet' to solve all software development problems, but no-one
> but a few spin doctors ever claimed it would be.
> 
> However, the real question should be 'has OO made a significant positive
> difference', and in my experience the answer is a resounding 'yes!'.
> 


Dear Harry,
I agree with you that OO has many advantages, but I can not feel that significant improvement
as you said,

The important question is how measure the success of OO,
Can you please tell me on what crieteria you mesured this significant difference
is it
(  code reusibility / software development time / software performace / software reliablity/
software cost / software portablity / ...etc .. ) these issues that count for any organization

actually I am looking for any references that compares " with figures and statistics"
between different applications developped using OO and the traditional methods.

All what I have found are examples that show OO is workable, for me this
is not an evidence to the significant difference"


Another thing, Since you are familiar with OO,
Could you please tell  me what is the best environment to develop an OO application,
( in my case most of our applications are database systems )

Thank you very much 

Regards,
Ahmed

> Cheers,
> Harry
> -
> alt.computer pty ltd                    software development consultants

Re: What is wrong with OO ?

[Roger T.]

Harry Protoolis <harry@matilda.alt.net.au> wrote in article
<slrn5a9o60.okl.harry@matilda.alt.net.au>...
> >My question is what is wrong with OO ? why it did not achieved its
targets yet.?
> >What are the main obstacles? 
> 
> The traditional techniques all suffered from a number of significant
> flaws. Perhaps the most damaging one was what I (rather unkindly) think
> of as 'The glorification of idiots' phenomenon. What I mean by this is
> that projects were typically infested by a group of people who never
> wrote any software, but spent most of the budget drawing diagrams that
> the implementors never used.

I agree with your thesis in general but I would like to point out that the 
the glorification of idiots also included the glorification of those
implementors
that had no use at all for any high level analysis and design efforts.

There are plenty of implementors who could be called idiots for engaging in
what I call "stream of consciousness" coding.

> The main contribution of OO has been was could be termed 'The
> glorification on the implementor'. This has been achieved by the
> effective marriage of Analysis, Design and Implementation. The result
> is that every member of the team does all three of the key tasks.

This is true but the question I wonder about is how much importance and 
therefore time does the implementor invest in the Analysis and Design
parts.

The most important result of OO is that it encourages the implementor to
value 
these development stages more highly than he might otherwise. 

Implementation is the ultimate goal and OO is a means to reach
that goal and also provide a quality product.

> In fact IMHO an OO team has no place for anyone who cannot do all
> three tasks. Jim Coplein wrote an excellent pattern called
> 'Architect also Implements' which covers very nicely the reasoning
> behind not allowing non-implementors to design systems.

Agree.

> Certainly the mecca of automatic reuse has not been achieved, but the
> quantity and quality of 3rd party components available for most OO
> languages already exceeds that available for their non-OO counterparts,
> and IHMO this suggests a bright future.

Agree.

> Certainly OO has not made writing software trivial or automatic, but
> then, *nothing ever will*.

It will make writing some ever-growing subset of software trivial or
automatic 
and free us to attack more difficult coding problems.

Roger T.

Re: What is wrong with OO ?

[Bill Gooch]

Ahmed wrote:
> 
> Actually immediat reuse can be acheived to a certain extent with
> the traditional structural methods if they adopted a good design

A key phrase here is "to a certain extent."  OO allows
more effective reuse (less redundancy, less copy-and-edit)
than alternatives.

> What I understand from this is that it is not convinient to reuse
> objects of other applications because they are built with different
> perspectives..

I think "not convenient" is a bit of an understatement - 
"very difficult" might typically be more accurate.

> Does this mean,If two organizations developed almost typical applications
> does not mean that the objects developed can be reusable between them..
> Is not this a deficiency in OO.

As compared to what?  Non-OO software?  I think not.

Two different automobile designs rarely share any 
compatible parts (except those which are industry-
standardized, like oil filters), unless the designers 
worked together with that goal in mind.

> Every programmer is tackling the same problem using his own perception
> of the problem..his own abstraction..

Yes, and the alternative is?...

> The concept behind OO is that it deals with peices of software as
> tangible objects exactly as real world works..

Not at all.  "How the real world works" is by no means 
obvious or well understood ("real world" in itself is 
an exceedingly vague term), and you'd need to provide 
some definitions of these things, as well as evidence 
to support the above assertion.    

> however in real world
> every object has a clear behaviour and perception by every body,

Not in the slightest. 

> while in the OO software each object has a behaviour according to
> the perception of his designer..!!

Sometimes.  The designer probably hopes it does.

> The problem is that many organization avoid moving toword OO because
> the transfter cost to OO ( training programmers / organization change in
> standards / new tools / new analysis and design methods / legacy
> system/ etc. ) are much higher than the benifit of "immediate reuse"

OK - why is this a problem?

> Another point regarding inheritance, we know that Visiual Basic does not
> have the capability of inheritance, however you can build a system
> much faster  compared to using visiual C++ with much less code.

Depends what system, doesn't it?  VB isn't ideal for
all computer applications; C++ is probably a better 
choice for at least some of them.

> I am not saying that we should move to the traditional structural methods
> No, I have suffered enough from it, I actually like OO because of its
> strong features..But I want to know why it is not moving so fast..

Patience is a virtue.  Rapid growth and early acceptance
can lead to backlash and equally rapid decline. 

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: What is wrong with OO ?

[Dr. Richard Botting]

(Followups trimmed to comp.object and comp.software-eng)
Robert C. Martin (rmartin@oma.com) wrote:
: In another case, I have worked with a client who had a bunch of
: "architects" doing nothing but drawing pretty Booch diagrams and
: then throwing them over the wall to a bunch of programmers.  The
: programmers hated the architects and ignored what they produced.

Software people have four traditional ways of handling any problems:
	(1) ignore it
	(2) invent a tool
	(3) try to be methodical
	(4) define your program to be the solution and standardize it.

OO seems to have inheritted these virtual methods.
(HHOS)

--
dick botting     http://www.csci.csusb.edu/dick/signature.html
Disclaimer:      CSUSB may or may not agree with this message.
Copyright(1996): Copy freely but say where it came from.
	I have nothing to sell, and I'm giving it away.

Re: What is wrong with OO ?

[Joe Winchester]

Harry Protoolis wrote:

> In fact IMHO an OO team has no place for anyone who cannot do all
> three tasks. Jim Coplein wrote an excellent pattern called
> 'Architect also Implements' which covers very nicely the reasoning
> behind not allowing non-implementors to design systems.

Harry,

Do you know where I might be able to get hold of Coplien's pattern.

Regards,

-- 
Joe Winchester
JoeW@concentric.net
103276,233@Compuserve.com

Re: What is wrong with OO ?

[Matthew Gream]

Hi Ahmed,

On Tue, 03 Dec 1996 17:38:37 +0000, Ahmed (ACQ95AA@shef.ac.uk) wrote:

> Object Oriented Technology came with quite promising claims that if
> achieved can benefit the software development companies and
> organisations millions of pounds.

OO is no different from many other technologies. It comes with many
promises, and it can fulfill these if used in the right situations in
the right way. It is not a panacea, which is not a new or surprising
statement.

When you consider "Object Oriented Technology", you must also consider
Domain Analysis, Architecture, Patterns and other lifecycle goodies
which are not inherently Object Oriented, but seem to be a necessary
requirement for successful OO benefits.

> Some of these claims for instance
> 1 - high reusability of objects and frameworks

This can be achieved, but it requires discipline, investment and
experience.  Discpline to work hard towards reusability, and to
maintain that reusability (though evolution). Investment in terms of
the effort involved to establish generic solutions (generic solutions
are generally [:-)] much harder than specific solutions).  Experience
to make the correct decisions when constructing re-usable items (to
have some degree of visibility).

> 2 - Resilience to change, i.e. low software maintenance and evolution cost

How flexible is the software? This has a lot to do with architecture:
"if you don't get the architecture right up front, you may as well pack
up and go home" [quote made by a fellow engineer]. The architecture in
many ways predicts what will happen to the software over its
lifecycle.  If you don't get this right, you will need to change the
architecture: this is usually not a trivial task. This is not exclusively
an OO issue though.

OO includes inheritence. This promotes generalisation -- factoring out
commonalities -- which reduces dependencies. Reduction in dependencies
makes maintenance and evolution more predictable and cheaper. It is
perhaps predictability that is more important than anything, better to
correctly assess that all the costs are high up front, before starting,
rather than finding out later.

There are also CASE tools, which make evolution and maintenance much
easier and achievable (they also keep you focused at a higher level of
logic). Having a CASE tool take care of menial details (file
organisation, includes, class definitions, method stubs, etc) and take
over some of the verification roles (use cases and scenarios) is very
important. Though, CASE tools are not inherently an OO thing.

There are probably many more items you can mention here as well.

> 3 - Easier understanding by the user and Natural transition between the analysis, design, 
> implementation because they all use tangible perceived objects.

The transition is definitely a good thing. Being able to iteratively
build software is much more predictable as well. What you've said seems
to be much easier to say that to do, from the experience I've seen
around me. Getting the right architecture and objects up front requires
experience (and therefore, knowledge). It also requires an appropriate
balance between the actual system requirements, the system domain and
other domains. This requires time and experience. 

> However the reality is not so bright as claimed..if so, then nobody today thought to  develop a
> software on the traditional structural methods...
> My question is what is wrong with OO ? why it did not achieved its targets yet.?
> What are the main obstacles? 

I would say that it is slowely acheiving its targets and that there are
three main inter-related obstacles: time, experience and collaboration.
We need more of these to help the overall feedback loop.

> Is the problem with the immature OO methodologies ( OO analysis and design in specific ) ?
> or is it the deficiency in the development  tools used like C++ or Smalltalk ?
> or is it the steep difference in thinking between the traditional and OO schools ?
> or is it  related with the difficulty of object classification ?
> or is it  because of vast legacy systems done using the traditional methods ?
> or is a combination of many other factors...?

All of these would seem to be problems from my, limited, experience. The
thinking "mindset" is perhaps one of the most important. 

> I know that giving a precise answer is very difficult for such a complex question, but I like to
> hear the comments of people working at the feild and who suffered from many difficulties..

> I would really appreciate any participation, response or even leading to a good reference ,
> and would be very grateful if the opinions are supported by some evidences...

You want evidence ? I need more experience :-). Please excuse my bias
towards architecture in the above as well, I think that architecture
and organisation are very important. Architecture is everywhere, from
the big to the small (in the software, in the process, in the people,
in the organisation, etc). Most of the software problems I have
encountered can be traced back to architectural issues of one form or
another.

Cheers,
Matthew.

--
Email:  Matthew.Gream@Jtec.com.au
Phone:  (02) 390-0194
Fax:    (02) 364-0055
Post:   Jtec (R&D) Pty Ltd. 
        Unit 3, 118-122 Bowden St. 
        Meadowbank NSW 2114.

Re: What is wrong with OO ?

[Marnix Klooster]

tbushell@fox.nstn.ns.ca (Tom Bushell) wrote:

> It is my growing opinion that this is a fundamental problem with all
> "formal" design methods, not just OO design.  The effort involved in
> doing the design is as great or greater than doing the construction
> (coding).  Contrast this with doing the blueprints for a bridge - the
> design effort is orders of magnitude cheaper than the construction.
> (Or so I believe - a civil engineer might correct me on this).  Also,
> the OO design models I've studied don't seem to be very good maps of
> actual real world systems - there seems to be a big gap between high
> level architecture and running code.  I believe there should be a
> fairly smooth continuim from high level to low level of detail.

Couldn't agree with you more.

> I'm starting to believe that design and code don't make sense as
> separate entities - the design should _become_ the code - the design
> documents for an implemented system are used as the foundation of the
> code, and then regenerated from the code.  Major benefits would be
> that design work would not be discarded because it was too difficult
> to bring it up to date with reality.  Therefore, the design should
> never get out of synch.  This a similar idea to reverse engineering,
> but not identical.

One approach in the direction you sketch is the formal method
called the "refinement calculus".  Essentially, a (formal)
specification is considered to be a very high-level
non-executable program, and programming tries to `refine' that
program to an equivalent one that is executable.  The refinement
calculus gives formal proof rules with which refinements can be
proven correct.  Therefore, the side-effect of developing a
program this way is a proof that it meets its specification.  In
other words, we have a `provably correct program.'

> If anyone has knows of tools that would facilitate this approach, I'd
> certainly be interested.  I've done some very simple prototypes, and
> hope to work on the idea in future (when I have more time - Hah!).

Because of the emphasis on proof, the refinement calculus
requires more mathematical skills of the programmer than other
methods.  Also, for larger programs having some kind of proof
support tool is a necessity.  Finally, it often happens that the
specification must be changed halfway.  With proper tool support
it should be easy to check which refinements still hold, and
which don't.  Such tools are under development; try the "Formal
methods" web page at

   http://www.comlab.ox.ac.uk/archive/formal-methods.html

If you want to know more on the refinement calculus, you could
begin with Carroll Morgan, "Programming from Specifications",
Second Edition, Prentice-Hall, 1994, ISBN 0-13-123274-6.

> -Tom

Groetjes,

 <><

Marnix
--
Marnix Klooster        |  If you reply to this post,
marnix@worldonline.nl  |  please send me an e-mail copy.

Re: What is wrong with OO ?

[Tim Ottinger]

Matthew Gream wrote (And all in all, a thoughtful posting):
[in response to question:]
> > 2 - Resilience to change, i.e. low software maintenance and evolution cost
> 
> How flexible is the software? This has a lot to do with architecture:
> "if you don't get the architecture right up front, you may as well pack
> up and go home" [quote made by a fellow engineer]. The architecture in
> many ways predicts what will happen to the software over its
> lifecycle.  If you don't get this right, you will need to change the
> architecture: this is usually not a trivial task. This is not exclusively
> an OO issue though.

By the way, while this is "essentially" right, there are plenty of cases
where people did not build the correct architecture the first time out.
In fact, many of us will tell you that it's nigh impossible to build it
right the first time out if the software project is interesting enough.

The iterative incremental model ain't perfect, but using short cycles
and daring to revisit can cover an awful lot of design sins. If you
commit to an architecture, then you're probably stuck. 

I propose the motto "design by distrust!".  If the work is suitably 
isolated from the physical and business requirements, then you can 
reliably insulate yourself from those things you don't believe will
be invariant, even if you don't know which direction they'll go in.

Of course, this *is* your next point, but I wanted to stress that 
it's not a top-down thing, and the process is not completely 
unforgiving.  Otherwise, we'd be better off outside of OO for large
projects.

The architecture thing, even the business model, can be essentially
right and correctably wrong, and sometimes it's a close to perfection
as you'll get.  Especially early on in a project.

> OO includes inheritence. This promotes generalisation -- factoring out
> commonalities -- which reduces dependencies. Reduction in dependencies
> makes maintenance and evolution more predictable and cheaper. It is
> perhaps predictability that is more important than anything, better to
> correctly assess that all the costs are high up front, before starting,
> rather than finding out later.

Design by distrust! Estimate by distrust!

> > Is the problem with the immature OO methodologies ( OO analysis and design in specific ) ?
> > or is it the deficiency in the development  tools used like C++ or Smalltalk ?
> > or is it the steep difference in thinking between the traditional and OO schools ?
> > or is it  related with the difficulty of object classification ?
> > or is it  because of vast legacy systems done using the traditional methods ?
> > or is a combination of many other factors...?
> 
> All of these would seem to be problems from my, limited, experience. The
> thinking "mindset" is perhaps one of the most important.

To begin with, I don't accept the idea that there is a "problem".
I'll talk about that in a second.

Secondly, I think that the difference in thinking between OO and 
structured is a matter of breaking mental habits, not the deep and
nearly incrossible chasm people make it out to be.  We have people
who jump from COBOL to C++ and OO in one great leap.  We have a 
number of people who came from procedural 4GLs to OO.  It happens
very frequently, maybe every week or every day all over the world
with thousands and thousands of people.

A lot of the "problem" is with organizations.  If they've been
successful
to any degree with other methods (including brute force) then they are 
unlikely to "mess with the formula" by going into OO.  A lot of people
still use Fortranm, COBOL, RPG, etc., successfully - untouched by the
Client/Server revolution, CASE, even RDBMS.  No person or company is 
obliged to stay "technically current", and so many will not.  And they
might do fine at it.

The fact of the matter is that OO is a change in management and project
planning as much as anything else, and a lot of managers aren't too
keen on having their world ripped out from under them.  That's just
an education thing.  It'll come in time, but the focus on managing 
OO is fairly recent in the scheme of things.

There's an underlying myth of the question which was originally asked.
"If method A is good, then why does anybody do anything else", or 
"If some people don't use A, then it must not be very good". 

If I asked "If software is a good career, then why do some people
still raise crops?" you might laugh. Software is not for every-
body.  For that matter, you know that managers and financial people
make more money than programmers, so whats wrong with you that you
don't go into management instead?  Well, maybe programming is fine
for you.  Maybe that money benefit isn't all that important to you.
Does that mean that managers *don't* make more money?

Likewise OO. It's not a winner-take-all battle with the rest 
of the DP world.  It doesn't have to be popular, and it doesn't 
have to be used exclusively by all software companies in order 
to work.

It's just a set of mental tools you can use if you want the
benefits it can provide.  

Some people are gung-ho, some are skeptical, some don't care.  And 
they have that right.

-- 
Tim
******************************************************************** 
 In some sense, all of life is design.  The way we pick our friends, 
 the way we plant a garden, and the way we choose software is all 
 design. Sometimes we do things by habit, other times by carefully 
 weighing the pros and cons, and sometimes we make experiments.  
                                            -- Ralph Johnson --

Re: What is wrong with OO ?

[Russell Corfman]

It's in the proceedings from the PLoP-94 conference. The
proceedings are published by Addison-Wesley in the book
"Pattern Languages of Program Design" edited by
Coplien and Schmidt, ISBN 0-201-60734. Most good book stores
should have it and the PLoPD2 book from PLoP-95.

I believe there is a copy on the web that is reachable
from Coplien's homepage http://www.bell-labs.com/people/cope/
look for "organizational and process patterns"

Russell Corfman
corfmanr@agcs.com

In article <32A65E19.7E68@concentric.net>,
Joe Winchester  <JoeW@concentric.net> wrote:
>Harry Protoolis wrote:
>
>> In fact IMHO an OO team has no place for anyone who cannot do all
>> three tasks. Jim Coplein wrote an excellent pattern called
>> 'Architect also Implements' which covers very nicely the reasoning
>> behind not allowing non-implementors to design systems.
>
>Harry,
>
>Do you know where I might be able to get hold of Coplien's pattern.
>
>Regards,
>
>-- 
>Joe Winchester
>JoeW@concentric.net
>103276,233@Compuserve.com

Re: What is wrong with OO ?

[Bill Gooch]

[followups trimmed]

Ell wrote:
> 
> Bill Gooch (bill@iconcomp.com) wrote:
> : Ahmed wrote:
> : .... 
> : > Every programmer is tackling the same problem using his own perception
> : > of the problem..his own abstraction..
> 
> : Yes, and the alternative is?...
> 
> Relying on domain experts for fundamental application semantics and as
> well relying on domain experts to determine implementation necessaries for
> application use.  

Fair enough.  Also I would have said "sharing explicit
models among all interested parties" to avoid problems
that often arise due to miscommunication (or lack of
comunication).

> Relying on domain experts for implementation of Use Cases.

I'm not sure what "implementation of use cases" means
here - can you explain?  I'm more familiar with the idea 
of software analysts and designers implementing things 
based on what they hear from domain experts and users.

> : > The concept behind OO is that it deals with peices of software as
> : > tangible objects exactly as real world works..
> 
> Yes!  Well not *exactly* as the real world operates, but in a way that
> utilizes, and is anchored upon "real world" domain abstractions,
> patterns, and semantics.
> 
> : Not at all.  "How the real world works" is by no means
> : obvious or well understood ("real world" in itself is
> : an exceedingly vague term), and you'd need to provide
> : some definitions of these things, as well as evidence
> : to support the above assertion.
> 
> If we grasp, as in you have alluded to in many of your previous posts that
> development should start with understanding domain abstractions and
> relationships how is that different from basing project analysis and
> architecture on "tangible objects exactly as the real world operates".

Fine, all except for the quote, which I can't interpret in
a way that I'm comfortable with.  Ill-defined terms combining 
to form what looks to me like total nonsense.  I can't answer
your question, because I don't know what the quote is trying 
to say (your explanation is one of numerous possibilities).

> : > while in the OO software each object has a behaviour according to
> : > the perception of his designer..!!
> 
> : Sometimes.  The designer probably hopes it does.
> 
> Yes, the pragmatists and empiricists hope that they can do whatever they
> want to analysis and physical design based on their narrow inclinations.

If you say so.  (Here I have a strange unpleasant feeling of 
deja vu.)
 
> In actuality there is an objective reality (or at the very least objective
> human conception) behind what goes on in an application and its domain
> that developers should attempt to model as closely as possible.

In actuality that is just one opinion.  I'm curious,
though: what is "objective human conception?"  

> : > The problem is that many organization avoid moving toword OO because
> : > the transfter cost to OO ( training programmers / organization change in
> : > standards / new tools / new analysis and design methods / legacy
> : > system/ etc. ) are much higher than the benifit of "immediate reuse"
> 
> : OK - why is this a problem?
> 
> Because "immediate reuse" should not be the only, or main criteria by
> which an organization adopts one development paradigm or another (e.g. OO
> vs. others), as I see it....

Good.  What in your opinion are some other important criteria?

Actually my question was more about why it matters in general
whether or not "many organizations avoid moving toward OO."  
But I like your answer, even if it's responding to a slightly 
different question.

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: What is wrong with OO ?

[Bill Gooch]

Brian Gridley wrote:
> 
[ Ahmed wrote: ]
> >: > Every programmer is tackling the same problem using his own perception
> >: > of the problem..his own abstraction..
> >
[ Bill Gooch wrote: ]
> >: Yes, and the alternative is?...
> >
> Communication, teams, and a development environment 2 steps beyond ENVY.

Good.  Can you say a bit more about this?

> If all the code that has been written in various shops became available to the
> general developing public within 3 months of it's creation, we would have spent
> far less time repeating ourselves, and have the most robust development
> environment and reuseable code, and have eliminated all other language
> competitors (not ST-based).

I don't think so (especially about the part in parens, 
since Smalltalk environments aren't clearly superior 
to all others - superior to most, yes). 

> Instead, we are still all solving the same problems
> , over and over again.  Is anyone interested in building a communal repository
> with a system for charging users and rewarding developers for code?

We're working on it.  Stay tuned.

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: What is wrong with OO ?

[Daniel Drasin]

Ahmed wrote:
> 
> Hello Every Body
> 
> I am a new  research student working at the field of Object Oriented Technology...I have several
> critical opinions about Object Oriented in general, and I like to participate it with you and hear
> you expert comments and opinions
> 
> Object Oriented Technology came with quite promising claims that if achieved can benefit the software
> development companies and organisations millions of pounds.
> 
> Some of these claims for instance
> 1 - high reusability of objects and frameworks
> 2 - Resilience to change, i.e. low software maintenance and evolution cost
> 3 - Easier understanding by the user and Natural transition between the analysis, design,
> implementation because they all use tangible perceived objects.
> 
> However the reality is not so bright as claimed..if so, then nobody today thought to  develop a
> software on the traditional structural methods...
> 
> My question is what is wrong with OO ? why it did not achieved its targets yet.?
> What are the main obstacles?
> 
My $0.02.

The problems I've seen with OO projects arise not from the use of OO,
but from the misuse of OO.  Programmers trying to use non-OO methods,
incorrectly applying OO concepts, etc.  This is a result of a lack of
OO teaching at eductational institutions.  Even schools that offer 
1 or 2 OO language courses usually fail to educate; they use C++
and only really teach the "C" part.  There are very few
universities that make an effort to inculcate students with an
understanding of OO techiniques and methods.  So it's no wonder
when these graduates try to apply them in the "real world," they
get all fouled up.

Dan

-- 
	Daniel Drasin			Applied Reasoning 
	drasin@arscorp.com		2840 Plaza Place, Suite 325
	(919)-781-7997			Raleigh, NC  27612
	http://www.arscorp.com

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "tbushell" == Tom Bushell <tbushell@fox.nstn.ns.ca> writes:

tbushell> On Wed, 04 Dec 1996 08:45:22 -0600, rmartin@oma.com (Robert
tbushell> C. Martin)
wrote> 

>> harry@matilda.alt.net.au (Harry Protoolis) wrote:

harry> The traditional techniques all suffered from a number of
harry> significant flaws. Perhaps the most damaging one was what I
harry> (rather unkindly) think of as 'The glorification of idiots'
harry> phenomenon. What I mean by this is that projects were typically
harry> infested by a group of people who never wrote any software, but
harry> spent most of the budget drawing diagrams that the implementors
harry> never used.

But such people are not at all idiots: they are usually the cleverest
people on the project, from many points of view, especially
self-interest. :-)

rmartin> Much to my dismay, there are some OO methods that are promoting
rmartin> the same scheme.  The "analyst" draw nice pretty little
rmartin> diagrams, and even run them through simulators to "prove" that
rmartin> they work.  These diagrams are then run through a program that
rmartin> generates code.  Programmers who maintain that code generator
rmartin> have to make sure that the "right" code is generated.  They
rmartin> have to make the program work.

Both of these observations seem to me rather realistic, from direct and
indirect observation of actual projects.

tbushell> It is my growing opinion that this is a fundamental problem
tbushell> with all "formal" design methods, not just OO design.

This is in part what has made formal methods (as in correctness
proofs/verification) rather less popular than perhaps they should be:
the ``formal'' bit is as large as, and usually as unreliable as, the
``informal'' bit of a project (getting a specification or a proof right
is often about as hard, and sometimes harder, as getting the program
itself right)

tbushell> The effort involved in doing the design is as great or greater
tbushell> than doing the construction (coding).

That's quite well often the case -- now, if the design was _useful_,
then that would not be a problem. Unfortunately analisyses or designs
are often rather dramatically decoupled from each other and
implementation, for both technical and sociological (for example inane
adherence to the waterfall model) reasons, and so that effort is usually
largely wasted.

*If* analisys and design efforts were conducted in resonance with each
other and implementation, then spending more effort on those than coding
would be all fine and actually rather useful, for formulating solutions
in more abstract terms usually makes them easier to maintain and modify.

tbushell> Contrast this with doing the blueprints for a bridge - the
tbushell> design effort is orders of magnitude cheaper than the
tbushell> construction.  (Or so I believe - a civil engineer might
tbushell> correct me on this).

It is usually _cheaper_, but on the other hand it might take _longer_.

Developing and then ``debugging'' a bridge design is a long and
difficult process, that involves a large number of considerations in
different fields, from economics to demographics to aestetics.

tbushell> Also, the OO design models I've studied don't seem to be very
tbushell> good maps of actual real world systems - there seems to be a
tbushell> big gap between high level architecture and running code.  I
tbushell> believe there should be a fairly smooth continuim from high
tbushell> level to low level of detail.

Why?

tbushell> I'm starting to believe that design and code don't make sense
tbushell> as separate entities - the design should _become_ the code -
tbushell> the design documents for an implemented system are used as the
tbushell> foundation of the code, and then regenerated from the code.
tbushell> Major benefits would be that design work would not be
tbushell> discarded because it was too difficult to bring it up to date
tbushell> with reality.  Therefore, the design should never get out of
tbushell> synch.  This a similar idea to reverse engineering, but not
tbushell> identical.

This seems a bit fuzzy as a description, but reminds me of the
``corroboration'' approach from Dijkstra to program correctness: if one
develops programs using methodical techniques _starting_ from their
``proof'', then the correctness of the program is highly corroborated by
such a process.

tbushell> If anyone has knows of tools that would facilitate this
tbushell> approach, I'd certainly be interested.  I've done some very
tbushell> simple prototypes, and hope to work on the idea in future
tbushell> (when I have more time - Hah!).

But OO is in large part about this: the ``high level''
modules/classes/prototypes are supposed to capture the essence of the
design. Pointing some sort of OO program browser to a program source and
removing from the picture the lower levels of abstraction *ought* to
reveal the design. This *ought* to be the case with structured
programming methods in general, and with OO in particular it should be
even more pleasant because of the disciplined modularization of the
program it entails.

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "rmartin" == Robert C Martin <rmartin@oma.com> writes:

[ ... ]

harry> In fact IMHO an OO team has no place for anyone who cannot do all
harry> three tasks. [Analysis, Design, and Implementation]

rmartin> Agreed, emphatically.

As much as I agree ith these wise words, that clearly arise out of a
solid amount of experience with the ``alternative'', I have to sadly add
here that sociological reasons make the ``alternative'' rather common;
career stratification, 

harry> Jim Coplien wrote an excellent pattern called 'Architect also
harry> Implements' which covers very nicely the reasoning behind not
harry> allowing non-implementors to design systems.

rmartin> Software architects who do not implement will be ignored by the
rmartin> people who actually *do* implement.  An architect cannot be
rmartin> effective unless he/she really understands the problems that
rmartin> the implementors are facing today, now, this minute.

I know both you and Harry already know this, but let me add for the sake
of completeness and of the record (and Ell :->): and viceversa!

Architecture, as you have so many times argued, is extremely important,
and the implementor that is not guided by sound architectural
principles, by close interaction with analisys and design, is not going
to do a nice implementation.

Which of course brings us back to the observation above: that
programming, and in particular OO with its great emphasis on structured,
modular, abstraction, requires the ability to understand and perform at
all three levels of discourse.

Re: What is wrong with OO ?

[Nick Thurn]

IMO asking "what is wrong with OO?" is a bit like asking "what is wrong with
a hammer?"

My point is OO is only a tool. The user of a tool is fundamental to the results.
IMO if anything is wrong with OO it is inflated expectations. In the end
it is people who create software. Good people create good software in any
language/paradigm. Good OO looks deceptivly simple. Attaining simplicity is
the hard part. I think of it as the difference between whistling a tune and
writing a tune. Currently there are to many writers and not enough whistlers :)

Regarding reuse and reusability, there are two levels of reuse: personal and
strangers. Personal (including your team) reuse is pretty easy
to achieve, reuse by strangers is hard. Reusable is in the eye of the reuser
not the writer. All a writer can do is *attempt* to create reusable code it
is for others to decide whether it is reusable or not. 

In C++ land the biggest barrier to reuse has been the proliferation of 
proprietry container librarys (usually as part of a more high level
set of functionality). With the standard basically here this problem
may go away. We still have the problem that most (probably all) mature
librarys are written in legacy C++, when will they port across? when
will compilers be available that handle all the new features? when will
there be a standard ABI?

IMO OO is a great tool, if it is flawed it is the execution not the concept.
Oh well, back to the salt mines...

cheers
Nick (my opinions only)

Re: What is wrong with OO ?

[Tom Bushell]

On Wed, 04 Dec 1996 08:45:22 -0600, rmartin@oma.com (Robert C. Martin)
wrote:

>harry@matilda.alt.net.au (Harry Protoolis) wrote:
>
>> The traditional techniques all suffered from a number of significant
>> flaws. Perhaps the most damaging one was what I (rather unkindly) think
>> of as 'The glorification of idiots' phenomenon. What I mean by this is
>> that projects were typically infested by a group of people who never
>> wrote any software, but spent most of the budget drawing diagrams that
>> the implementors never used.
>
>Much to my dismay, there are some OO methods that are promoting 
>the same scheme.  The "analyst" draw nice pretty little diagrams, and
>even run them through simulators to "prove" that they work.  These
>diagrams are then run through a program that generates code.  Programmers
>who maintain that code generator have to make sure that the "right" code
>is generated.  They have to make the program work.

It is my growing opinion that this is a fundamental problem with all
"formal" design methods, not just OO design.  The effort involved in
doing the design is as great or greater than doing the construction
(coding).  Contrast this with doing the blueprints for a bridge - the
design effort is orders of magnitude cheaper than the construction.
(Or so I believe - a civil engineer might correct me on this).  Also,
the OO design models I've studied don't seem to be very good maps of
actual real world systems - there seems to be a big gap between high
level architecture and running code.  I believe there should be a
fairly smooth continuim from high level to low level of detail.

I'm starting to believe that design and code don't make sense as
separate entities - the design should _become_ the code - the design
documents for an implemented system are used as the foundation of the
code, and then regenerated from the code.  Major benefits would be
that design work would not be discarded because it was too difficult
to bring it up to date with reality.  Therefore, the design should
never get out of synch.  This a similar idea to reverse engineering,
but not identical.

If anyone has knows of tools that would facilitate this approach, I'd
certainly be interested.  I've done some very simple prototypes, and
hope to work on the idea in future (when I have more time - Hah!).

-Tom



----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Ell]

Bill Gooch (bill@iconcomp.com) wrote:
: Ahmed wrote:
: > 
: > Actually immediat reuse can be acheived to a certain extent with
: > the traditional structural methods if they adopted a good design
 
: A key phrase here is "to a certain extent."  OO allows
: more effective reuse (less redundancy, less copy-and-edit)
: than alternatives.
 
: > What I understand from this is that it is not convinient to reuse
: > objects of other applications because they are built with different
: > perspectives..
 
: I think "not convenient" is a bit of an understatement - 
: "very difficult" might typically be more accurate.

In my experience, and observations, it is not "cross application"  reuse
of classes/objects that is a problem as much as it is "cross environment"
reuse of classes/objects.  Especially wrt physical design reuse.  I.e.
getting classes/objects to physically work across different environments
is difficult indeed.
 
: Two different automobile designs rarely share any 
: compatible parts (except those which are industry-
: standardized, like oil filters), unless the designers 
: worked together with that goal in mind.
 
: > Every programmer is tackling the same problem using his own perception
: > of the problem..his own abstraction..
 
: Yes, and the alternative is?...

Relying on domain experts for fundamental application semantics and as
well relying on domain experts to determine implementation necessaries for
application use.  Relying on domain experts for implementation of Use
Cases.

: > The concept behind OO is that it deals with peices of software as
: > tangible objects exactly as real world works..

Yes!  Well not *exactly* as the real world operates, but in a way that
utilizes, and is anchored upon "real world" domain abstractions,
patterns, and semantics.
 
: Not at all.  "How the real world works" is by no means 
: obvious or well understood ("real world" in itself is 
: an exceedingly vague term), and you'd need to provide 
: some definitions of these things, as well as evidence 
: to support the above assertion.    

If we grasp, as in you have alluded to in many of your previous posts that
development should start with understanding domain abstractions and
relationships how is that different from basing project analysis and
architecture on "tangible objects exactly as the real world operates".

: > however in real world
: > every object has a clear behaviour and perception by every body,
 
: Not in the slightest. 

The perception of object behavior ranges in various cases between being
very clear to all to only discernable to a handful.

: > while in the OO software each object has a behaviour according to
: > the perception of his designer..!!
 
: Sometimes.  The designer probably hopes it does.

Yes, the pragmatists and empiricists hope that they can do whatever they
want to analysis and physical design based on their narrow inclinations.

In actuality there is an objective reality (or at the very least objective
human conception) behind what goes on in an application and its domain
that developers should attempt to model as closely as possible. 

: > The problem is that many organization avoid moving toword OO because
: > the transfter cost to OO ( training programmers / organization change in
: > standards / new tools / new analysis and design methods / legacy
: > system/ etc. ) are much higher than the benifit of "immediate reuse"
 
: OK - why is this a problem?

Because "immediate reuse" should not be the only, or main criteria by
which an organization adopts one development paradigm or another (e.g. OO
vs. others), as I see it.
 
: > I am not saying that we should move to the traditional structural methods
: > No, I have suffered enough from it, I actually like OO because of its
: > strong features..But I want to know why it is not moving so fast..

Seems pretty fast to me.  From what I read in most literature in the
computer field, or area, OO is de rigeur - virtually the only thing being
talked about as a development paradigm.  That is even in the mainframe
world.
 
: Patience is a virtue.  Rapid growth and early acceptance
: can lead to backlash and equally rapid decline. 

Excelsior!  As quickly as possible!  OO has at least nearly 30 years of
growth.

Elliott

Re: What is wrong with OO ?

[Ell]

Tom Bushell (tbushell@fox.nstn.ns.ca) wrote:
: rmartin@oma.com (Robert C. Martin) wrote:
: >
: >harry@matilda.alt.net.au (Harry Protoolis) wrote:
: >>
: >> The traditional techniques all suffered from a number of significant
: >> flaws. Perhaps the most damaging one was what I (rather unkindly) think
: >> of as 'The glorification of idiots' phenomenon. What I mean by this is
: >> that projects were typically infested by a group of people who never
: >> wrote any software, but spent most of the budget drawing diagrams that
: >> the implementors never used.

: >Much to my dismay, there are some OO methods that are promoting 
: >the same scheme.  The "analyst" draw nice pretty little diagrams, and
: >even run them through simulators to "prove" that they work.  These
: >diagrams are then run through a program that generates code.  Programmers
: >who maintain that code generator have to make sure that the "right" code
: >is generated.  They have to make the program work.
 
: It is my growing opinion that this is a fundamental problem with all
: "formal" design methods, not just OO design.  The effort involved in
: doing the design is as great or greater than doing the construction
: (coding).  

Even if "doing" good OO analysis (drawing "nice pretty little diagram" and
*much* more) cost more time and dollars than OO coding, it pays off
because doing good OO analysis is generally decisive to the most rapid and
Use Case effective development of the project. 

: I'm starting to believe that design and code don't make sense as
: separate entities - the design should _become_ the code - the design
: documents for an implemented system are used as the foundation of the
: code, and then regenerated from the code.  

And if you think about it, the only real way for what you call "design" to
"become" the code is if a perspective larger than being mainly focused on
physical coding *leads* physical coding.

: Major benefits would be
: that design work would not be discarded because it was too difficult
: to bring it up to date with reality.  Therefore, the design should
: never get out of synch.

This is precisely the approach of Booch/Coad/Jacobson/Rumbaugh from what I
know about their methods.  Physical design and coding is based on/rooted
in analysis concepts.  Physical design and coding are simply additive to
the analysis models.

Elliott

Re: What is wrong with OO ?

[Brian Gridley]

>: > Every programmer is tackling the same problem using his own perception
>: > of the problem..his own abstraction..
> 
>: Yes, and the alternative is?...
>
Communication, teams, and a development environment 2 steps beyond ENVY.

If all the code that has been written in various shops became available to the 
general developing public within 3 months of it's creation, we would have spent 
far less time repeating ourselves, and have the most robust development 
environment and reuseable code, and have eliminated all other language 
competitors (not ST-based). Instead, we are still all solving the same problems 
, over and over again.  Is anyone interested in building a communal repository 
with a system for charging users and rewarding developers for code?

Re: What is wrong with OO ?

[Thomas Gagne]

Computer technology is treated little differently by the media than
politics, medicine, and/or consumer safety issues.  Basically, most
pundits make their living exploiting the Chicken Little model.  Those
with soft, impressionable minds believe what the read simply because
they read it.

Truth is, there's nothing wroing with OOT.  There's nothing wrong with
client-server.  But the reporting of the short comings and demises is
premature and irresponsible.  There will always be high-profile
projects  using the technology de'jour that fail for reasons other than
the short comings of the technology.

Whether your technology is assembler, C, RDBMS, Smalltalk, distributed
processing, or whatever, it can be sabotaged by;
	mismanagement
	inexperienced developers (in the technology)
	poorly managed customer expectations
	poorly trained users
	poor documentation
	did I mention mismanagement?
None of these incriminates technology.  All of these afflictions exist
independent of the technology employed.  Addmittedly, I have been a part
of projects that have (euphemistically) missed their objectives more
because of the misuse of technology than the fault of it.

Take for instance the many hurled afronts to RDBMS as being slow.  I
still regularly read and hear of supposedly credible experts
recommending denormalization as a way of overcoming performance 
problems.  I've discovered the problem isn't with your engine, its how
you're using it.  Have you tried using multiple connections executing
parallel queries to eliminate join processing?  If that sounds to
difficult, maybe you should get a systems programmer to develop a
three-tier system for you so the more complex programming can be hidden
in a middle-tier (possibly where it belongs?) rather than in your
application.

People who have been a part of varied programming teams have often
learned that good programmers program well in any language.  Bad
programmers program poorly in any language.

It's time to stop blaming the technology and get with the program.  As
the adage says, "Those who say it can't be done should get out of the
way of those doing it."

Re: What is wrong with OO ?

[Ell]

Tom Bushell (tbushell@fox.nstn.ns.ca) wrote:
:
: Robert C. Martin wrote:
: 
: >Harry Protoolis wrote:
: >
: >> The traditional techniques all suffered from a number of significant
: >> flaws. Perhaps the most damaging one was what I (rather unkindly) think
: >> of as 'The glorification of idiots' phenomenon. What I mean by this is
: >> that projects were typically infested by a group of people who never
: >> wrote any software, but spent most of the budget drawing diagrams that
: >> the implementors never used.

So then we had the elevation of self-centered hackers, eh?  Not that all
such plans were good, but the coders should be following some
architectural plan 95% of the time.

: >Much to my dismay, there are some OO methods that are promoting 
: >the same scheme.  The "analyst" draw nice pretty little diagrams, and
: >even run them through simulators to "prove" that they work.  These
: >diagrams are then run through a program that generates code.  Programmers
: >who maintain that code generator have to make sure that the "right" code
: >is generated.  They have to make the program work.

Are you saying that iterative and incremenatl diagrams are always wrong or
that the code generator has problems?  Or both? 
 
: It is my growing opinion that this is a fundamental problem with all
: "formal" design methods, not just OO design.  The effort involved in
: doing the design is as great or greater than doing the construction
: (coding).  Contrast this with doing the blueprints for a bridge - the
: design effort is orders of magnitude cheaper than the construction.

This to me only shows that building software and building bridges are 2
different kinds of building activity.  It does not impugn the efficacy of
determining sw project analysis and formulating a project architecture.

: (Or so I believe - a civil engineer might correct me on this).  Also,
: the OO design models I've studied don't seem to be very good maps of
: actual real world systems - there seems to be a big gap between high
: level architecture and running code.  I believe there should be a
: fairly smooth continuim from high level to low level of detail.

This is precisely what the 3 amigos and other OO gurus advocate in
their works.
 
: I'm starting to believe that design and code don't make sense as
: separate entities - the design should _become_ the code - the design
: documents for an implemented system are used as the foundation of the
: code, and then regenerated from the code.  Major benefits would be
: that design work would not be discarded because it was too difficult
: to bring it up to date with reality.  Therefore, the design should
: never get out of synch.  This a similar idea to reverse engineering,
: but not identical.

Ditto my last remark.

Cheers,

Elliott

Re: What is wrong with OO ?

[Ell]

Richie Bielak (richieb@calfp.com) wrote:
: Matthew Gream wrote:
: 
: [...]
: 
: > How flexible is the software? This has a lot to do with architecture:
: > "if you don't get the architecture right up front, you may as well pack
: > up and go home" [quote made by a fellow engineer]. 
 
: These kinds of statements always bother me. How are you supposed to
: know that the architecture (or design for that matter) is right?
: 
: The only way I see is to implement it and see how it works. That's
: why the iterative software development makes sense, you get to try
: out out your ideas in practice and adjust them as needed.

The point as far as I'm concerned is that an architecture should guide
_all_ coding.  That is even if the initial architecture is later modified,
or later scrapped. 

Elliott

Re: What is wrong with OO ?

[Tom Bushell]

On 5 Dec 1996 03:56:02 GMT, ell@access2.digex.net (Ell) wrote:

>Even if "doing" good OO analysis (drawing "nice pretty little diagram" and
>*much* more) cost more time and dollars than OO coding, it pays off
>because doing good OO analysis is generally decisive to the most rapid and
>Use Case effective development of the project. 

I agree that formal high level design _should_ pay off, but there is
ample anecdotal (as provided by other contributers to this thread)
that it doesn't always.  Some might argue that this is because the
design process wasn't "good", but I wonder if this is just a symptom
of a deeper problem with formal design as it is currently practiced.
We seem to be modelling the civil engineers - draw the blueprints,
then build the bridge, and correct the blueprints "as built".  But
software is bits, not atoms, and there may be better approaches.


>And if you think about it, the only real way for what you call "design" to
>"become" the code is if a perspective larger than being mainly focused on
>physical coding *leads* physical coding.

Agreed.  I picture the design activity as creating some form of
outlines and diagrams, which would be successively refined down to the
level of running code.  But you could "back up" (zoom out?) to the
higher levels of abstraction at any point in the development (or
maintenance) process.

>This is precisely the approach of Booch/Coad/Jacobson/Rumbaugh from what I
>know about their methods.  Physical design and coding is based on/rooted
>in analysis concepts.  Physical design and coding are simply additive to
>the analysis models.

I speak only from knowledge gleaned from magazine articles, but my
understanding is that the tools are lacking to provide the outline
style views I'm looking for, with the possible exception of
Together/C++.

IMO, most of these well known methods focus on the wrong things.
There seems to be far too much emphasis on inheritance relationships,
which is not extremely useful in my experience.  I'd be much more
interested in tools that allowed me to work with dataflow and side
effects on persistant data - at various levels of abstraction.

-Tom



----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Jeff Miller]

Bill Gooch wrote:
> 
> Ahmed wrote:
> >
> > Actually immediat reuse can be acheived to a certain extent with
> > the traditional structural methods if they adopted a good design
> 
> A key phrase here is "to a certain extent."  OO allows
> more effective reuse (less redundancy, less copy-and-edit)
> than alternatives.

This reminds me of a thread we had on the comp.lang.c++ ng a couple
of years ago.

I maintained then, and continue to maintain, that the extent to
which OO tools incrementally promote reuse (C++ as compared to C,
to draw an obvious example) is not in and of itself sufficient to
have any meaningful impact in any large organization.

Effective reuse is substantially a management issue, not a technical
one. OO helps, but organizational and process changes are more
important.

                                             Jeff Miller
                                             Senior Server Architect
                                             CSG Systems, Inc.
                                             jeff_miller@csgsys.com
                                             jmiller@probe.net

Re: What is wrong with OO ?

[Carl Weidling]

In article <32a5ceba.81462731@news.nstn.ca>,
Tom Bushell <tbushell@fox.nstn.ns.ca> wrote:
>On Wed, 04 Dec 1996 08:45:22 -0600, rmartin@oma.com (Robert C. Martin)
>wrote:
>
>>harry@matilda.alt.net.au (Harry Protoolis) wrote:
>>
>>> The traditional techniques all suffered from a number of significant
>>> flaws. Perhaps the most damaging one was what I (rather unkindly) think
>>> of as 'The glorification of idiots' phenomenon. What I mean by this is
>>> that projects were typically infested by a group of people who never
>>> wrote any software, but spent most of the budget drawing diagrams that
>>> the implementors never used.
>>
...<stuff deleted for brevity -cpw>
>
>It is my growing opinion that this is a fundamental problem with all
>"formal" design methods, not just OO design.  The effort involved in
>doing the design is as great or greater than doing the construction
>(coding).  Contrast this with doing the blueprints for a bridge - the
>design effort is orders of magnitude cheaper than the construction.
...<more stuff deleted>
>I'm starting to believe that design and code don't make sense as
>separate entities - the design should _become_ the code - the design
>documents for an implemented system are used as the foundation of the
...<rest of previous posting deleted>
	I remember seeing a documentary about Gothic Cathedrals as
examples of engineering.  The commentary compared the way models are
constructed first nowadays to test a design, and they showed models of
cathedrals going through stress tests, but for those medieval masons,
the building was also the engineering model.  The flying buttresses for
instance, were added when the masons saw how wind was blowing down the walls.
	On the other hand, wasn't there a famous example back in the 70s
when 'top-level design' was first being expounded, where some big project
for a newspaper or something was designed first and then coded and it worked.
I remember this being cited a lot when I first started programming, can
anyone recall details or hard facts about that?
-- 
Cleave yourself to logodedaly and you cleave yourself from clarity.

Re: What is wrong with OO ?

[Harry Protoolis]

On Thu, 05 Dec 1996 03:06:57 GMT, Tom Bushell <tbushell@fox.nstn.ns.ca> wrote:
>On Wed, 04 Dec 1996 08:45:22 -0600, rmartin@oma.com (Robert C. Martin)
>wrote:
>
>>harry@matilda.alt.net.au (Harry Protoolis) wrote:
>>
>>> The traditional techniques all suffered from a number of significant
>>> flaws. Perhaps the most damaging one was what I (rather unkindly) think
>>> of as 'The glorification of idiots' phenomenon. What I mean by this is
>>> that projects were typically infested by a group of people who never
>>> wrote any software, but spent most of the budget drawing diagrams that
>>> the implementors never used.
>>
>>Much to my dismay, there are some OO methods that are promoting 
>>the same scheme.  The "analyst" draw nice pretty little diagrams, and
>>even run them through simulators to "prove" that they work.  These
>>diagrams are then run through a program that generates code.  Programmers
>>who maintain that code generator have to make sure that the "right" code
>>is generated.  They have to make the program work.
>
>It is my growing opinion that this is a fundamental problem with all
>"formal" design methods, not just OO design.  The effort involved in
>doing the design is as great or greater than doing the construction
>(coding).  Contrast this with doing the blueprints for a bridge - the
>design effort is orders of magnitude cheaper than the construction.
>(Or so I believe - a civil engineer might correct me on this).  Also,
>the OO design models I've studied don't seem to be very good maps of
>actual real world systems - there seems to be a big gap between high
>level architecture and running code.  I believe there should be a
>fairly smooth continuim from high level to low level of detail.

IMHO, the trick with OO design is to do it *informally* most of the
time. What I mean by this is that you sketch out high level architecture
and analysis results as high level class diagrams and then give them to
the 'implementors' to design and code.

The implementation team then does design as a series of informal
gatherings around a white board drawing state diagrams, detailed class
diagrams, object diagrams etc. You then photocopy and file the
whiteboard drawings and let the same group of people code from the
hand drawn design.

I then quite often reverse-engineer the resulting code and call *that*
the formal system design.

I do some formal tracking of this design process, but the golden rule is
that nothing should get in the way of the creative process. The failure
of *all* attempts at formal design is this mistaken belief that anything
short of coding can replace coding ... 

>I'm starting to believe that design and code don't make sense as
>separate entities - the design should _become_ the code - the design
>documents for an implemented system are used as the foundation of the
>code, and then regenerated from the code.  Major benefits would be
>that design work would not be discarded because it was too difficult
>to bring it up to date with reality.  Therefore, the design should
>never get out of synch.  This a similar idea to reverse engineering,
>but not identical.

My point is that the *design* and the *code* come into existance
together. To talk about the design becoming the code implies that it
exists before the code in some sense.

>If anyone has knows of tools that would facilitate this approach, I'd
>certainly be interested.  I've done some very simple prototypes, and
>hope to work on the idea in future (when I have more time - Hah!).

I think that a facinating tool would be a language sensitive drawing
tool in which you could switch your view between diagrams and code and
write 'code' in either view.

H
-
Harry Protoolis                              alt.computer pty ltd                 
harry@alt.net.au                             software development consultants

Re: What is wrong with OO ?

[Harry Protoolis]

On 6 Dec 1996 02:12:33 GMT, Ell <ell@access5.digex.net> wrote:
>Tom Bushell (tbushell@fox.nstn.ns.ca) wrote:
>:
>: Robert C. Martin wrote:
>: 
>: >Harry Protoolis wrote:
>: >
>: >> The traditional techniques all suffered from a number of significant
>: >> flaws. Perhaps the most damaging one was what I (rather unkindly) think
>: >> of as 'The glorification of idiots' phenomenon. What I mean by this is
>: >> that projects were typically infested by a group of people who never
>: >> wrote any software, but spent most of the budget drawing diagrams that
>: >> the implementors never used.
>
>So then we had the elevation of self-centered hackers, eh?  Not that all
>such plans were good, but the coders should be following some
>architectural plan 95% of the time.

I suppose I started the name-calling, so I can't complain can I :-)

In any event, that is not what I am advocating at all. What I am
suggesting is that OO techinques *can* be sold to implementors, because
good OO design *does* map to meaningful implementations. (unlike, IMHO,
any form of traditional structured design)

As a result, IME, you can convince your implementors to do design
themselves. This has the multiple benefits of getting better, more
meaninful designs done, *and* not getting them ignored.

If you then involve *the same group of people* in the up front problem
analysis you get a win-win-win scenario, as they are now basing
implementable designs on analysis results in which they have a stake.

This is the beauty of 'Architect-also-implements', the chief architect
can lead all three components of the process with some credibility, and
can handle the most awful of all questions asked to a 'pure' Analyst,
namely 'How the hell do I implement this ?', and avoid the most soul
destroying (and project killing) of all answers ...

'I don't care, that's just an implementation problem'.

H

p.s. Elliot, your newsreader is (still) badly broken, all your postings are
     appearing out of sync in their respective threads. Are you using
     'Followup' to respond to postings ?

-
Harry Protoolis                              alt.computer pty ltd                 
harry@alt.net.au                             software development consultants

Re: What is wrong with OO ?

[Harry Protoolis]

On 6 Dec 1996 03:26:57 GMT, Ell <ell@access4.digex.net> wrote:
>Richie Bielak (richieb@calfp.com) wrote:
>: Matthew Gream wrote:
>: 
>: [...]
>: 
>: > How flexible is the software? This has a lot to do with architecture:
>: > "if you don't get the architecture right up front, you may as well pack
>: > up and go home" [quote made by a fellow engineer]. 
> 
>: These kinds of statements always bother me. How are you supposed to
>: know that the architecture (or design for that matter) is right?
>: 
>: The only way I see is to implement it and see how it works. That's
>: why the iterative software development makes sense, you get to try
>: out out your ideas in practice and adjust them as needed.
>
>The point as far as I'm concerned is that an architecture should guide
>_all_ coding.  That is even if the initial architecture is later modified,
>or later scrapped. 

Despite being a 'self centered hacker' (I like that title :-)) I
actually agree with you Elliot. You should at least sketch your
architecture out after your analysis is complete, (where analysis ==
primary use cases), and design to it.

The possibility of being wildly wrong in your first cut at architecture
is no excuse for not trying, after all if you are right then you win and
if you are wrong then at least you have something to iterate on.

H
-
Harry Protoolis                              alt.computer pty ltd                 
harry@alt.net.au                             software development consultants

Re: What is wrong with OO ?

[Tom Bushell]

On 05 Dec 1996 22:30:40 +0000, pcg@aber.ac.uk (Piercarlo Grandi)
wrote:

>*If* analisys and design efforts were conducted in resonance with each
>other and implementation, then spending more effort on those than coding
>would be all fine and actually rather useful, 

I agree that the effort is useful.  But my gut feeling is that with
better (and apparently undiscovered, as yet) processes and tools, the
high level design activity should be about 10% of the total project,
not around 50%.

>tbushell> Contrast this with doing the blueprints for a bridge - the
>tbushell> design effort is orders of magnitude cheaper than the
>tbushell> construction.  (Or so I believe - a civil engineer might
>tbushell> correct me on this).
>
>It is usually _cheaper_, but on the other hand it might take _longer_.

I assume this is because the design is the work of a much smaller
team, whose only physical output is computer models or paper.  This is
my point - other engineering disciplines appear to routinely put much
less total effort into design, with much greater success.  I guess
this is just the positive result of greater maturity as a discipline.

>tbushell> Also, the OO design models I've studied don't seem to be very
>tbushell> good maps of actual real world systems - there seems to be a
>tbushell> big gap between high level architecture and running code.  I
>tbushell> believe there should be a fairly smooth continuim from high
>tbushell> level to low level of detail.
>
>Why?

Why not? ;-) (Don't know what you're asking here...)

>But OO is in large part about this: the ``high level''
>modules/classes/prototypes are supposed to capture the essence of the
>design. Pointing some sort of OO program browser to a program source and
>removing from the picture the lower levels of abstraction *ought* to
>reveal the design. This *ought* to be the case with structured
>programming methods in general, and with OO in particular it should be
>even more pleasant because of the disciplined modularization of the
>program it entails.

Absolutely!  But why doesn't it work out that way?

-Tom



----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Harry Protoolis]

On Wed, 04 Dec 1996 16:35:54 +0000, Ahmed <ACQ95AA@shef.ac.uk> wrote:
>Harry Protoolis wrote:
>> 
>> On Tue, 03 Dec 1996 17:38:37 +0000, Ahmed <ACQ95AA@shef.ac.uk> wrote:
>> However, the real question should be 'has OO made a significant positive
>> difference', and in my experience the answer is a resounding 'yes!'.
>> 
>
>
>Dear Harry,
>I agree with you that OO has many advantages, but I can not feel that significant improvement
>as you said,
>
>The important question is how measure the success of OO,
>Can you please tell me on what crieteria you mesured this significant difference
>is it
>(  code reusibility / software development time / software performace / software reliablity/
>software cost / software portablity / ...etc .. ) these issues that count for any organization
>
>actually I am looking for any references that compares " with figures and statistics"
>between different applications developped using OO and the traditional methods.

This, I think is the nub and crux of your problem. The gathering of real
empirical data on software development is difficult or impossible. Real
software developent companies do not have time to prepare these results
for publication, and usually consider them too commercially sensitive.

>All what I have found are examples that show OO is workable, for me this
>is not an evidence to the significant difference"

Sorry, if it's hard evidence you want you probably need to wait another
ten years or so at least. However, the anecdotal evidence is that OO is
at least as good at getting the job done as conventional techniques, and
(very) occasionally spectactularly better.

>Another thing, Since you are familiar with OO,
>Could you please tell  me what is the best environment to develop an OO application,

:-), g++, vim, make, purify and ddd on a Sun Ultra Creator 3D with two
heads. (sorry guys, sparcworks CC is nice, but debugger *still* bites)

I find that Tools.h++ helps a lot, and when I can get it the STL.

>( in my case most of our applications are database systems )

Oh, and SYBASE with DbTools.h++ from Roguewave.

Seriously that is a very broad question, and depends a great deal on
your application domain. This sort of advice is worth what you pay for
it.

Cheers,
H

p.s. your lines are too long ...
_
Harry Protoolis                              alt.computer pty ltd                 
harry@alt.net.au                             software development consultants

Re: What is wrong with OO ?

[Steve Heller]

Daniel Drasin <drasin@arscorp.com> wrote:

>The problems I've seen with OO projects arise not from the use of OO,
>but from the misuse of OO.  Programmers trying to use non-OO methods,
>incorrectly applying OO concepts, etc.  This is a result of a lack of
>OO teaching at eductational institutions.  Even schools that offer 
>1 or 2 OO language courses usually fail to educate; they use C++
>and only really teach the "C" part.  There are very few
>universities that make an effort to inculcate students with an
>understanding of OO techiniques and methods.  So it's no wonder
>when these graduates try to apply them in the "real world," they
>get all fouled up.

  I agree. Moreover, instructors who DO attempt to teach "real" C++
(i.e., OO) programming run the risk of upsetting students who think
they already know how to program and other instructors who are still
not completely conversant with OO notions.


Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller 

Re: What is wrong with OO ?

[Nick Leaton]

:
> : > How flexible is the software? This has a lot to do with architecture:
> : > "if you don't get the architecture right up front, you may as well pack
> : > up and go home" [quote made by a fellow engineer].
> 
> : These kinds of statements always bother me. How are you supposed to
> : know that the architecture (or design for that matter) is right?
> :
> : The only way I see is to implement it and see how it works. That's
> : why the iterative software development makes sense, you get to try
> : out out your ideas in practice and adjust them as needed.
> 
> The point as far as I'm concerned is that an architecture should guide
> _all_ coding.  That is even if the initial architecture is later modified,
> or later scrapped.


But if you take an standard example, employee. Can you code up an
employee class without having an architecture? As an employee class
could be used in lots of different systems, all with different
architectures, you don't need to have an initial architecture to start
from. This is true of almost all components.

I don't see why there should be a distinction between top down and
bottom up. I use both in practice. Start off coding the obvious objects.
This gives you a feel for what you are doing. Then put them together in
some framework.
-- 

Nick

Re: What is wrong with OO ?

[Ralph Cook]

Harry Protoolis wrote:
> 
> On Wed, 04 Dec 1996 16:35:54 +0000, Ahmed <ACQ95AA@shef.ac.uk> wrote:
> >Harry Protoolis wrote:
> >All what I have found are examples that show OO is workable, for me this
> >is not an evidence to the significant difference"
> 
> Sorry, if it's hard evidence you want you probably need to wait another
> ten years or so at least. However, the anecdotal evidence is that OO is
> at least as good at getting the job done as conventional techniques, and
> (very) occasionally spectactularly better.

And occasionally spectacularly worse.  And to say that
individual projects like this have succeeded or failed does NOT
"prove", or even "show", that the language environment used is
"good" or "bad".

rc
-- 
When I DO speak for a company, I list my title and use "We".

Re: What is wrong with OO ?

[David Bradley]

The problem is that reuse through OOP takes effort.  People seem not
willing to expend the effort to get the benefit of OOP.  They put an
OOP in place and don't change their methods and then wonder why they
aren't able to reuse code.  You never get something for nothing.  If
you're not willing or unable to put forth the effort you'll never see
the benefit.

In order for something to be reused it has to be designed properly.
OOD is where most people fail.  This takes effort.  If you don't
expend this effort upfront you'll not get anything out.  

Look at OOP as a lever.  The work you put in will be multiplied out
the other end.  If you don't put in the initial work on the front end
then you'll never get the benefit on the back end.

--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com

Re: What is wrong with OO ?

[Bill Gooch]

Jeff Miller wrote:
> .... 
> Effective reuse is substantially a management issue, not a technical
> one. OO helps, but organizational and process changes are more
> important.

I think you may have missed the emphasis I was putting on
*immediate* reuse.  This means reuse of software modules
(methods, interfaces, classes, etc.) within a single
application, and sometimes across similar applications 
that are being developed concurrently.  IME, this flavor 
of reuse is primarily a technical (and technical project 
management) issue, and not an organizational one.  
"Process" at some level is always an issue, but then 
that's not saying very much.

OTOH, I agree that large-scale (longer term, and/or
broader scope, e.g. framework-level) reuse requires
organizational compliance.  But still, the technical 
issues can't take too much of a back seat, or nothing 
good will come of it.  You may accomplish reuse with 
organizational and process changes in the absence of 
a strong technical understanding, but the stuff you'll 
be reusing won't be worth reusing.

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: What is wrong with OO ?

[H Brett Bolen]

I don't believe I getting involved with this.  Anyway here's my
thoughts:

What are the 'Big Three' fundimental concepts with OO?

They are 

  Inheritance 
  Polymorphism 
  Encapsulation

 
I think that Inheritance struggles against Encapsulation.  Instead
of a function being in a single file, it is spread out over
two, three  or sometimes even 10 files ( depending upon the
'inheritance lattice').  Sometimes i find myself questioning which
of the 11 virtual functions do i need to fix.

I think better tools could help.

I think Inheritance is overused.  It even can be harmfull to reuse
( but I won't get into THAT).  When it's overused, it just makes
things complicated.

'Whats wrong with C++ and OOP?' is a way different question.
-- 
b\253              | Take Chances, Make Mistakes 
brettb@cpcug.org   | Get Messy    
brett bolen        |     - Ms Frizzle - MSB
Walrus Consulting  | http://www.cpcug.org/user/brettb

Re: What is wrong with OO ?

[Ahmed]

Bill Gooch wrote:
> 
> Ahmed wrote:
> >
> > Does this mean,If two organizations developed almost typical applications
> > does not mean that the objects developed can be reusable between them..
> > Is not this a deficiency in OO.
> 
> As compared to what?  Non-OO software?  I think not.
> 

Compared to the Object concept and its capability ..!!

> Two different automobile designs rarely share any
> compatible parts (except those which are industry-
> standardized, like oil filters), unless the designers
> worked together with that goal in mind.
> 

I think this is a good example for comparison,

Does every car-company develop the car from a to z ?  I doubt it ..!
There are special companies dedicated only to develop specific spare parts for the cars,

It is true that the spare parts are not compatible ( in general ) between different car models, 
However almost all cars share the same level of abstraction,

when you say a "radiator" to a mechnical engineer he will immediately understand its functionality,
no matter if it is a Mercedece or Honda car.
When you say to a mechanic "piston" "shaft" "gear-box" "clutch" "handbrake" ...etc. ( you name it )
then an Immediate image will draw in his mind and will grasp a general perception

Even if you go to lower levels, each part has a name and a main function,

Without this common abstaction between cars then the job of any mechanics will be almost
imposible. Otherwise every car model will require a dedicated mechanical engineer.


> > Every programmer is tackling the same problem using his own perception
> > of the problem..his own abstraction..
> 
> Yes, and the alternative is?...
> 

In my openion, to get the advantage of OO capability, there must be an 
agreement on the abstraction level of every domain. This should turn into standard abstaction 
 accessable for any softwaer developer. There should be an institute or company to take this 
responsibility. Otherwise people will always reenvent the weel by inventing their trivial classes 
localy which is a waste of a valuable resource .. ( Programmers )


> > The concept behind OO is that it deals with peices of software as
> > tangible objects exactly as real world works..
> 
> Not at all.  "How the real world works" is by no means
> obvious or well understood ("real world" in itself is
> an exceedingly vague term), and you'd need to provide
> some definitions of these things, as well as evidence
> to support the above assertion.
> 

I feel that this is a more phylosifical  answer than being practical.
Yes you need to provide some definitions for tricky words that might
give different semantics, however trivail words in the proper context
are self explainatory ..!!

> > however in real world
> > every object has a clear behaviour and perception by every body,
> 
> Not in the slightest.
> 
> > while in the OO software each object has a behaviour according to
> > the perception of his designer..!!
> 
> Sometimes.  The designer probably hopes it does.
> 
> > The problem is that many organization avoid moving toword OO because
> > the transfter cost to OO ( training programmers / organization change in
> > standards / new tools / new analysis and design methods / legacy
> > system/ etc. ) are much higher than the benifit of "immediate reuse"
> 
> OK - why is this a problem?

This means that OOP did  not yet prove or show its greate advantages  in many domains. So
It needs efforts more before being accepted widely. I believe that OO has the power to do so
but ( probably ) the wrong usage of it is preventing its remarkable success in certain
areas.


> 
> > Another point regarding inheritance, we know that Visiual Basic does not
> > have the capability of inheritance, however you can build a system
> > much faster  compared to using visiual C++ with much less code.
> 
> Depends what system, doesn't it?  VB isn't ideal for
> all computer applications; C++ is probably a better
> choice for at least some of them.
> 

Agree with you that C++ is much more powerful that VB in certain areas ..
But What prevent an OOP from exceeding a non OOP in all areas ..?


Regards,
Ahmed

> --
> William D. Gooch             bill@iconcomp.com
> Icon Computing               http://www.iconcomp.com
> Texas liaison for the International Programmers Guild
> For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: What is wrong with OO ?

[Myles Williams]

In article <588g4v$jer@samba.rahul.net> Carl Weidling <cpw@rahul.net> writes:
   On the other hand, wasn't there a famous example back in the 70s
  when 'top-level design' was first being expounded, where some big project
  for a newspaper or something was designed first and then coded and it worked.
  I remember this being cited a lot when I first started programming, can
  anyone recall details or hard facts about that?

That would be the New York Times database, created by IBM circa 1970.
It was the first full-scale application of structured programming, and
was completed early and under budget with approximately 0.25
defects/kLOC.

-- 
Myles Williams			"When you see me again, it won't be me."
http://funnelweb.utcc.utk.edu/%7Ewilliams/freeos | Guide to free
						 | operating system kernels

Re: What is wrong with OO ?

[Ranjan Bagchi]

Myles Williams wrote:
> 
> In article <588g4v$jer@samba.rahul.net> Carl Weidling <cpw@rahul.net> writes:
>    On the other hand, wasn't there a famous example back in the 70s
>   when 'top-level design' was first being expounded, where some big project
>   for a newspaper or something was designed first and then coded and it worked.
>   I remember this being cited a lot when I first started programming, can
>   anyone recall details or hard facts about that?
> 
> That would be the New York Times database, created by IBM circa 1970.
> It was the first full-scale application of structured programming, and
> was completed early and under budget with approximately 0.25
> defects/kLOC.
> 

Wow.. that's impressive.

It also indicates to me that flagship projects in any methodology
seem to be incredibly successful.  Perhaps it's because world-class
engineers are working on it and they're just succesful regardless of 
technology or tools or anything.  The suggestion, though, may be that 
success of projects done by mere-mortal engineers using a particular 
methodology provide better data points.

How this applies to the success of O-O is interesting because I think
most people agree that misapplied O-O results in failed projects
which sully O-O's reputation.  Is it easier for mere-mortals to
understand O-O?  

Should mere-mortals be in the software development business at all is 
another question, which is vaguely frightening.

-rj

Re: What is wrong with OO ?

[Robert C. Martin]

In article <587veh$ng8@news3.digex.net>, ell@access5.digex.net (Ell) wrote:

> : Robert C. Martin wrote:
> 
> : >Much to my dismay, there are some OO methods that are promoting 
> : >the same scheme.  The "analyst" draw nice pretty little diagrams, and
> : >even run them through simulators to "prove" that they work.  These
> : >diagrams are then run through a program that generates code.  Programmers
> : >who maintain that code generator have to make sure that the "right" code
> : >is generated.  They have to make the program work.
> 
> Are you saying that iterative and incremenatl diagrams are always wrong or
> that the code generator has problems?  Or both? 

I am saying that the creation of an elite "architecture team" composed
of members who:
  1. Dictate their decisions to the programmers.
  2. Do no programming themselves.
is a prelude to a disaster.

Architects must first be programmers.  Architects must continue to write
some code.  Architects must sell, or at least negotiate, their architectures
with the developers.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Prashant Gupta]

H Brett Bolen wrote:
> 
> I think that Inheritance struggles against Encapsulation.  Instead
> of a function being in a single file, it is spread out over
> two, three  or sometimes even 10 files ( depending upon the
> 'inheritance lattice').  Sometimes i find myself questioning which
> of the 11 virtual functions do i need to fix.
> 
On the contrary, I think careful use of inheritance promotes
encapsulation. In any case, I don't think encapsulation means that
all the code will be in a single "file". After all, using separate
text files for different subclasses is just an implementation detail
specific to the language (eg C++). Encapsulation simply means that
logically related concepts, namely the data and the operations that
can be performed on the data, "live" together within a logical entity.
How that logical entity is stored on a physical device is an entirely
different matter. An inheritance hierarchy is certainly a well defined
logical entity within the OO paradigm where all of the polymorphic
methods can live.

Let us say we have an abstract superclass (base class) called
"Automobile" which provides a method called "Automobile>>#driveTo:"
[ Automobile::driveTo(const Destination *) ].
The actual implementation of the method needs to be deferred to the
concrete subclasses (derived classes) because 
4speed/5speed/Nspeed/automatic transmission vehicles would presumably
work differently. Now even if this "driveTo" method is implemented
differently in 25 concrete subclasses, I don't see how that violates
encapsulation. More importantly, how would it promote encapsulation
if we were to not use inheritance and instead construct all of the 
concrete classes from scratch. Wouldn't that require duplication of
code that is common to all Automobiles. Wouldn't that be a violation
of encapsulation in a sense.
> 
> 'Whats wrong with C++ and OOP?' is a way different question.

No argument there. :-)

Prashant Gupta.

> --
> b\253              | Take Chances, Make Mistakes
> brettb@cpcug.org   | Get Messy
> brett bolen        |     - Ms Frizzle - MSB
> Walrus Consulting  | http://www.cpcug.org/user/brettb

-- 

The opinions expressed here are mine and do not necessarily reflect
the opinions of my employer.
----------------------------------------------------------------------
Prashant Gupta		mailTo:pg@bbt.com         (919) 405 4884
----------------------------------------------------------------------

Re: What is wrong with OO ?

[David Bradley]

>I assume this is because the design is the work of a much smaller
>team, whose only physical output is computer models or paper.  This is
>my point - other engineering disciplines appear to routinely put much
>less total effort into design, with much greater success.  I guess
>this is just the positive result of greater maturity as a discipline.

or the result of a more complex field.

--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com

Re: What is wrong with OO ?

[Roger Vossler]

Tom Bushell wrote:
> It is my growing opinion that this is a fundamental problem with all
> "formal" design methods, not just OO design.  The effort involved in
> doing the design is as great or greater than doing the construction

<snip> 

> I'm starting to believe that design and code don't make sense as
> separate entities - the design should _become_ the code - the design
> documents for an implemented system are used as the foundation of the
> code, and then regenerated from the code.  Major benefits would be

<snip>

> If anyone has knows of tools that would facilitate this approach, I'd
> certainly be interested.  I've done some very simple prototypes, and
> hope to work on the idea in future (when I have more time - Hah!).

IMHO, this is more of problem with large CASE tools or design systems
than it is with design per say. As I understand it from the OO wizards,
start with a small number of use-cases in order to understand the
problem,
and if you go OO subsequently, then do some CRC card modeling.

Thus, all you need for a start is a stack of 3x5 index cards, pencil,
paper, and a couple of good books. Peter Coad has a lot of good things
to say about this. Then, when you understand what you are doing, commmit
to the CASE swamp of your choice.

The problem is that people first buy a killer tool chest and spend
large numbers of hour understanding how to use the beast and even
more hours stuffing a data base only to discover thay they have
created a big mess.

Cheers, Roger Vossler (vossler@csn.net)

Re: What is wrong with OO ?

[Mukesh Prasad]

Tom Bushell wrote:
[snip]
> I'm starting to believe that design and code don't make sense as
> separate entities - the design should _become_ the code - the design
> documents for an implemented system are used as the foundation of the
> code, and then regenerated from the code.  Major benefits would be
> that design work would not be discarded because it was too difficult
> to bring it up to date with reality.  Therefore, the design should
> never get out of synch.  This a similar idea to reverse engineering,
> but not identical.
[...]

I have seen the term "iterative prototyping" used to formally
describe an approach like this.

Iterative prototyping means you start from a
prototype of the system, written from a very sketchy
design (the design may even be just in peoples' heads.)
You use your prototype to write an improved
design, which you then use to implement improvements
to the prototype, which you then use to improve
your design.... repeat until your erstwhile
"prototype" becomes the "system" with a very
closely matching design spec, and everybody is happy.

In practice, I have seen a shortened version,
the "backward spec", i.e. specifications done
from implemenations (with modifications as required)
work very well in certain cases.  Much better than the
strict "implement exactly from spec" approach.

I believe these less top-down approaches work better
because in a lot of cases, at specification time
the product is very vaguely understood.  Moreover,
many implementation problems are not anticipated well.
An actual, physical implementation can sharpen everybody's
hazy understanding to the point where actually good design
decisions can be made.  Thus doing the spec from an
initial implementation, and fixing the implementation
to match the final spec, can yield much
better results overall.

Of course, there is no reason why your design
couldn't be OO.  The problems you describe,
I think, are not problems of OO, but rather
the problems of trying to do a detailed
design without sufficient understanding
of the product to be designed and its problems.

  /Mukesh

Re: What is wrong with OO ?

[Bill Gooch]

Ahmed wrote:
> 
>.... 
> It is true that the spare parts are not compatible ( in general ) between different car models,
> However almost all cars share the same level of abstraction,
>
> when you say a "radiator" to a mechnical engineer he will immediately understand its functionality,
> no matter if it is a Mercedece or Honda car.
> When you say to a mechanic "piston" "shaft" "gear-box" "clutch" "handbrake" ...etc...

In software, any of the above would be a "pattern."

> Even if you go to lower levels, each part has a name and a main function,
> Without this common abstaction between cars then the job of any mechanics will be almost
> imposible. Otherwise every car model will require a dedicated mechanical engineer.

The analogy breaks down because all cars respond to
essentially the same set of general requirements, with 
variations occurring at a more detailed level.  Software
requirements vary widely at all levels, and thus the 
*application* and *composition* of common patterns in
different pieces of code also vary accordingly.  Cars
(and trucks) are all similar in many important respects,
in addition to the fact that the patterns involved in
their designs are pretty well and widely understood.
Your everyday mechanic will usually know most of the
patterns by heart, whereas a typical software engineer
is often learning new patterns with each new project.

> Yes you need to provide some definitions for tricky words that might
> give different semantics, however trivail words in the proper context
> are self explainatory ..!!

IMO words are never "self explanatory."  It's in the 
nature of perception that each individual has his or 
her own distinct interpretation.  But there is a wide
range of variation in the ambiguity of different words,
and "real" and "world" are both separately, and even
more so when used together, highly ambiguous.  We tend 
to ignore or even deny the ambiguity of words like these 
that we use very frequently, but trying to define them
in very specific terms often illuminates the issue.

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: What is wrong with OO ?

[Todd Hoff]

Daniel Drasin wrote:
> 

> The problems I've seen with OO projects arise not from the use of OO,
> but from the misuse of OO.  Programmers trying to use non-OO methods,
> incorrectly applying OO concepts, etc.  This is a result of a lack of
> OO teaching at eductational institutions.  Even schools that offer
> 1 or 2 OO language courses usually fail to educate; they use C++
> and only really teach the "C" part.  There are very few
> universities that make an effort to inculcate students with an
> understanding of OO techiniques and methods.  So it's no wonder
> when these graduates try to apply them in the "real world," they
> get all fouled up.

If i invented a hammer and 90% of people couldn't use
it correctly would we blame the hammer or the people?
It seems those who've "got" OO blame the people. Maybe we
should blame the hammer. Maybe OO just won't work in
the mass market of building applications. Not that it
can't, but that it doesn't work often enough to make it
universally appropriate.


-------------------------------------------------------------
tmh@possibility.com        | The loyalty of small men can be
http://www.possibility.com | bought cheaply, for greed has no
                           | pride.  - Michael Kube-McDowell

Re: What is wrong with OO ?

[Robert C. Martin]

In article <slrn5afin1.49v.harry@matilda.alt.net.au>, harry@alt.net.au wrote:

> On 6 Dec 1996 03:26:57 GMT, Ell <ell@access4.digex.net> wrote:
> >Richie Bielak (richieb@calfp.com) wrote:
> >
> >The point as far as I'm concerned is that an architecture should guide
> >_all_ coding.  That is even if the initial architecture is later modified,
> >or later scrapped. 
> 
> Despite being a 'self centered hacker' (I like that title :-)) I
> actually agree with you Elliot. You should at least sketch your
> architecture out after your analysis is complete, (where analysis ==
> primary use cases), and design to it.

Actually, I prefer to do much more than just "sketch it out", the architecture
should be very well defined, and very detailed.  However, I also prefer to
begin producing the architecture well before all the analysis is complete.
And I prefer producing code that is conformant to the architecture - and the
analysis - long before the architecture is complete.  

In other words, I like to do them all concurrently.

This doesn't mean that I *ever* code something that is not designed.
It also doesn't mean that I design something that has not been analyzed. 
It's just that I don't wait for *all* the analysis to be completed before
I begin on designing the architecture.  And I don't wait for the complete
architecture before I begin on the code.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Myles Williams]

In article <32A8631E.4CB0@pobox.com> Ranjan Bagchi <ranjan.bagchi@pobox.com> writes:
   > That would be the New York Times database, created by IBM circa 1970.
   > It was the first full-scale application of structured programming, and
   > was completed early and under budget with approximately 0.25
   > defects/kLOC.
   Wow.. that's impressive.
   It also indicates to me that flagship projects in any methodology
   seem to be incredibly successful.  Perhaps it's because world-class
   engineers are working on it and they're just succesful regardless of 
   technology or tools or anything.  The suggestion, though, may be that 

I tend to think it's because the people working on it are familiar
with the methodology in its original incarnation, before marketers and
"armchair experts" corrupt it.  That's why, whenever someone needs
an explanation of OO, I direct them to the work by Parnas and co. in
the 70s.

-- 
Myles Williams			"When you see me again, it won't be me."
http://funnelweb.utcc.utk.edu/%7Ewilliams/freeos | Guide to free
						 | operating system kernels

Re: What is wrong with OO ?

[Bob Crispen]

There's one OOD problem that so far I haven't seen mentioned
that's been the death of at least two programs I know of.

Object-Oriented Design is a paradigm, implemented by various
methodologies, in order to PRODUCE A GOOD DESIGN.

The go/no-go question that MUST be asked of an OO design
(the fruits of an OO methodology or process) is not "Does
this design scrupulously adhere to the tenets of our
particular sect of OOD?" but rather "Is this a GOOD DESIGN?"

Forgive my shouting, but it is perfectly possible to lose
sight of the goal in the quest for methodological
scrupulousness.

It's also perfectly fatal.
--
Rev. Bob "Bob" Crispen
crispen@hiwaay.net
"A polar bear is just another way of expressing a rectangular bear."

Re: What is wrong with OO ?

[David B. Shapcott [C]]

In article <32a5ceba.81462731@news.nstn.ca>,
Tom Bushell <tbushell@fox.nstn.ns.ca> wrote:
>
>It is my growing opinion that this is a fundamental problem with all
>"formal" design methods, not just OO design.  The effort involved in
>doing the design is as great or greater than doing the construction
>(coding).  Contrast this with doing the blueprints for a bridge - the
>design effort is orders of magnitude cheaper than the construction.
>(Or so I believe - a civil engineer might correct me on this).  Also,
>the OO design models I've studied don't seem to be very good maps of
>actual real world systems - there seems to be a big gap between high
>level architecture and running code.  I believe there should be a
>fairly smooth continuim from high level to low level of detail.
>
>I'm starting to believe that design and code don't make sense as
>separate entities - the design should _become_ the code - the design
>documents for an implemented system are used as the foundation of the
>code, and then regenerated from the code.  Major benefits would be
>that design work would not be discarded because it was too difficult
>to bring it up to date with reality.  Therefore, the design should
>never get out of synch.  This a similar idea to reverse engineering,
>but not identical.

In bridge engineering, design and construction take place in different
mediums, unlike software engineering.  A software engineer designs and
implements on the same medium, a computer, providing an opportunity to
at least *partially* translate design information directly into
implementation.  Mechnical translation is less error prone than humans
and far less labor intensive.

The complete implementation cannot be synthesized mechanically, but
such translation should be maximized.  If the developers *depend* on
design information, they will keep it up to date (they really have no
choice).  IME, flow control seems to be the correct level for
partitioning.

The concept you refer to is termed `round trip engineering' (RTE).
Although trying to synthesize up-to-date design from the end product
(i.e. reverse engineering) is the wrong way to achieve RTE.  RTE
works best when changing a design product is the only and *best*
method for effecting change in the implementation.  (This reverses
the path of generation you propose.)

Manual update and synchronization of design products with
implementation never gets done.  Never, IME.  Reverse engineering only
provides an up-to-date design product at the end of the implementation
phase (IMO, synchronization should be continuous) -- although RE helps
immensely when the developers are dealing with legacy or third party
products.

Some RTE schemes also suffer because the reverse engineering relies too
heavily on the code generator.  Even minor changes to the generated code
can defeat reverse engineering.


-- 
D. Brad Shapcott [C] Contractor, Motorola Cellular Infrastructure Group

"Theory changes the reality it describes."

Re: What is wrong with OO ?

[Tansel Ersavas]

... Disucssion deleted

> >It seems those who've "got" OO blame the people. Maybe we
> >should blame the hammer. Maybe OO just won't work in
> >the mass market of building applications. Not that it
> >can't, but that it doesn't work often enough to make it
> >universally appropriate.
> 
>   Or maybe it's just taught poorly. I've been pretty successful in
> teaching OOP to people who don't know it already. However, it takes an
> awful lot of work on both the instructor's and the student's part, as
> well as a proper approach. That is, rather than my trying to cram
> dozens of constructs down the student's throat, we take them slowly
> and in the proper sequence. The student won't know as many facts when
> we get done as if he'd read a "Learn C++ in Five Seconds" book, but he
> or she will KNOW and UNDERSTAND the material I've taught.
>

Ladies and Gentlemen,

Before we discuss 'what is wrong with OO', shouldn't we discuss what is
wrong with the current popular paradigm, procedure orientation.
Most of us seem to have forgotten it is just a historical accident that
we program the way we do in procedural approach, and if we are in a
total mess as software developers, one of the biggest reasons is our
insistence on procedure orientation. Most of the current OO
implementations carry a legacy of people with procedure oriented
background, and that reflects quite badly on the projects. Languages
that easily allow such escapes also contribute to this phenomena.

Once we accept the problems of the procedure orientation (see my
previous posting to comp.object about the subject) then we can look at
the alternatives. 

When we conquer new places, the first to go usually perish. It is tough
to be a pioneer. However, with persistence and perseverence, we build
necesary access and support systems, and that new place becomes very
hospitable and finally, a source of great wealth. Luckily, time for
being a pioneer in OO is just about to pass. Now comes better times and
even prosperity.

There are three major reasons why OO projects fail. All of them are
stated by the great wisdom of Jedi in "Star Wars".

These are:
    "Do or do not. There is no try"
    Using my tools and techniques, I can prove you that I can produce
    better and faster systems using OO (Please read my notes at the end
    of this message). If I can do it, so you can.If you just try to do
    it, you will fail. Be determined to do it.

    "You must unlearn what you have learned"
    People cling so heavily to the baggage they have been carrying, 
    they can not have an open mind about OO. SO the first thing I do
    in my training sessions is to create doubts and  questions about 
    the problems of the procedural approach, and why procedure
    orientation is a very ineffective technique for most new problems.
    Of course, you should have a very good mentor that is capable of
    demonstrating these in practical terms. 

    "You must believe in what you are doing"
    OO will help you. It will feel awkward at times, but you must
    persist with it. You will be eventually rewarded.

Coming to the question of "What is wrong with OO" the question should
read "What are the problems in the current state of OO that slows down
it's progress". 

There three major problems that slows down OO.
.  Lack of expertise, personal and team skills (human issues)
.  Lack of fast, efficient and practical tools-environments that make
   programming one of the the most labor-oriented, miserable works
   available Today
.  Lack of practical OO application techniques and ways that will
   integrate OO with other succesful paradigms

Current state of OO suffers from all of the above. Each and every one of
these problems are soluble, Indeed as a company, we are working on and
have at least intermediate solutions for all of them. 

BTW I get a much better response for OO from children. For that reason,
I'll offer educational versions my tools and techniques to schools so
that children can be exposed to these techniques before their minds are
clutterd by the current dominant paradigms.
 
Tansel Ersavas
RASE Inc.
mailto:tansel@deep.net
http://www.rase.com/

Re: What is wrong with OO ?

[Ell]

Piercarlo Grandi (pcg@aber.ac.uk) wrote:
: "rmartin" == Robert C Martin <rmartin@oma.com> writes:
: > Harry wrote 
: >> In fact IMHO an OO team has no place for anyone who cannot do all
: >> three tasks. [Analysis, Design, and Implementation]
 
: > Agreed, emphatically.

It seems you all are not considering all factors here.  For instance,
because someone is a good Java programmer does not necessarily mean they
are good at working with users to formulate analysis, or that they have
good architectural skills for medium sized or large projects.  And vice
versa.

Some people are better at some things than others and some people
shouldn't do certain things at all.

: Architecture, as you have so many times argued, is extremely important,
: and the implementor that is not guided by sound architectural
: principles, by close interaction with analisys and design, is not going
: to do a nice implementation.

If you are speaking of Martin, he has only accepted that project coders
should be required to follow architecture within the last 6 months
(partially at my urging).  WRT analysis he has never to my knowledge
accepted that an overall analysis should be done at the outset of a
project and that it should lead the creation of project architecture. 

Elliott

Re: What is wrong with OO ?

[Nick Thurn]

Todd Hoff wrote:
> 
> If i invented a hammer and 90% of people couldn't use
> it correctly would we blame the hammer or the people?
> It seems those who've "got" OO blame the people. Maybe we
> should blame the hammer. Maybe OO just won't work in
> the mass market of building applications. Not that it
> can't, but that it doesn't work often enough to make it
> universally appropriate.
> Todd,

I think it is the expectations placed on the people. 
Michaelangelo user a hammer and chisel to produce great art.
I use it to bang a hole in my kitchen wall. If I expected
great art I would be disappointed. 

The expectation that *all* those who use OO should be producing
reusable, high quality stuff is false however it appears IME
to be (or at least have been initially) the case. 

For the "average" programmer OO should be mainly using not 
creating. Of course it's chicken and egg, something must be
created to be reused.

cheers
Nick (my opinions only)
"If I had a hammer, I'd hammer in the ...."

> -------------------------------------------------------------
> tmh@possibility.com        | The loyalty of small men can be
> http://www.possibility.com | bought cheaply, for greed has no
>                            | pride.  - Michael Kube-McDowell

Re: What is wrong with OO ?

[Harry Protoolis]

On 7 Dec 1996 02:02:05 GMT, Ell <ell@access2.digex.net> wrote:
>Piercarlo Grandi (pcg@aber.ac.uk) wrote:
>: "rmartin" == Robert C Martin <rmartin@oma.com> writes:
>: > Harry wrote 
>: >> In fact IMHO an OO team has no place for anyone who cannot do all
>: >> three tasks. [Analysis, Design, and Implementation]
> 
>: > Agreed, emphatically.
>
>It seems you all are not considering all factors here.  For instance,
>because someone is a good Java programmer does not necessarily mean they
>are good at working with users to formulate analysis, or that they have
>good architectural skills for medium sized or large projects.  And vice
>versa.

This is a question of direction. I accept that there will be individuals
who can only do implementation under the guidance of more senior
designer/implementors, and that possibly not all of your
designer/implementors might do analysis. These are acceptable tradeoffs
to the reality of staffing projects.

However, I would never, ever, ever hire an individual who claimed to
be a 'software architect' who was not *at least* a competent programmer,
and I would try hard to find one who was an exceptional programmer.
I would expect a person calling themselves an 'analyst' to be
either a competant designer/implementor or have very strong domain
specific skills, or better yet both. If they only have the latter then
their role would, by necessity, be limited.

>Some people are better at some things than others and some people
>shouldn't do certain things at all.

Sure, but IME if you can write software, you can't be an 'architect' period.

>: Architecture, as you have so many times argued, is extremely important,
>: and the implementor that is not guided by sound architectural
>: principles, by close interaction with analisys and design, is not going
>: to do a nice implementation.

>If you are speaking of Martin, he has only accepted that project coders
>should be required to follow architecture within the last 6 months
>(partially at my urging).  WRT analysis he has never to my knowledge
>accepted that an overall analysis should be done at the outset of a
>project and that it should lead the creation of project architecture. 

See, you said it again. 'project coders' as if they were a separate
bunch of people. If you make the 'Architecture Team' the core of the
'Coding team' then the issue of 'requiring' does not come up. Of course
the implementation will follow the architecture, if the architecture is
being developed by the same people who are leading the implementation effort.

H
-
Harry Protoolis                              alt.computer pty ltd                 
harry@alt.net.au                             software development consultants

Re: What is wrong with OO ?

[Harry Protoolis]

On Fri, 06 Dec 1996 09:09:54 -0500, Ralph Cook <ralph.cook@mci.com> wrote:
>Harry Protoolis wrote:
>> 
>> On Wed, 04 Dec 1996 16:35:54 +0000, Ahmed <ACQ95AA@shef.ac.uk> wrote:
>> >Harry Protoolis wrote:
>> >All what I have found are examples that show OO is workable, for me this
>> >is not an evidence to the significant difference"
>> 
>> Sorry, if it's hard evidence you want you probably need to wait another
>> ten years or so at least. However, the anecdotal evidence is that OO is
>> at least as good at getting the job done as conventional techniques, and
>> (very) occasionally spectactularly better.
>
>And occasionally spectacularly worse.  And to say that
>individual projects like this have succeeded or failed does NOT
>"prove", or even "show", that the language environment used is
>"good" or "bad".

Point taken, I guess what I am saying is that the hard statistical
evidence needed doesn't exist yet. It is too early to call OO a failure,
and given all we have is anecdotal evidence, IME the balance is on the
positive side

H
-
Harry Protoolis                              alt.computer pty ltd                 
harry@alt.net.au                             software development consultants

Re: What is wrong with OO ?

[Kazimir Majorinc]

Hello!

I spent last two years in programming (for me) very complex structures in
C++, and before that in Borland's Object Pascal. Although I was very
enthusiastic with OO in the beginning, I'm losing this day by day. Before
few months I thinked that Smalltalk could be better than C++, now I am in
doubt with this. Listen why.

1. My analyse of my work shows that I will wrote programs faster if I use
some of good old procedural languages, like Modula-2. I know how you
could criticize me, but I'm exposed here. 8-)

2. Encapsulation, I mean that both data and functions are together in
object seems to me like very unnatural shape today. Look at
mathemathics. Mathematical language do not use that paradigm, although
things which are described there are more complex than any software.  
They use something which looks like procedural paradigm with operators.
It talks to me that, paradoxaly, object paradigm could work only for
simple problems, but for complex, we have to come back to procedural.
Looking just hierarchicaly, functions should be one level higher than
data. Moreover, it is especially unnatural that one object contains
functions which uses many others. If I overload operators, for
example + in C++, I have disgusting when I use object model, and I have
to prefer first element, when there is absolutely no reasons for that.
If I could choose, I use procedural overload. If is necessary to make
groups of functions, it is better to use some sort of packages. Class
with lot of function members look really unnatural. I believe Smalltalk
is even worse here. 

3. Polymorphism. The greatest part of OO. I understand wish, but look at
C++. Why if I want to do this things, I have to do it implicitely. I
mean why functions which overload each other should have same name? It
is better to do it explicitely, to say which function is overload of
which. Now things could be simpler. I do not know how to do it in
procedural paradigm, but I believe that it is somehow possible.

4. Inheritance. It seems OK. 

5. Constructors, Destructors. They are great!

6. Messages. I do not know a lot of this, but Idea that object change
himself alone remembers me at the days of programming on TI57, or in
assembler, when every instruction is on so called accumulator. OO wants
accumulator back.

I would apprettiate one copy of answer privately (because news from my
server expire fast), and use my name, that I could find you with Deja
News. Of course, public answer is even better.

_______________________________________________
Author: Kazimir Majorinc
E-mail: Kazimir.Majorinc@public.srce.hr
        kmajor@public.srce.hr (slightly better)
http:   //public.srce.hr/~kmajor (~7min to USA)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
One who knows the secret of the 7th stair

Re: What is wrong with OO ?

[Steve Heller]

Todd Hoff <tmh@possibility.com> wrote:

>Daniel Drasin wrote:
>> 

>If i invented a hammer and 90% of people couldn't use
>it correctly would we blame the hammer or the people?

  If I invented an electron microscope and 90% of people couldn't use
it, would we blame the electron microscope or the people? In other
words, the complexity of the job that the tool needs to do matters as
well.

>It seems those who've "got" OO blame the people. Maybe we
>should blame the hammer. Maybe OO just won't work in
>the mass market of building applications. Not that it
>can't, but that it doesn't work often enough to make it
>universally appropriate.

  Or maybe it's just taught poorly. I've been pretty successful in
teaching OOP to people who don't know it already. However, it takes an
awful lot of work on both the instructor's and the student's part, as
well as a proper approach. That is, rather than my trying to cram
dozens of constructs down the student's throat, we take them slowly
and in the proper sequence. The student won't know as many facts when
we get done as if he'd read a "Learn C++ in Five Seconds" book, but he
or she will KNOW and UNDERSTAND the material I've taught.


Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller 

Re: What is wrong with OO ?

[Steve Heller]

rmartin@oma.com (Robert C. Martin) wrote:

>I am saying that the creation of an elite "architecture team" composed
>of members who:
>  1. Dictate their decisions to the programmers.
>  2. Do no programming themselves.
>is a prelude to a disaster.

>Architects must first be programmers.  Architects must continue to write
>some code.  Architects must sell, or at least negotiate, their architectures
>with the developers.

  Absolutely correct in all regards.


Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller 

Re: What is wrong with OO ?

[Tansel Ersavas]

Dave Griffiths wrote:

> The last OO project I worked on was a spectacular disaster. A "generic"
> reservations system for one of the biggest entertainment companies in the
> world. It was cancelled a couple of months ago after millions down the
> drain. You won't read about it anywhere because these things aren't discussed
> publically. That in itself is part of the OO "problem" - you only hear about
> the successes. This particular project failed through lack of a coherent
> technical vision. There was nobody "in charge", just a bunch of developers
> making it up as they went along. They were pretty talented, but that RAD
> approach simply doesn't scale up for large projects.

I think that there are a few points here that should be discussed. 

1. "The cancelled projects with money down the drain" is not a part of
the OO problem, but a general IS one. I know two 100 million projects
cancelled after 5 years of great hopes, money and sweat, and they
weren't OO projects. Every year, hundreds of BILLIONS of dollars are
down the drain because of blown IS budgets and cancelled projects. In
fact I would doubt very much that cancelled OO projects to successful OO
projects ratio to be anything near cancelled traditional style projects
vs overall traditional projects. The only reason we hear about failed
traditional systems is that there are so many of them and they are much
more spectacular than the one you are mentioning. Still only a very few
of them get a mention. 

2. You were very right to observe the reasons as to why the project
failed. However, this is a more general syndrom of industrial era
mentality applied to complex systems. 
As we move in the post industrial era, most of our problems come from
our inability to create new types of organizations that can deal with
such situations.

3. I am not a particular fan of the RAD approach. It doesn't imply OO,
in fact, OO is only later tucked on to it. RAD is Today's techniques
applied to Yesterday's organization structure. OO is not essential to
the RAD, and If RAD fails, the failure can not be attributed to its
tucked on OO component.

4. You were right to point out scaling as the biggest problem. However,
OO, though as practiced Today it has its scaling problems, properly done
has a much bigger chance of scaling than the traditional approach.

> OO is pretty easy to sell though. You get the salesman to fly in from
> California, take the managers out to lunch, talk loudly, smoke big cigars
> and so on, then it's back to the conference room for a demo "blah blah,
> ten times faster than existing development environments, blah blah", they
> show how you can build a GUI interface to the database with just a few
> drag'n'drops. Managers are bewitched, they agree to a pilot project to
> build a prototype, in come the consultants to head up the project, they
> knock up a few bubble diagrams, the prototype gets built and looks better
> than anything the managers have ever seen and that's it, they're hooked.

I'm glad to hear that. In my time it was much harder.  

> By the time it all goes horribly wrong, the fast talking consultants who
> did the original "design" are long gone (natch) and are now trying to sell
> someone their Web based solution...

Hey, they have to live, life goes on. What's wrong if they costed a few
millions to be wasted on one client's expense?
Frankly, I couldn't have kept a straight face if I were responsible of
such a failure. 

Anyway, I think that for OO to succeed, there are certain prerequisites.

1. People and the organization that they are in
2. Proper techniques (such as OO)
3. Tools 

People and organizations issue is the most important issue. If you get
the best people and put them into an average organization, they will be
wasted. Why:
Current organizations are based on Smith, Fayol and Taylor's industrial
era principles. These principles are based not on trust and liberty, but
suspect and control. It is a restrictive rather than nourishing
environment. In this environment, people are restricted by the system
they are in, and act accordingly. 
I personally witnessed a case where in a big organization three of my
friends were working on a project they knew it wouldn't be succesful,
because by the time they had finished it, the system that they were
developing the software for would be outdated, and being a legacy
propriotory system, they wouldn't be able to replace hardware, and there
would be no cheap way to port the software. They tried to explain it to
the management, but not wholeheartedly. Nobody listened. As nobody owned
the system, software was finished, and shelved.

In this type of organization the process is divided into little steps of
each would be performed by a non-overlapping team. Only the managers
high up should have the overall vision and knowledge of which most of it
already filtered going up and down; therefore collective vision and
knowledge is nowhere to be found.

Alternative structures are networking organizations. Indeed, there are a
few companies enjoying benefits of human networking, and ours strives to
be one of them.

As for OO, even if it doesn't work, it should work. I saw it working,
and I know it is repeatable.

Tools are another chapter, indeed another book, that can help us out of
our current misery. However, I don't have time to elaborate on that.

Overall, it is a jigsaw, if parts are missing it doesn't look good.

Remember, reading the same Bible, some go to crusade and kill thousands,
some become loving caring people. Using the same knife, a chef creates
masterpieces that are delicious, yet some others use it to threaten
others. Techniques are just like that. Not magic wands. People can use
OO to drown themselves and others in a spectacular mess, or glorify
themselves and their organization. Lets create an unified vision for the
people first, and than expect good results.

Finally, if OO won't work, what are the alternatives, certainly not the
old ways.

Kind Regards

Tansel Ersavas
RASE Inc.
mailto:tansel@deep.net
http://www.rase.com/

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "tbushell" == Tom Bushell <tbushell@fox.nstn.ns.ca> writes:

tbushell> On 05 Dec 1996 22:30:40 +0000, pcg@aber.ac.uk (Piercarlo
tbushell> Grandi) wrote:

pcg> *If* analisys and design efforts were conducted in resonance with
pcg> each other and implementation, then spending more effort on those
pcg> than coding would be all fine and actually rather useful,

tbushell> I agree that the effort is useful.  But my gut feeling is that
tbushell> with better (and apparently undiscovered, as yet) processes
tbushell> and tools, the high level design activity should be about 10%
tbushell> of the total project, not around 50%.

Perhaps the reverse: if the tools were really advanced, perhaps
including a program generator (and despite claims to the contrary no
such thing has been yet produced), then high level design activity would
be almost all the project. As things stand, human work on the ``lower''
levels of a project is indispensable, and communication problems between
the humans doing the various levels of abstraction, if the total effort
is divided in groups corresponding to such levels of abstraction, can
cause embarassing problems, as Robert Martin has always observed.

tbushell> Contrast this with doing the blueprints for a bridge - the
tbushell> design effort is orders of magnitude cheaper than the
tbushell> construction.  (Or so I believe - a civil engineer might
tbushell> correct me on this).

pcg> It is usually _cheaper_, but on the other hand it might take
pcg> _longer_.

tbushell> I assume this is because the design is the work of a much
tbushell> smaller team, whose only physical output is computer models or
tbushell> paper.

Not quite, because while _building_ the bridge is an almost-mechanical
project, designing it requires a lot of hard thought, and consultation
with users, and in particular lots of iterations and refinements.

However designing a bridge and building it are not a good analogy for
analysis/design and vs. coding; more like an analogy for all three of
analisys/design/coding vs. execution.

Naturally building a bridge from blueprints is not quite as mechanical
as executing a program, for bridges are built by human teams using quite
but not-so-precise blueprints. Still it has the characteristics of
execution: an abstraction is turned into an instance (and potentially
many instances, in the case of things other than bridges of course).

tbushell> This is my point - other engineering disciplines appear to
tbushell> routinely put much less total effort into design, with much
tbushell> greater success.  I guess this is just the positive result of
tbushell> greater maturity as a discipline.

Well, my impression is exactly the opposite: that the design of material
entities like a new car or an airplane model requires immense amount of
money and time, as compared to almost any software project, and as many
iterations, and as much debugging, if not more, and then there are as
many *design* bugs (as opposed to manufacturing defects) in the finished
products. The saving grace is that cars and other physical systems like
a building (but surely not airplanes) are usually, but not often simpler
than doing software.

Even in *cost* designing a new car or airplane can be a significantly
large part of the cost of each instance of the design. I would even
argue that the percentage of the sale price of instances that repays the
development cost can be significantly higher for cars or airplanes than
for software.

  Then while a large part of the sale price covers instantion costs for
  cars and airplanes, the instantiation costs of software are very
  small, and most of the sale price covers marketing expenses and
  profit; in this software is more like soft drinks and perfumes,
  physical products sold on their intangible value, than cars or
  airplanes.

tbushell> Also, the OO design models I've studied don't seem to be very
tbushell> good maps of actual real world systems - there seems to be a
tbushell> big gap between high level architecture and running code.  I

This is a good reason why architectures as maps of real world system are
not such a good idea.

tbushell> believe there should be a fairly smooth continuim from high
tbushell> level to low level of detail.

piercarl> Why?

tbushell> Why not? ;-) (Don't know what you're asking here...)

I am asking for any argument to support the statements you make. You
support your observations with reference to "my gut feeling", "Or so I
believe", and "I believe there should be".

This is all fine, but then you should provide some argument as to why
your gut feelings or beliefs are; for they are about some points where
plausibility can work either way, and it's hard to trust one's own
instincts in such matter.

pcg> But OO is in large part about this: the ``high level''
pcg> modules/classes/prototypes are supposed to capture the essence of
pcg> the design. Pointing some sort of OO program browser to a program
pcg> source and removing from the picture the lower levels of
pcg> abstraction *ought* to reveal the design. This *ought* to be the
pcg> case with structured programming methods in general, and with OO in
pcg> particular it should be even more pleasant because of the
pcg> disciplined modularization of the program it entails.

tbushell> Absolutely!  But why doesn't it work out that way?

Because achieving this requires hard thinking. This is typically beyond
the state of the art.

Or perhaps because the rather vague statements by those who believe in
``silver bullets'', in particular those with ``real world modeling'' on
them, mean that many people don't focus hard enough on the structure of
programs _as such_; there is evidence as to what is a good structure for
a model of the ``real world'', and then that this would also be a good
structure for a program. There is instead some sparse but good evidence
about what is a better structure for a program as such.

Re: What is wrong with OO ?

[Nigel Tzeng]

In article <slrn5ai5m2.9ce.harry@matilda.alt.net.au>,
Harry Protoolis <harry@alt.net.au> wrote:
>On Fri, 06 Dec 1996 09:09:54 -0500, Ralph Cook <ralph.cook@mci.com> wrote:
>>Harry Protoolis wrote:

[snip]

>Point taken, I guess what I am saying is that the hard statistical
>evidence needed doesn't exist yet. It is too early to call OO a failure,
>and given all we have is anecdotal evidence, IME the balance is on the
>positive side

FWIW In Rise and Resurrection Ed Yourdon has an excerpt from "Survey
of Advanced Technology" by Chris Pickering for the years 1991 and
1993.  

The top performer in 1991 was OO/OOPS with percentage used 3.8,
percentage succeeded 91.7 and effective penetration 3.5.

In 1993 the worst performer was OO/OOPS with percentage used 11.9,
percentage succeeded 66.3 and effective penetration of 7.9%.

As a reference Structured Methods had a 84.2 success rate in 1993.
RDBMS were the top performer of that year at 96.0 (Gee...I guess we
finally know how to write and use RDBMS eh?).

I never did bother to find the original study so I don't know the
sample size, how he gathered data and so forth.

As with all statistics YMMV.

>Harry Protoolis                              alt.computer pty ltd        

Re: What is wrong with OO ?

[Harry Protoolis]

On Fri, 06 Dec 1996 16:36:36 -0600, Robert C. Martin <rmartin@oma.com> wrote:
>In article <slrn5afin1.49v.harry@matilda.alt.net.au>, harry@alt.net.au wrote:
>
>> Despite being a 'self centered hacker' (I like that title :-)) I
>> actually agree with you Elliot. You should at least sketch your
>> architecture out after your analysis is complete, (where analysis ==
>> primary use cases), and design to it.
>
>Actually, I prefer to do much more than just "sketch it out", the architecture
>should be very well defined, and very detailed.  However, I also prefer to
>begin producing the architecture well before all the analysis is complete.
>And I prefer producing code that is conformant to the architecture - and the
>analysis - long before the architecture is complete.  
>
>In other words, I like to do them all concurrently.
>
>This doesn't mean that I *ever* code something that is not designed.
>It also doesn't mean that I design something that has not been analyzed. 
>It's just that I don't wait for *all* the analysis to be completed before
>I begin on designing the architecture.  And I don't wait for the complete
>architecture before I begin on the code.

Sure, but I tend to do a overall sketch to give me a big picture before
diving in to the detail at any point. I find this helps to size the 
problem up.

One force at this point in a project lifecycle is the need to estimate
effort. I usually use a preliminary analysis as a significant input to
the estimation process, but you can rarely afford to do very detailed
architectural work up front (prior to contract signing).

As a result I find you begin the 'natural' process with at least a
preliminary analysis. From that I tend to sketch architecture, then pick
the hardest/highest risk and begin the iterative process of detailed
analysis, architecture, design and implementation.

The initial sketch helps to give some overall uniformity to the
architecture without being a straitjacket to the process.

H
-
Harry Protoolis                              alt.computer pty ltd                 
harry@alt.net.au                             software development consultants

Re: What is wrong with OO ?

[Kenneth Mays]

I agree with the thread on the problems we have in the field of 
software engineering in OOT/OOP. You don't send students off to a 
four-year college to learn Pascal programming and then expect them to 
go into the work force programming in Smalltalk (I can't wait to see 
"Learn Smalltalk in 21 days"). Even C++ takes a different frame of 
mind than if you just came from a COBOL or RPG background.

But, a lot of this doesn't matter becasue the field is diverse. A 
person picks up a language or two under his/her belt and that becomes 
their marketable skill. Lockheed Martim still hires people based on 
AI knowledge and LISP programming background. Some companies still 
hire 8051 programmers while some hire FORTRAN programmers. Then, 
you'll get asked if you know FORTRAN-77, FORTRAN IV, or FORTRAN-90 
(when is FORTRAN FORTRAN?). We have that problem with Ada95 and 
Ada83, many engineers don't have a clue on what Ada95 is beacsue they 
are stuck on just knowing Ada83 and don't want to learn new languages.

I don't think there is anything wrong with OOD/OOT/OOP since it is 
nothing new and Apple used the concepts back in the late 1980s. Are 
we just spinning our wheels argueing about something that won't go 
away anytime soon?

Ken

Re: What is wrong with OO ?

[Todd Hoff]

Steve Heller wrote:
>   If I invented an electron microscope and 90% of people couldn't use
> it, would we blame the electron microscope or the people? In other
> words, the complexity of the job that the tool needs to do matters as
> well.

The analogy doesn't hold as an electron microscope is a specialized
tool. OO is not supposed to be a specialized tool but a general 
methodology for designing and implementing software systems.

>   Or maybe it's just taught poorly. I've been pretty successful in
> teaching OOP to people who don't know it already. 

Or the flip side, why is it so hard to learn? And if it
really takes top teachers working over extended periods 
of time with individual students to learn OO what is the chance 
of it being taught properly in the large?


-------------------------------------------------------------
tmh@possibility.com        | The loyalty of small men can be
http://www.possibility.com | bought cheaply, for greed has no
                           | pride.  - Michael Kube-McDowell

Re: What is wrong with OO ?

[Roger Vossler]

Tom Bushell wrote:
> 1. The design/implementation dichotomy that works well in other
> engineering disciplines does not map to software.
> 
> 2. The design representations advocated by the gurus are not
> appropriate or sufficient for real systems - they don't map to the
> "code" in a useful way.
> 
> Think we've got a new thread here - "What's wrong with formal design?"
> 
> -Tom
As far as point 1 is concerned, I would like to known more about
where engineering design/implementation dichotomy breaks down
with software. OTOH, I have no doubt that software could use
a strong dose of engineering discipline.

Concerning point 2: wow, is this ever true. I read the books and
papers by the gurus and then program using several different
languages, frameworks, IDEs, etc. with the result that it takes
real work to bridge the gap. A lot of arm waving takes place
between OOA/D and working with a real system.

Roger Vossler, vossler@csn.net

Re: What is wrong with OO ?

[Harry Protoolis]

On 7 Dec 1996 07:28:21 GMT, Harry Protoolis <harry@matilda.alt.net.au> wrote:
>
>Sure, but IME if you can write software, you can't be an 'architect' period.
                      ^^^
Oops, I mean 'can't' (of course) :-)

H
-
Harry Protoolis                              alt.computer pty ltd                 
harry@alt.net.au                             software development consultants

Re: What is wrong with OO ?

[Steve Heller]

Todd Hoff <tmh@possibility.com> wrote:

>Steve Heller wrote:
>>   If I invented an electron microscope and 90% of people couldn't use
>> it, would we blame the electron microscope or the people? In other
>> words, the complexity of the job that the tool needs to do matters as
>> well.

>The analogy doesn't hold as an electron microscope is a specialized
>tool. OO is not supposed to be a specialized tool but a general 
>methodology for designing and implementing software systems.

  All programming is difficult. Programming is a specialized task,
which implies the need for specialized tools. Designing good libraries
is even more difficult than writing good programs, and it requires
talents in addition to those needed for application programming.
Therefore, library design should be done primarily by specialists.
This will make the job of the application programmer easier, not
harder.


>>   Or maybe it's just taught poorly. I've been pretty successful in
>> teaching OOP to people who don't know it already. 

>Or the flip side, why is it so hard to learn? And if it
>really takes top teachers working over extended periods 
>of time with individual students to learn OO what is the chance 
>of it being taught properly in the large?

  I haven't had an "extended period" to teach OO, if by that you mean
more than a couple of months. Of course, the students will have to
apply what they learn in the real world in order to be truly fluent
with their new knowledge, but this is true of any applied field.
  However, the necessity for good teachers is a real constraint, since
it appears that many "OO teachers" don't understand it very well
themselves. Another part of the problem is poor textbooks that don't
give enough background and depth so that the students can really grasp
the fundamentals; I'm doing what I can to fix that.



Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller 

Re: What is wrong with OO ?

[Snowball queries]

Todd Hoff wrote:

> Or the flip side, why is it so hard to learn? And if it
> really takes top teachers working over extended periods
> of time with individual students to learn OO what is the chance
> of it being taught properly in the large?

It is NOT hard to learn. What is hard is how to UNLEARN. I have been
teaching OO for a long time and the problem IS that we have learned
procedure orientation first, which interferes a lot with OO teachings.
Though it is such an awkward modeling, we spend years and years learning
it, then stick to it as it were the ten commandmends. I discovered that
I can teach OO to children very quickly whereas sometimes it takes a
considerable amount of time to initiate professionals to OO. 
OO is much more closer to the human thinking and reasoning process than
the procedure oriented approach. Good OO teachers first explain well why
procedure orientation is a historical accident, and they convince their
audience as to why procedure oriented approach is in fact a terribly
inefficient way of modeling large systems. Then they introduce OO.

Tansel Ersavas
RASE Inc.
mailto:tansel@deep.net
http://www.rase.com/

Re: What is wrong with OO ?

[Todd Hoff]

Piercarlo Grandi wrote:

> Perhaps the reverse: if the tools were really advanced, perhaps
> including a program generator (and despite claims to the contrary no
> such thing has been yet produced), then high level design activity would
> be almost all the project.

If you mean a magic machine that eats a spec and
spits out perfect code for a target then you are right,
no such thing has been produced. But i have created many 
times, as have others, domain specific languages where 
custom made code generators can be plugged in that automate
large chunks of a system. Programmers can specify what
they want in the language and a few people in the project
can work on the code generators for the features. Works
like a charm. Unfortunatetly it is not "coding" so most
managers and programmers see such approaches as a
waste of time.

-------------------------------------------------------------
tmh@possibility.com        | The loyalty of small men can be
http://www.possibility.com | bought cheaply, for greed has no
                           | pride.  - Michael Kube-McDowell

Re: What is wrong with OO ?

[Art Schwarz]

!> People who have been a part of varied programming teams have often
!> learned that good programmers program well in any language.  Bad
!> programmers program poorly in any language.

And the same applies to 'designers' and 'design methodologies'. Too
often a good design methodology is condemned by a bad design and a
bad design methodology is advanced by a good design.

Re: What is wrong with OO ?

[Tom Bushell]

On 6 Dec 1996 07:08:24 GMT, harry@matilda.alt.net.au (Harry Protoolis)
wrote:

>IMHO, the trick with OO design is to do it *informally* most of the
>time. What I mean by this is that you sketch out high level architecture
>and analysis results as high level class diagrams and then give them to
>the 'implementors' to design and code.
>
>The implementation team then does design as a series of informal
>gatherings around a white board drawing state diagrams, detailed class
>diagrams, object diagrams etc. You then photocopy and file the
>whiteboard drawings and let the same group of people code from the
>hand drawn design.

Interesting!  How many projects have you done this way?


>I then quite often reverse-engineer the resulting code and call *that*
>the formal system design.

Can you give a rough estimate of the level of effort required to do
this reverse engineering, as a percentage of total project effort?  I
assume you believe this is more cost effective than doing a more
formal design up front.


>My point is that the *design* and the *code* come into existance
>together. To talk about the design becoming the code implies that it
>exists before the code in some sense.

Doesn't this contradict your previous description of the informal
process you follow - the first "design" is the hand drawn sketches,
which you then give to your coders, who will probably modify the
design as they code.  So it _does_ exist before the code.

Some interesting semantic issues here - what is meant by "design" and
"code"?  The biggest distinction I tend to make is that a "design"
artifact is at a higher level of abstraction, and not runnable;
whereas "code" is runnable, and at the lowest level of abstraction.  I
may have to reconsider these definitions - they tend to blur together
with the tools I'm proposing.


>I think that a facinating tool would be a language sensitive drawing
>tool in which you could switch your view between diagrams and code and
>write 'code' in either view.

This is very much as I envision it.  What set me down this road of
thought was my experience doing high level design for the Prograph
class library, which was developed here in Nova Scotia.  Prograph is a
truly visual language *at the code level*, not just a GUI builder
tacked onto an evolved version of FORTRAN, like VB/VC++/Delphi et al.
This experience opened my eyes to what is possible.  If the "code" is
a "diagram", then the "design" is just another diagram at a higher
level of abstraction, and it should be possible to move back and forth
at will.

Interestingly enough, another local person, Randy Giffen, has
developed a browser that lets you take existing textual Smalltalk code
and display it visually, and modify it or write new code totally
within the visual environment.  He says he hardly ever looks at the
textual code any more - it's easier to write in the visual mode, and
it's easier to understand existing code that way as well.  Haven't had
a chance to play with it yet, but the demo he gave was _very_
impressive!

So, the pieces are all there, someone just has to put them together.

-Tom




----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Tom Bushell]

On Fri, 06 Dec 1996 11:18:43 -0500, Mukesh Prasad
<mprasad@dma.isg.mot.com> wrote:

>
>In practice, I have seen a shortened version,
>the "backward spec", i.e. specifications done
>from implemenations (with modifications as required)
>work very well in certain cases.  Much better than the
>strict "implement exactly from spec" approach.

The problem is that with current tools available to the average
developer, this is a manual step.  Most shops don't have the
discipline to do it, so we end up with the current situation - the
only accurate description of the system is the code, which is at too
low a level of abstraction to easily develop system level
understanding.


>I believe these less top-down approaches work better
>because in a lot of cases, at specification time
>the product is very vaguely understood.  Moreover,
>many implementation problems are not anticipated well.
>An actual, physical implementation can sharpen everybody's
>hazy understanding to the point where actually good design
>decisions can be made.  

Agree 100%.

>Thus doing the spec from an
>initial implementation, and fixing the implementation
>to match the final spec, can yield much
>better results overall.

Even better - eliminate the spec/implementation dichotomy.  The spec
is just an "outline", if you will, of the implementation, and remains
as an intregal part, automatically tracking the implementation and
instantly viewable at any time.

I don't see any reason why we can't do this - to use Fred Brook's
terms, it's just an "accidental" complexity, not an an "essential"
one.

-Tom


----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Tom Bushell]

On Fri, 06 Dec 1996 14:45:05 -0600, Roger Vossler <vossler@csn.net>
wrote:

>Then, when you understand what you are doing, commmit
>to the CASE swamp of your choice.
>
>The problem is that people first buy a killer tool chest and spend
>large numbers of hour understanding how to use the beast and even
>more hours stuffing a data base only to discover thay they have
>created a big mess.

Agreed.  But I think there _may_ be additional, perhaps more
fundamental problems:

1. The design/implementation dichotomy that works well in other
engineering disciplines does not map to software.

2. The design representations advocated by the gurus are not
appropriate or sufficient for real systems - they don't map to the
"code" in a useful way.

Think we've got a new thread here - "What's wrong with formal design?"

-Tom



----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "piercarl" == Piercarlo Grandi <piercarl@sabi.demon.co.uk> writes:
piercarl> Or perhaps because the rather vague statements by those who
piercarl> believe in ``silver bullets'', in particular those with ``real
piercarl> world modeling'' on them, mean that many people don't focus
piercarl> hard enough on the structure of programs _as such_; there is
piercarl> evidence as to what is a good structure for a model of the
         ^
	 |
      little
piercarl> ``real world'', and then that this would also be a good
piercarl> structure for a program. There is instead some sparse but good
piercarl> evidence about what is a better structure for a program as
piercarl> such.

Re: What is wrong with OO ?

[Ell]

Harry Protoolis (harry@matilda.alt.net.au) wrote:
: Robert C. Martin <rmartin@oma.com> wrote:
: >
: >However, I also prefer to
: >begin producing the architecture well before all the analysis is complete.
: >And I prefer producing code that is conformant to the architecture - and the
: >analysis - long before the architecture is complete.  
: >...
: >It's just that I don't wait for *all* the analysis to be completed before
: >I begin on designing the architecture.  And I don't wait for the complete
: >architecture before I begin on the code.
 
: Sure, but I tend to do a overall sketch to give me a big picture before
: diving in to the detail at any point. I find this helps to size the 
: problem up.

I think the word "overall" is key here vs. what is said immediately above
it.  Overall meaning, as I see it, at least covering all points percieved
to be major.  In my and others experience, no "new" application production
coding should go on before having done overall application analysis and
architecture.  This helps to avoid unnecessary re-work among other
benefits.

Elliott

Re: What is wrong with OO ?

[Todd Knarr]

In <32a98036.46416970@news.nstn.ca>, tbushell@fox.nstn.ns.ca (Tom Bushell) writes:
>1. The design/implementation dichotomy that works well in other
>engineering disciplines does not map to software.

>Think we've got a new thread here - "What's wrong with formal design?"

I think the problem with formal design goes right to your point #1,
since in most other enginerring disciplines there *isn't* the strong
dichotomy between design and implementation. Think about an architect
designing a bridge, and how much he has to know about the actual
construction methods and materials involved to come up with a design
that can be built without falling down. No self-respecting architect
or mechanical engineer would, for instance, decide that stone is pretty
and would fit well with the landscape but arches and intermediate
support pylons wouldn't, so "we'll build a 1000 foot stone bridge as a
single span with no arches under it".

All too often, though, the "systems analysts" hand me a design document
which I'm supposed to implement which is exactly the programming
equivalent of that 1000-foot single-span stone bridge.

--
Todd Knarr : tknarr@xmission.com      |  finger for PGP public key
                                      |  Member, USENET Cabal
***** Unsolicited commercial e-mail proof-read at $50/message *****

Seriously, I don't want to die just yet.  I don't care how
good-looking they are, I! don't! want! to! die!"
                                        -- Megazone ( UF1 )

Re: What is wrong with OO ?

[Nick Leaton]

Piercarlo Grandi wrote:

> Perhaps the reverse: if the tools were really advanced, perhaps
> including a program generator (and despite claims to the contrary no
> such thing has been yet produced), then high level design activity would
> be almost all the project.

Available now, called a programer.
-- 

Nick

Re: What is wrong with OO ?

[Nick Leaton]

> If you mean a magic machine that eats a spec and
> spits out perfect code for a target then you are right,
> no such thing has been produced. But i have created many
> times, as have others, domain specific languages where
> custom made code generators can be plugged in that automate
> large chunks of a system. Programmers can specify what
> they want in the language and a few people in the project
> can work on the code generators for the features. Works
> like a charm. Unfortunatetly it is not "coding" so most
> managers and programmers see such approaches as a
> waste of time.

Sometimes this can be a superb techinique. For example interfacing
with a DB. Write a schema file. Your code generator spits out code
from the schema file. If you have a bug in your design, it is easy
to change the generator, and fix all the relavent code. 

-- 

Nick

Re: What is wrong with OO ?

[Ell]

Todd Knarr (tknarr@xmission.com) wrote:
: In <32a98036.46416970@news.nstn.ca>, tbushell@fox.nstn.ns.ca (Tom Bushell) writes:
: >1. The design/implementation dichotomy that works well in other
: >engineering disciplines does not map to software.
 
: >Think we've got a new thread here - "What's wrong with formal design?"
 
: All too often, though, the "systems analysts" hand me a design document
: which I'm supposed to implement which is exactly the programming
: equivalent of that 1000-foot single-span stone bridge.

The role of the system architect(s) is to translate analysis into physical
design.  It's nice when the analysts know, but any self-respecting
architect should definietly know about technical building materials.

Elliott

Re: What is wrong with OO ?

[Tom Bushell]

On 08 Dec 1996 18:44:08 +0000, piercarl@sabi.demon.co.uk (Piercarlo
Grandi) wrote:

>tbushell> I agree that the effort is useful.  But my gut feeling is that
>tbushell> with better (and apparently undiscovered, as yet) processes
>tbushell> and tools, the high level design activity should be about 10%
>tbushell> of the total project, not around 50%.
>
>Perhaps the reverse: if the tools were really advanced, perhaps
>including a program generator (and despite claims to the contrary no
>such thing has been yet produced), then high level design activity would
>be almost all the project. 

Good point, although I suspect the bulk of the effort would be in what
is currently called "detailed" design.  This is what I would like to
see happen.  

>However designing a bridge and building it are not a good analogy for
>analysis/design and vs. coding; more like an analogy for all three of
>analisys/design/coding vs. execution.

I _think_ you are saying you believe _building_ a bridge is analogous
_executing_ a program.  If so, my reply would be that executing a
program is more like opening a bridge to traffic - construction is
complete and it has been turned over to it's intended users.

>Well, my impression is exactly the opposite: that the design of material
>entities like a new car or an airplane model requires immense amount of
>money and time, as compared to almost any software project, and as many
>iterations, and as much debugging, if not more, and then there are as
>many *design* bugs (as opposed to manufacturing defects) in the finished
>products. 

You may be right.  I've never seen any statistics on how much of the
new product development effort can be attributed to design, but I know
it is significant.

>tbushell> Also, the OO design models I've studied don't seem to be very
>tbushell> good maps of actual real world systems - there seems to be a
>tbushell> big gap between high level architecture and running code.  I
>
>This is a good reason why architectures as maps of real world system are
>not such a good idea.

Interesting point.  If you are saying that architecture/civil
engineering are perhaps not the best fields to look to for
inspiration, I'm starting to agree with you.  Seems there may be more
profit in looking to mechanical engineering and biology - both deal
with much more dynamic real world objects.  A software system is more
like a machine or an organism than like a bridge.  Thanks for that
insight!

>
>tbushell> believe there should be a fairly smooth continuim from high
>tbushell> level to low level of detail.

The point I was trying to emphasize was my perception that there seems
to be a big chasm between the high level design models currently
advocated, and running code.  Perhaps this is why "over the wall"
processes fail - only the architect has enough understanding to make
the leap, so he/she must also implement.

This makes me suspect one or more of the following are true:

1. Current high level design models are inappropriate
2. Additional high level design models are required to supplement
existing models
3. "Intermediate" design models are required to bridge the gap between
high level and detailed design/coding.

>I am asking for any argument to support the statements you make. You
>support your observations with reference to "my gut feeling", "Or so I
>believe", and "I believe there should be".

Quite deliberate choice of words on my part.  My intuitions are
_usually_ correct, which has served me well in predicting
technological trends.  But I have only my limited experience to go on
with modern design methodologies, and was trying to get some harder
data, or at least anecdotal evidence to substantiate or refute my
hunches.

>tbushell> Absolutely!  But why doesn't it work out that way?
>
>Because achieving this requires hard thinking. This is typically beyond
>the state of the art.
>
>Or perhaps because the rather vague statements by those who believe in
>``silver bullets'', in particular those with ``real world modeling'' on
>them, mean that many people don't focus hard enough on the structure of
>programs _as such_; there is evidence as to what is a good structure for
>a model of the ``real world'', and then that this would also be a good
>structure for a program. There is instead some sparse but good evidence
>about what is a better structure for a program as such.

Again, a good point.  I read this to mean you might be in agreement
with my point #2 above about current models being insufficient.
Perhaps we should be using software patterns to constrain the
allowable design models that can be produced, so they will be more
likely to be implementable.  

-Tom



----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Matt Kennel]

Nick Leaton (nickle@calfp.co.uk) wrote:
: Piercarlo Grandi wrote:

: > Perhaps the reverse: if the tools were really advanced, perhaps
: > including a program generator (and despite claims to the contrary no
: > such thing has been yet produced), then high level design activity would
: > be almost all the project.

: Available now, called a programer.

Exactamundo.   The 'tool' is known as a "programming language". 

I don't understand the obsession with "high level design tools" outside
programming languages. 

Programming langauges *are* the proper "high level design tool", and despite
seeming fuddy-duddy and old-fashioned, progress in programming language has
always been, and will continue to be, the most potent means to deliver the 
fruits of research to programmers. 

If you take as an axiom that "humans will always have to make some decisions"
then this conclusion will follow.

The real improvements in programming come when interesting new concepts are
made into technology. 

: -- 
: Nick

--
Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ 
  I would not, could not SAVE ON PHONE,    |==================================
  I would not, could not BUY YOUR LOAN,    |The US Government does not like
  I would not, could not MAKE MONEY FAST,  |spam either.  It is ILLEGAL!
  I would not, could not SEND NO CA$H,     |USC Title 47, section 227
  I would not, could not SEE YOUR SITE,    |p (b)(1)(C) www.law.cornell.edu/
  I would not, could not EAT VEG-I-MITE,   | /uscode/47/227.html
  I do *not* *like* GREEN CARDS AND SPAM!  |==================================
               M A D - I - A M!

Re: What is wrong with OO ?

[Alan Meyer]

In article <58lbbo$8kl@news.xmission.com>, tknarr@xmission.com wrote...
   <<snip>>
>All too often, though, the "systems analysts" hand me a design document
>which I'm supposed to implement which is exactly the programming
>equivalent of that 1000-foot single-span stone bridge.

I once visited a large municipal government computing shop with 130 people 
working there.  I was told by the boss that as far as he's concerned, his
"systems analysts" are to do all the thinking and his programmers, he
called them "coders", are just supposed to translate those lofty thoughts
into code.  He then thought that the reason the average programmer only
stayed 18 months (remember that's the average, I wonder what the good ones
were doing!) was because that was the nature of the business and programmers
were defective people anyway!

I personally believe that the division into "analysts" and "programmers" is
a dangerous one.  If a person can't do both he is likely to do a lot of harm
to a project.  An "analyst" that doesn't understand programming will often
specify impractical designs.  A "programmer" that can't understand the
needs of the users will often build unusable programs.  The best systems
always come from people who make it their business to understand the total
problem from the point of view of the user, the point of the view of the
machine, and everything in between.

Re: What is wrong with OO ?

[Frederick Sickert]

Robert C. Martin wrote:
> 
> In article <slrn5afin1.49v.harry@matilda.alt.net.au>, harry@alt.net.au wrote:
> 
> > On 6 Dec 1996 03:26:57 GMT, Ell <ell@access4.digex.net> wrote:
> > >Richie Bielak (richieb@calfp.com) wrote:
> > >
> > >The point as far as I'm concerned is that an architecture should guide
> > >_all_ coding.  That is even if the initial architecture is later modified,
> > >or later scrapped.
> >
> > Despite being a 'self centered hacker' (I like that title :-)) I
> > actually agree with you Elliot. You should at least sketch your
> > architecture out after your analysis is complete, (where analysis ==
> > primary use cases), and design to it.
> 
> Actually, I prefer to do much more than just "sketch it out", the architecture
> should be very well defined, and very detailed.  However, I also prefer to
> begin producing the architecture well before all the analysis is complete.
> And I prefer producing code that is conformant to the architecture - and the
> analysis - long before the architecture is complete.
> 
> In other words, I like to do them all concurrently.
> 
> This doesn't mean that I *ever* code something that is not designed.
> It also doesn't mean that I design something that has not been analyzed.
> It's just that I don't wait for *all* the analysis to be completed before
> I begin on designing the architecture.  And I don't wait for the complete
> architecture before I begin on the code.
> 
> --
> Robert C. Martin    | Design Consulting   | Training courses offered:
> Object Mentor       | rmartin@oma.com     |   Object Oriented Design
> 14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
> Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
> 
> "One of the great commandments of science is:
>     'Mistrust arguments from authority.'" -- Carl Sagan

I think Jacobsen's book, Object Oriented Software Engineering, outlines
a very useful approach. He looks at the Analysis, Design and
Implementation phases as building models. The analysis model is closest
to the problem domain. The implementation model is the code, and so is
heavily dependent on the implementation environment, and the design
model bridges the two. Each model evolves. Each model can be worked on
independantly. There is no requirement that one model be completed
before working on the others, just that the models should be reconciled
eventually.

Re: What is wrong with OO ?

[David Bradley]

nigel@access5.digex.net (Nigel Tzeng) wrote:

>FWIW In Rise and Resurrection Ed Yourdon has an excerpt from "Survey
>of Advanced Technology" by Chris Pickering for the years 1991 and
>1993.  
>
>The top performer in 1991 was OO/OOPS with percentage used 3.8,
>percentage succeeded 91.7 and effective penetration 3.5.
>
>In 1993 the worst performer was OO/OOPS with percentage used 11.9,
>percentage succeeded 66.3 and effective penetration of 7.9%.

My guess is that a greater percentage of people using OOP in 1991 had
a better understanding of it than those 1993.  It doesn't mean OOP is
a failure, just that you have more people in 1993 entering OOP and you
have the training curve to deal with.

Unfortunately they jumped into the OOP pool without first learning how
to swim.  They may have taken a lesson or two and could hold their own
in calm waters, but when things get rough they drown.  In stead of
realizing they lack knowledge and accepting the responsibility for
their failure they point the finger at OOP.

--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com

Re: What is wrong with OO ?

[Don Harrison]

Roger Vossler wrote:

:I have no doubt that software could use
:a strong dose of engineering discipline.

It already exists. It's called "Design by Contract" a la Eiffel. :)

That alone is not sufficient, of course. There are many other factors that
can be brought to bear in the development of high quality software, not the
least of which are common sense and discipline.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Ell]

mj@sjx-ixn10.ix.netcom.com>
Organization: The Universe
Distribution: 
Alan Meyer (ameyer@ix.netcom.com) wrote:
: In article <58lbbo$8kl@news.xmission.com>, tknarr@xmission.com wrote...
:    <<snip>>
: >All too often, though, the "systems analysts" hand me a design document
: >which I'm supposed to implement which is exactly the programming
: >equivalent of that 1000-foot single-span stone bridge.
 
: I once visited a large municipal government computing shop with 130 people 
: working there.  I was told by the boss that as far as he's concerned, his
: "systems analysts" are to do all the thinking and his programmers, he
: called them "coders", are just supposed to translate those lofty thoughts
: into code.  He then thought that the reason the average programmer only
: stayed 18 months (remember that's the average, I wonder what the good ones
: were doing!) was because that was the nature of the business and programmers
: were defective people anyway!

Quite a narrow minded manager.
 
: I personally believe that the division into "analysts" and "programmers" is
: a dangerous one.  If a person can't do both he is likely to do a lot of harm
: to a project.  An "analyst" that doesn't understand programming will often
: specify impractical designs.  A "programmer" that can't understand the
: needs of the users will often build unusable programs.  The best systems
: always come from people who make it their business to understand the total
: problem from the point of view of the user, the point of the view of the
: machine, and everything in between.

How about the formulation of an architecture to span the gap?  This may or
may not require someone who's called an architect.

Elliott
 

Re: What is wrong with OO ?

[Samuel S. Shuster]

Todd Hoff,

 >OO is not supposed to be a specialized tool but a general 
 >methodology for designing and implementing software systems.

  Maybe that's a problem in and of itself. Maybe OO is supposed to be a
specialized tool, but has been inappropriately hyped so much that too many
people think that it is supposed to be E-Z.

  Let's look out to the side a moment. VisualBasic. Certainly it's one of those
"EveryMan" tools. But why does it fail so bad on large enterprise systems, and
in particular why does it fail so bad when the system requires large groups of
interacting subsystems and interaction between developers and testing and even
worse for maintenance?

  I've got an opinion as to why. VisualBasic does not promote a disciplined
approach to development. I hold that in fact it promotes a cowboy attitude. In
order to get to the large system with all that goes with it with VisualBasic,
one not only has to diligently apply an external discipline, one has to fight
the tool in order to do so!

  What OT (or any methodology does) is define a discipline. Is it a general
methodology? Yes. But a methodology none the less, and as such, demands that
discipline be used in order to see any benefit from it. Lip service doesn't do
it. Knowledge alone doesn't do it. Doing it, with rigor, is the only way.

  So, if OT has failed in any way, it is in not stopping the hype that allows
people to perceive that OT is just some kind of E-Z solution to all their
problems.

  Is OT a better discipline for developing large systems? I believe so, but I
don't believe that this is the debate here.

  A better question is, has Structured/Procedural Technology failed? If we only
judge by looking in the context of how the majority of procedural
tools/languages are used, then in my opinion, Yes. It has failed miserably... in
my further opinion, it has failed worse than OT.

  However, if we look and judge by when the rigor of the discipline of
Structured/Procedural technology is used, then I believe it has succeeded fairly
well.

  Further, if we look and judge Object Technology in terms of a rigor &
discipline, I believe it to be successful also.

  Finally, we come to the comparison. When we look and judge by rigor &
discipline, and then finally _add_ in effectiveness and then compare, then I
believe OT is comparatively more successful.

  But to reiterate, this all depends, deeply, on the fact that OT isn't a
belief, isn't simply the understanding of three concepts (Encapsulation,
Inheritance and Polymorphism), isn't even simply the correct applying of these
and related concepts.

  It is a discipline. It is a discipline like all other disciplines that in
order to be successful must be applied. Applied rigorously. In my opinion,
anything less is not Object Technology... It's the lip service of the self
anointed experts whom I wouldn't trust to design my cat's upchucked hair
balls... even from a fresh example.

  So, what's wrong with OO? What's wrong is people who think they should be able
to see the structure of molecules with a High School Microscope, and are then so
overwhelmed when someone says "It takes a powerful electron microscope, bub, and
you'll have to learn how to use one, and apply some discipline in order to get
the results you need"

  TANSTAAFL. The biggest problem facing the software community is the too
widespread belief that Object Technology is a free lunch.
                                And So It Goes
                                     Sames

============================================================================
sshuster@parcplace.com
ParcPlace-Digitalk
Consultant
All opinions are my own.
============================================================================

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "nickle" == Nick Leaton <nickle@calfp.co.uk> writes:

nickle> Piercarlo Grandi wrote:

pcg> Perhaps the reverse: if the tools were really advanced, perhaps
pcg> including a program generator (and despite claims to the contrary
pcg> no such thing has been yet produced), then high level design
pcg> activity would be almost all the project.

nickle> Available now, called a programer.

  rmartin> In another case, I have worked with a client who had a bunch
  rmartin> of "architects" doing nothing but drawing pretty Booch
  rmartin> diagrams and then throwing them over the wall to a bunch of
  rmartin> programmers.  The programmers hated the architects and
  rmartin> ignored what they produced.

Unfortunately, no matter how intensely so many managers wishfully think
so (note that I am implying that you are a ``suit'' or that you
wishfully think so, just that such wishful thinking is common among
them), programmers are not "tools", and often not even "really advanced"
ones :-).

That programmers are not tools is indeed the reason which explains
Robert Martin's observation that tossing buble diagrams over the wall
does not work.

Re: What is wrong with OO ?

[Dr. Richard Botting]

From the point of view of a hypothetical software engineer:
	Someone who takes a project from the user's griping
	thru to implementation, maintenance and a nice fee:-)

Implementations of
OO share a defect with a number of earlier methods and
methodologies:-
	Optimism.

By which I mean that there is no apparent part of many OO methods
that signals that the problem you are trying to solve is
going to be hard until it is too late.

Very few methods (in any paradigm) have a step that says:  Don't use this 
method.  Whereas I have come to believe that a step like this is essential.

Similarly I am suspicious of software development processes or
methods (or methodologies) that don't have a step that works out
prior prior to coding that the design has a high chance of satsfying
the user. Performance, maintenance, usability, ...????

And so, I prefer approaches that allow one to collect and organize
data about the problem... not the solution, so that I have the
figures to be able to make sure my ideas will work.
--
dick botting     http://www.csci.csusb.edu/dick/signature.html
Disclaimer:      CSUSB may or may not agree with this message.
Copyright(1996): Copy freely but say where it came from.
	I have nothing to sell, and I'm giving it away.

Re: What is wrong with OO ?

[Tom Bushell]

On Tue, 10 Dec 1996 23:17:33 -0600, Roger Vossler <vossler@csn.net>
wrote:

>As far as point 1 is concerned, I would like to known more about
>where engineering design/implementation dichotomy breaks down
>with software. 

Tried to explain this in another post - hope it makes sense!

>OTOH, I have no doubt that software could use
>a strong dose of engineering discipline.

My belief as well.  Just think we have to choose carefully what we
steal from other disciplines.

>Concerning point 2: wow, is this ever true. I read the books and
>papers by the gurus and then program using several different
>languages, frameworks, IDEs, etc. with the result that it takes
>real work to bridge the gap. A lot of arm waving takes place
>between OOA/D and working with a real system.

Glad I'm not the only one with bruises from the leap. (And as others
have related, sometimes it's more like a Roadrunner cartoon - that
looooong plummet to the bottom of the canyon...)

-Tom



----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Tom Bushell]

On 11 Dec 1996 03:55:36 GMT, tknarr@xmission.com     ( Todd Knarr )
wrote:

>I think the problem with formal design goes right to your point #1,
>since in most other enginerring disciplines there *isn't* the strong
>dichotomy between design and implementation. 

Guess I wasn't clear about what I meant by "dichotomy".  I was
referring to the fact that in current practice, the design and the
implementation are almost always distinct artifacts.  The "design" is
a text, drawings, equations, or whatever.  The "implementation" is
runnable code.  Designs are models - static, abstract, incomplete -
not usable except as a precursor to implementation.  Implementations
are dynamic, tangible, detailed - usable in the real world.

If you accept this description, then there *is* a dichotomy in most
other enginering disciplines as well - the design for a car is the
blueprints, mockup, etc.  The implementation is the drivable car.

This dichotomy may make sense for other engineering disciplines, who
must convert the design (which is information, or "bits", to use
Negroponte's term) into "atoms".  But for software, it's all bits,
from design to implementtion!  I'm merely speculating that the
dichotomy may only exist in software because the disciplines we're
thinking about emulating do it that way.  

Perhaps this is a fundamental mistake, and we need to think of design
as an outline, or a scaffold, or a foundation, or whatever other good
analogies we can come up with, as opposed to a "model".  Perhaps then
we will not face so much difficulty and resistance to formal design,
because it will become obvious that this is a worthwhile activity.


>All too often, though, the "systems analysts" hand me a design document
>which I'm supposed to implement which is exactly the programming
>equivalent of that 1000-foot single-span stone bridge.

This is a very valid point, but in my mind a different issue (although
related).  In other parts of this thread, we've been talking about the
"gap" between design and code - the sense that there's a big leap of
abstraction between current design models and implementable systems.

I'm not really happy with the way I've explained this, and not even
sure I believe my own explanations, but will let it stand  until
something better occurs to me.

-Tom  (practicing semantics without a thesaurus _or_ a license)



----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[drush]

Elliot (Ell@access1.digex.net) wrote:
>I'd like to know what it is the "object gurus" have said/done, or haven't
>said/done that makes you two distrust them to design systems.  It
>certainly wouldn't be for lack of experience as virtually all of the ones
>I know of have extensive experience in medium and large system
>development. 

Actually, my contention (as was the original poster's IIRC) was with the
local, self-proclaimed, object-gurus. Most of the people who have published
books seem to have learned enough to be worth listening to. 

The local toads, OTOH, I have found to be unable to listen[1], unable to value
ideas that did not originate with them[2], unable to code (either cleanly or
efficiently[3])... On the gripping hand, every discipline has its own set of
power games: right now objects are hot, so they attract this kind of behavior.

>Do you all have any objections to object gurus other than that most of
>them see OO in the real world, or human cognition?  Do you all object to
>the way most object gurus emphasize that planning should lead coding? 
>What what concretely is you alls beef?

Regarding Objects & "real-world" modeling: I have also seen this as primarily
a political ploy. Yes there are objects in the real world, but (nearly) as soon
as you start doing analysis you are working in an abstracted realm. The real
question is how to structure your abstractions, and that can frequently be
done in many different ways.

The "real-world" is the system that you're replacing. To inflict that structure
on the system you're designing can be a *BIG* mistake.

Happy Hackin'
	david rush
	mailto:kumo@intercenter.net
	flamesto:/dev/null

	I bill $100/min for reading commercial e-mail.


[1] Once I asked the same question, three times in three different ways of
    the same individual. Each time I got the same 20 minute lecture which
    did not answer my question, but consisted on an exposition of his pet
    project. BTW - I was finishing/maintaining an OOP project that was 2
    *years* over schedule that he'd designed, and then gotten bored with.

[2] My boss at the time developed a great strategy, that I have yet to be
    able to perfect - he got the self-proclaimed (his own words) "Object Head"
    to come up with the same design ideas through very careful coaching.

[3] Same OH, designed & implemented a server process that used 12 threads
    internally (where he architecturally could have used 3), by missing an
    essential design idea from having never built server-side software
    before. He got the OOA all wrong, but it was thouroughly OO...and the
    cross object interactions still made the thing unmaintainable. After two
    years of maintaining this thing that *never worked right* I finally got
    him to realize that he had botched the design. It was too late, he was
    advocating a framework change where we would no longer need it.

Re: What is wrong with OO ?

[Harry Protoolis]

On 11 Dec 1996 01:39:48 GMT, Ell <ell@access4.digex.net> wrote:
>Harry Protoolis (harry@matilda.alt.net.au) wrote:
>: Robert C. Martin <rmartin@oma.com> wrote:
>: >
>: >However, I also prefer to
>: >begin producing the architecture well before all the analysis is complete.
>: >And I prefer producing code that is conformant to the architecture - and the
>: >analysis - long before the architecture is complete.  
>: >...
>: >It's just that I don't wait for *all* the analysis to be completed before
>: >I begin on designing the architecture.  And I don't wait for the complete
>: >architecture before I begin on the code.
> 
>: Sure, but I tend to do a overall sketch to give me a big picture before
>: diving in to the detail at any point. I find this helps to size the 
>: problem up.
>
>I think the word "overall" is key here vs. what is said immediately above
>it.  Overall meaning, as I see it, at least covering all points percieved
>to be major.  In my and others experience, no "new" application production
>coding should go on before having done overall application analysis and
>architecture.  This helps to avoid unnecessary re-work among other
>benefits.

Sure, as long as you don't get too bogged down in it. There is a very
real danger that if you spend too long doing 'overall' architecture
you wind up with pipe dreams. My rule-of-thumb is that overall
architecure should consist of a small (say < 10) number of fairly
simple diagrams. You should be able to get it across to the project team
in a single ~ 1 hour presentation.

Harry

Re: What is wrong with OO ?

[Nick Leaton]

: I once visited a large municipal government computing shop with 130
people
: working there.  I was told by the boss that as far as he's concerned,
his
: "systems analysts" are to do all the thinking and his programmers, he
: called them "coders", are just supposed to translate those lofty
thoughts
: into code.  He then thought that the reason the average programmer
only
: stayed 18 months (remember that's the average, I wonder what the good
ones
: were doing!) was because that was the nature of the business and
programmers
: were defective people anyway!

And the analyst spend more time telling the programmers what to do than
it takes to produce the code, and since the actual coding is a small
part of the overall time it is not suprising they have a high staff
turnover.
-- 

Nick

Re: What is wrong with OO ?

[Nick Leaton]

>   I've got an opinion as to why. VisualBasic does not promote a disciplined
> approach to development. I hold that in fact it promotes a cowboy attitude. In
> order to get to the large system with all that goes with it with VisualBasic,
> one not only has to diligently apply an external discipline, one has to fight
> the tool in order to do so!

It also fails because it is 'visual'. People think building the UI is
building the system. Building a model is not the usual disciplined
approach taken with VB. You can do this with VB, but I haven't seen 
many examples.

-- 

Nick

Re: What is wrong with OO ?

[Ronald Servant]

Harry Protoolis wrote:

> [...]. My rule-of-thumb is that overall
> architecure should consist of a small (say < 10) number of fairly
> simple diagrams. You should be able to get it across to the project team
> in a single ~ 1 hour presentation.

Now, what size of a project are you talking about?  Are taking about 
the problem domain model or the actual architectual solution to that
problem domain?

I believe I understand and agree with your point, but when you use a
number like 10 it makes me wonder.

Ron.
--
Ronald Servant                   | (613) 763-9662 [ESN 393]
GSF Framework, PCN Technology    | rservant@nortel.ca (work)
Nortel, Ottawa                   | rservant@magmacom.com (personal)

Re: What is wrong with OO ?

[matt]

Well, there must be something wrong with OO, 
because over half of the postings in this group 
debate the very existance of OO.

My own feeling is that:  What is it about building
software in 1996 that is different from building
factories in 1936, so that a new design paradigm
must be invented?  Did factory components have reuse, 
did their components have interfaces separate from 
implementation, did they have a class hierarchy?

If they didn't, why didn't they?  If they did then
how did they build these things without Booch and
company?

Matt Young

Re: What is wrong with OO ?

[drush]

ObOOPSelfCongratulation: I'm finding this thread to be *very* interesting.
                         Thanks, everyone.

Samuel Shuster wrote:
>  However, if we look and judge by when the rigor of the discipline of
>Structured/Procedural technology is used, then I believe it has succeeded
>fairly well.
>
I'm glad to see someone else saying this for a change. Good programming
practices don't change just because the technology changes. Using 
smalltalk (your-OOPL-here) means that you don't spend as much time 
implementing the  infrastructure used to support good practices. Or it
should.

>  Further, if we look and judge Object Technology in terms of a rigor &
>discipline, I believe it to be successful also.
>
No argument here. (the preceding sentence was included as flame-proofing
material.)

>the lip service of the self anointed experts whom I wouldn't trust to
>design  my cat's upchucked hair balls... even from a fresh example.

Please, don't hold back. Tell us how you *really* feel.

I *like* object gurus.

On toast.

>  TANSTAAFL. The biggest problem facing the software community is the too
>widespread belief that Object Technology is a free lunch.

Damn straight. I'm really sick of this industry's tendency to look for
"silver bullets." Good code for a big problem takes time to develop.

ObWorry: Are patterns going to turn into the next silver bullet buzzword?
         I hope not. But I do find them useful for speeding the 
         discussion of design ideas.

<twitter, mumble, blecch> (Smalltalkin')
	david rush
	mailto:kumo@intercenter.net
	flamesto:/dev/null

	I bill $100/min for reading commercial email

Re: What is wrong with OO ?

[Ell]

drush@zakalwe.raleigh.ibm.com wrote:
: Samuel Shuster wrote:
: >the lip service of the self anointed experts whom I wouldn't trust to
: >design  my cat's upchucked hair balls... even from a fresh example.
 
: Please, don't hold back. Tell us how you *really* feel.
: 
: I *like* object gurus.
: 
: On toast.

I'd like to know what it is the "object gurus" have said/done, or haven't
said/done that makes you two distrust them to design systems.  It
certainly wouldn't be for lack of experience as virtually all of the ones
I know of have extensive experience in medium and large system
development. 

Do you all have any objections to object gurus other than that most of
them see OO in the real world, or human cognition?  Do you all object to
the way most object gurus emphasize that planning should lead coding? 
What what concretely is you alls beef?

Elliott

Re: What is wrong with OO ?

[Dan Stubbs]

In article <58s1uo$4m2@sun.sirius.com>,  <matt@mail.siruis.com> wrote:
>Well, there must be something wrong with OO, 
>because over half of the postings in this group 
>debate the very existance of OO.
>
I don't think that anybody ever claimed that OO was the answer to every
problem. The claim is that in some (perhaps many) situations it is a
very powerful approach. It is a paradigm that allows one to reuse
existing software that is provided in the form of objects. The reuse
mechanism is inheritance. 

Reuse is certainly not new. But one of the primary reuse methods prior
to OO was the reuse of operations (usually in the form of functions or
procedures.) There are currently libraries of FORTRAN procedures for
scientific applications that are undoubtedly superior to anything
available in any language or supported by any other paradigm.

Reuse using inheritance from objects is certainly different than reuse
of operations. One difference is that you inherit both the operations
and the data types acted on by those operations. The two form a
tightly coupled unit. Reuse with procedures usually means finding
the exisiting procedures that, when applied to your data, solve
your problem.

With objects you are designing an object (that solves your problem)
based on other existing objects that may involve a hierarchy with several
levels. Objects are made much more powerful by supporting generics
(at compile time) and polymorphism (at run time).

The nice thing about Ada95 is that its interface to these object
mechanisms is much cleaner and easier to use than is the case for
other languages that support OO.

There is no doubt that the OO paradigm is very different than, for
example, the procedural paradigm. The problem is that the notions of
object, inheritance and polymorphism while beautiful in their 
simplicity are also difficult because of their subtleties.

There are many internet addresses that provide object libraries. Some
of them are free--some are expensive. 

My inclination is to give an example here, but this is already rather
long so I will defer to see if there is any interest.

>My own feeling is that:  What is it about building
>software in 1996 that is different from building
>factories in 1936, so that a new design paradigm
>must be invented?  Did factory components have reuse, 
>did their components have interfaces separate from 
>implementation, did they have a class hierarchy?
>
>If they didn't, why didn't they?  If they did then
>how did they build these things without Booch and
>company?
>
>Matt Young

Re: What is wrong with OO ?

[Ell]

drush@zakalwe.raleigh.ibm.com wrote:
: Elliott (Ell@access1.digex.net) wrote:
: >Do you all have any objections to object gurus other than that most of
: >them see OO in the real world, or human cognition?  Do you all object to
: >the way most object gurus emphasize that planning should lead coding? 
: >What what concretely is you alls beef?
 
:Regarding Objects & "real-world" modeling: I have also seen this as primarily
:a political ploy. Yes there are objects in the real world, but (nearly) as soon
:as you start doing analysis you are working in an abstracted realm. The real
:question is how to structure your abstractions, and that can frequently be
:done in many different ways.

True, yet I see that some designs more closely express the nature of
domain semantics than others.  Why not go with the closer ones?  They
should be easier to maintain down the line, as they are more intuitive.
 
:The "real-world" is the system that you're replacing. To inflict that structure
:on the system you're designing can be a *BIG* mistake.

Sometimes we want to mirror an existing "real-world" manual process, and
at others we want to utilize domain abstractions to create new systems. 
In either case hewing close to domain semantics offers at the very least
greater understandability for developers and maintenance staff.  In my
experience and observations nearly any design based on "real world"
semantics can be made to have minimal dependency between its parts.  And
thus be a practical, highly usable design.

: Happy Hackin'

Well Halloween celebration for "Hack-ula" just passed, but your sentiments
are clear.  :-}

Elliott

Re: What is wrong with OO ?

[Chris]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]


Kazimir Majorinc <kmajor@jagor.srce.hr> a �crit dans l'article
<58b9jt$jhh@bagan.srce.hr>...
> Hello!
> 2. Encapsulation, I mean that both data and functions are together in
> object seems to me like very unnatural shape today. Look at
> mathemathics. Mathematical language do not use that paradigm, although
> things which are described there are more complex than any software.  

that's because what you can with types in mathematics is not a finite
state. What you can do with objects (classes) is supposed to be known and
finite.

> ... If I overload operators, for
> example + in C++, I have disgusting when I use object model, and I have
> to prefer first element, when there is absolutely no reasons for that.

That's why we should use friend functions...

> 3. Polymorphism. The greatest part of OO. I understand wish, but look at
> C++. Why if I want to do this things, I have to do it implicitely. I
> mean why functions which overload each other should have same name? It
> is better to do it explicitely, to say which function is overload of
> which. Now things could be simpler. I do not know how to do it in
> procedural paradigm, but I believe that it is somehow possible.

Because at an abstract level, you may want different (derived) objects do a
certain stuff without caring with how it will be performed (like a base or
overloaded way).
 
> 6. Messages. I do not know a lot of this, but Idea that object change
> himself alone remembers me at the days of programming on TI57, or in
> assembler, when every instruction is on so called accumulator. OO wants
> accumulator back.
???


-- 
Chris, drunk philosoph and bad programmer
"The nail pulling up calls the hammer"
                                     zen proverb

Re: What is wrong with OO ?

[Chris]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]


Jeff Miller <jmiller@probe.net> a �crit dans l'article
<32A7B9BC.52C71CEF@probe.net>...
> Effective reuse is substantially a management issue, not a technical
> one. OO helps, but organizational and process changes are more
> important.

I agree, but OO (design and implementation) will force a minimum of reuse
even if for best reusability, we have to think about it.


-- 
Chris, drunk philosoph and bad programmer
"The nail pulling up calls the hammer"
                                     zen proverb

Re: What is wrong with OO ?

[Chris]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]


H Brett Bolen <brettb@cpcug.org> a �crit dans l'article
<589i82$g1k@cpcug.org>...
> I don't believe I getting involved with this.  Anyway here's my
> thoughts:
> 
> What are the 'Big Three' fundimental concepts with OO?
> 
> They are 
> 
>   Inheritance 
>   Polymorphism 
>   Encapsulation
I'd say :
   Encapsulation
   Inheritance 
   Polymorphism 
> I think that Inheritance struggles against Encapsulation.
And I don't think, because private (strictly encapsulated) members in base
class are unreachable for derived classes. Other stuffs like friends,
protected or public should not be used unless they are needed (and they
often are).

-- 
Chris, drunk philosoph and bad programmer
"The nail pulling up calls the hammer"
                                     zen proverb

Re: What is wrong with OO ?

["Paul E. Bennett"]

In article <32aefdb0.406273038@news.nstn.ca>
           tbushell@fox.nstn.ns.ca "Tom Bushell" writes:

> On 11 Dec 1996 03:55:36 GMT, tknarr@xmission.com     ( Todd Knarr )
> wrote:
> 
> >I think the problem with formal design goes right to your point #1,
> >since in most other enginerring disciplines there *isn't* the strong
> >dichotomy between design and implementation. 
> 
> Guess I wasn't clear about what I meant by "dichotomy".  I was
> referring to the fact that in current practice, the design and the
> implementation are almost always distinct artifacts.  The "design" is
> a text, drawings, equations, or whatever.  The "implementation" is
> runnable code.  Designs are models - static, abstract, incomplete -
> not usable except as a precursor to implementation.  Implementations
> are dynamic, tangible, detailed - usable in the real world.
> 
> If you accept this description, then there *is* a dichotomy in most
> other enginering disciplines as well - the design for a car is the
> blueprints, mockup, etc.  The implementation is the drivable car.

Perfect! I am glad that someone else seems to share my views on this.
 
> This dichotomy may make sense for other engineering disciplines, who
> must convert the design (which is information, or "bits", to use
> Negroponte's term) into "atoms".  But for software, it's all bits,
> from design to implementtion!  I'm merely speculating that the
> dichotomy may only exist in software because the disciplines we're
> thinking about emulating do it that way.  

I have no problem in supporting the dichotomy. To me a Software design 
is the source listing, which we will all pore over in review meetings 
and structured walkthroughs, and this is the detailed instructions which 
will enable someone to perform the implementation phase (like handing the 
schematics, PCB layouts, components lists and assembly instructions to the 
equipment manufacturer).
 
> Perhaps this is a fundamental mistake, and we need to think of design
> as an outline, or a scaffold, or a foundation, or whatever other good
> analogies we can come up with, as opposed to a "model".  Perhaps then
> we will not face so much difficulty and resistance to formal design,
> because it will become obvious that this is a worthwhile activity.

Design exists at several levels in all engineering worlds. Concept Design, 
Prototype Design, Product Design, Industrial Design, Detail Design. Which 
level you need to be dealing with depends on how far thorugh your design 
lifecycle you are and what you are designing.
 
> >All too often, though, the "systems analysts" hand me a design document
> >which I'm supposed to implement which is exactly the programming
> >equivalent of that 1000-foot single-span stone bridge.
> 
> This is a very valid point, but in my mind a different issue (although
> related).  In other parts of this thread, we've been talking about the
> "gap" between design and code - the sense that there's a big leap of
> abstraction between current design models and implementable systems.
> 
> I'm not really happy with the way I've explained this, and not even
> sure I believe my own explanations, but will let it stand  until
> something better occurs to me.

If someone wants a 1000-foot single-span stone bridge you can build a 
structure in exotic materials and stone clad it. As long as the customer 
has not visited the site during construction he will never know. I believe 
that we might call this "information hiding" in software.

This thread has been a particularly long one for me to read today (as I have 
just returned to my system after a period away working) and all participants 
have contributed a mixture of interesting ideas and notions, some of which I 
can relate to easily.

We are all going to need a whole range of tools and paradigms to enable us 
to grasp the essentials of what our customers want from the systems we build 
for them. One thing we should all learn from the disasters that have occurred 
in IS design is that failure of projects is a failure of the management of 
the project. The projects that are successful, despite their use of "bleeding 
edge" technology and very difficult concepts are those in which project 
management has been very effective in maintaining discipline and rigour of 
application in the teams.

Choosing an appropriate "lifecycle" model and tools that enable the easy 
support of such a lifecycle would seem to be more worthy than arguing over 
which language a project should be done in. I would hope that we all agree 
that the language should suit the application area and use concepts natural 
to that domain (Application Specific Languages).

The Critical Failure Factors for any project are:

Hostile Culture (in the development or client organisation)
Poor reporting structures [a most important issue to get right]
Over commitment
Political Pressures
Under-estimated Complexity of problem domain (during initial phases)
Poor Consultation
Inappropriate Application (ie: Technical fix for management problem)
High Staff Turnover
Poor Staff Competency
Poor Communication
Inadequate Testing and Validation
Inadequate User Training
Insufficient Review Stages

[the above list is taken "Software Failure: Management failure" by Stephen 
Flowers published by John Wiley and Sons ISBN 0-471-95113-7 and describes many 
IS systems which failed for one reason or another.]

The question therefore is how do we avoid thos CFF's?

You will notice that one item that does not appear in the list is Changing 
Requirements. This is a fact of life for engineers of all disciplines.   
Engineers have to be good at dealing with changes to the requirements and 
manage them in an orderly manner. Rather than spend money on CASE tools why 
not buy a decent Change Management Software Package.

-- 
Paul E. Bennett <peb@transcontech.co.uk>
Transport Control Technology Ltd.
+44 (0)117-9499861
Going Forth Safely

Re: What is wrong with OO ?

[Kazimir Majorinc]

\x1eTansel Ersavas (tansel@deep.net) wrote:

: 1. "The cancelled projects with money down the drain" is not a part of
: the OO problem, but a general IS one. I know two 100 million projects
: cancelled after 5 years of great hopes, money and sweat, and they
: weren't OO projects. Every year, hundreds of BILLIONS of dollars are

Ubelievable. For that money I could do anything they want. Simulation of 
whole world economy? No problem! Programming language more complicated than
C++? No problem! I do not understand? I can not imagine problem which can not
be solved with that money, except if it comes from mathematical world.


: 3. I am not a particular fan of the RAD approach. It doesn't imply OO,
: in fact, OO is only later tucked on to it. RAD is Today's techniques
: applied to Yesterday's organization structure. OO is not essential to
: the RAD, and If RAD fails, the failure can not be attributed to its
: tucked on OO component.

Yeah, neither I.



: Anyway, I think that for OO to succeed, there are certain prerequisites.

: 1. People and the organization that they are in
: 2. Proper techniques (such as OO)
: 3. Tools 

..........

Unfortunately, OO is based on completely wrong principle. If it succeed, it 
would be on costs which are several times bigger than on procedural paradigm.
Which does not mean that it will not succeed commercialy. There are several
wrong, although attractive possibilities of OO. Example: If type B is
succesor of type A, in that case neither overriding nor polymorphism have
no sense. If B requires different procedure than A, which should be more
general it means that B is not specialisation of A. I say, complet chaos,
which could look nice, like it looked to me before 3 years.

_______________________________________________
Author: Kazimir Majorinc, Zagreb, Croatia
E-mail: Kazimir.Majorinc@public.srce.hr
        kmajor@public.srce.hr (slightly better)
http:   //public.srce.hr/~kmajor (~7min to USA)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
One who knows the secret of the 7th stair

Re: What is wrong with OO ?

[Tansel Ersavas]

Kazimir Majorinc wrote:

> 
> Unfortunately, OO is based on completely wrong principle. If it succeed, it
> would be on costs which are several times bigger than on procedural paradigm.

Compared to what? Procedure orientation? Can you tell me why we program
in procedures, what is so absolute about it? In fact the biggest mistake
is that we program in procedures. It is one of the biggest problems of
this Century. Please read my prev. postings about what's wrong with
procedure orientation.

> Which does not mean that it will not succeed commercialy.

I wouldn't bet on it.

> One who knows the secret of the 7th stair

But not OO


Tansel

Re: What is wrong with OO ?

[Robert C. Martin]

In article <58aj6t$1ch@news3.digex.net>, ell@access2.digex.net (Ell) wrote:

> Piercarlo Grandi (pcg@aber.ac.uk) wrote:
> : "rmartin" == Robert C Martin <rmartin@oma.com> writes:
> : > Harry wrote 
> : >> In fact IMHO an OO team has no place for anyone who cannot do all
> : >> three tasks. [Analysis, Design, and Implementation]
>  
> : > Agreed, emphatically.
> 
> It seems you all are not considering all factors here.  For instance,
> because someone is a good Java programmer does not necessarily mean they
> are good at working with users to formulate analysis, or that they have
> good architectural skills for medium sized or large projects.  And vice
> versa.

If you define an analyst as someone who deals with users and defines
requirements, then I agree with you.  However, such an analyst does not
produce high level partitionings of software structure.  He is unconcerned
with the technology of OO.  Rather he produces a cogent set of requirements
for systems that will solve users problems.

On the other hand, if you define an analyst as the person who interprets
a set of requirements and begins to divine the structure of the software that
will implement those requirements, then I disagree with you.  For that talent,
the ability to translate a requirement to a software structure, is the same
for all levels of software design.

Granted, the higher levels require more experience and talent to resolve,
than the lower levels.  But the intrinsic operation of translating
requirements into software structure is the same.  IMHO.

> : Architecture, as you have so many times argued, is extremely important,
> : and the implementor that is not guided by sound architectural
> : principles, by close interaction with analisys and design, is not going
> : to do a nice implementation.
> 
> If you are speaking of Martin, he has only accepted that project coders
> should be required to follow architecture within the last 6 months
> (partially at my urging).  WRT analysis he has never to my knowledge
> accepted that an overall analysis should be done at the outset of a
> project and that it should lead the creation of project architecture. 

Elliott, I have asked you many times before, and I will ask you once again,
not to put words in my mouth.

I have no idea where you got the 6 month number from.  And believe me, the
only thing your urging has given me is sore fingers from the immense amount
of typing that I have had to do to respond to all your misquotes and misuses
of my words.

No code should be produced without an architecture and a design to direct
it.  However, no architecture or design should be produced without code
to verify that it is correct.  At frequent intervals, designers should
commit their (probably unfinished) designs to code to verify that they
can be implemented and that they work.  Those designs can then be built
upon, improved, and extended.  The process is iterative and evolutionary.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Jeff Miller]

Kazimir Majorinc wrote:
> 
> \x1eTansel Ersavas (tansel@deep.net) wrote:
> 
> : 1. "The cancelled projects with money down the drain" is not a part
> : of the OO problem, but a general IS one. I know two 100  million
> : projects : cancelled after 5 years of great hopes, money and sweat,
> : and they weren't OO projects. Every year, hundreds of BILLIONS of
> : dollars are
> 
> Ubelievable. For that money I could do anything they want. Simulation
> of whole world economy? No problem! Programming language more
> complicated than C++? No problem! I do not understand? I can not
> imagine problem which can not be solved with that money, except if it
> comes from mathematical world.

Near the beginning of "The Mythical Man Month" an interesting
observation is made: Since we so often hear about the stunning 
success of one or two programmers working at the kitchen table,
why is it that all software is not written that way? Why is it that
corporations continue to build these crazy, wasteful, failure-prone
development departments when all they really needed to do was stuff
a couple of talented programmers in a garage for a few months?

There are lots of reasons, and I would refer the interested reader
to the book (something *anyone* in software development should read!),
I won't go into it here, but the details have to do with the geometric
growth of communication paths while the staff count is increasing
linearly.

Anyway, you would be amazed at how easy it is to tear through $100
million. Most commercial software projects are not of the nature you
implied. Problems like developing compilers and writing simulations
are nicely contained. The big dollar projects you hear about tend
to have enormous user interfaces, potentially hundreds of database
tables, be distributed on a global basis, involve complex communication
and coordination requirements, and require the sort of confirmed
reliability associated with computer systems that are managing millions
and sometimes of billions of dollars.

                                             Jeff Miller
                                             Senior Server Architect
                                             CSG Systems, Inc.
                                             jeff_miller@csgsys.com
                                             jmiller@probe.net

Re: What is wrong with OO ?

[Robert C. Martin]

> Todd Hoff wrote:
> > 
> > If i invented a hammer and 90% of people couldn't use
> > it correctly would we blame the hammer or the people?
> > It seems those who've "got" OO blame the people. Maybe we
> > should blame the hammer. Maybe OO just won't work in
> > the mass market of building applications. Not that it
> > can't, but that it doesn't work often enough to make it
> > universally appropriate.

I think this depends upon your expectations.

If you expect that OO is the solution to the so called "software crisis"
that will make all software projects fast and simple, and eliminate
all major bugs; if you expect that OO will allow junior engineers to
rapdily gain the skills of experienced designers; if you think that 
older styles of software are completely obsolesced by the far superior
technology of OO; then you will certainly be disapponted.   OO does
not meet those expectations.

However, if you expect that you can use the technology of OO as a tool
to help you manage the interdependencies between software modules in 
order to make software architectures that are reusable, resilient, and
maintainable; then you will probably not be dissapointed.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Robert C. Martin]

In article <32A8B86C.48BB@hiwaay.net>, crispen@hiwaay.net wrote:

> 
> The go/no-go question that MUST be asked of an OO design
> (the fruits of an OO methodology or process) is not "Does
> this design scrupulously adhere to the tenets of our
> particular sect of OOD?" but rather "Is this a GOOD DESIGN?"
> 

Well said.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Robert C. Martin]

In article <32AA207E.3199@deep.net>, tansel@deep.net wrote:

> There are three major reasons why OO projects fail. All of them are
> stated by the great wisdom of Jedi in "Star Wars".
> 
> These are:
>     "Do or do not. There is no try"
>     Using my tools and techniques, I can prove you that I can produce
>     better and faster systems using OO (Please read my notes at the end
>     of this message). If I can do it, so you can.If you just try to do
>     it, you will fail. Be determined to do it.

There is something to this.  However, OO will not work just because
you are determined.  You must understand the mechanisms that make it work,
and you must know what those mechamisms can, and cannot do.

In some sense OO has attracted programmers the way that new weight
loss methods attract people who want to lose weight.  They will grasp
at anything new to solve their problems.

OO is a great technique and it can help make software easier to reuse,
modify and maintain.  But it is not a cure-all; and it must be understood
in detail and weilded with skill.
> 
>     "You must unlearn what you have learned"
>     People cling so heavily to the baggage they have been carrying, 
>     they can not have an open mind about OO. SO the first thing I do
>     in my training sessions is to create doubts and  questions about 
>     the problems of the procedural approach, and why procedure
>     orientation is a very ineffective technique for most new problems.
>     Of course, you should have a very good mentor that is capable of
>     demonstrating these in practical terms. 

Although I agree with your sentiment, I disagree with your terminology.
We don't really want to unlearn anything.  We want to integrate the new
tools and mechanisms of OO into our practices.  
> 
>     "You must believe in what you are doing"
>     OO will help you. It will feel awkward at times, but you must
>     persist with it. You will be eventually rewarded.

You can't just believe without evidence.  That evidence can be 
empirical. But there are so few controlled experiments that reliable
empirical evidence is hard to find.  Or the evidence can be in the form
of a believable rationale.  One that can be tested with thought experiements.

---------

OO is not a motivational discipline.  It does not take willpower and
determination to "do things right".  Rather it takes knowledge and skill.



> 
> Coming to the question of "What is wrong with OO" the question should
> read "What are the problems in the current state of OO that slows down
> it's progress". 
> 
> There three major problems that slows down OO.
> .  Lack of expertise, personal and team skills (human issues)
> .  Lack of fast, efficient and practical tools-environments that make
>    programming one of the the most labor-oriented, miserable works
>    available Today
> .  Lack of practical OO application techniques and ways that will
>    integrate OO with other succesful paradigms
> 
> Current state of OO suffers from all of the above. Each and every one of
> these problems are soluble, Indeed as a company, we are working on and
> have at least intermediate solutions for all of them. 
> 
> BTW I get a much better response for OO from children. For that reason,
> I'll offer educational versions my tools and techniques to schools so
> that children can be exposed to these techniques before their minds are
> clutterd by the current dominant paradigms.
>  
> Tansel Ersavas
> RASE Inc.
> mailto:tansel@deep.net
> http://www.rase.com/

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Tansel Ersavas]

I have got an e-mail that grilled me a bit about some of my words  (2nd
part of the reply). In case other people thought along similar lines, I
am posting a slightly modified version of my reply here as well. 

> Kragen wrote:
> 
>> Tansel Ersavas wrote:
>> Before we discuss 'what is wrong with OO', shouldn't we discuss what is
>> wrong with the current popular paradigm, procedure orientation.
 
> I'd be interested to hear what you have to say on that.  Could you
> forward me your previous posting to comp.object about the subject?
> 

Unfortunately I accidentally deleted my original posting to comp.object
that you requested. But I'll restate some of the key points here:

What is wrong with Procedure orientation?

You may well know the story I am about to tell you at least I'm sure you
know parts of it. But it is so easy to forget, so I'll have to restate
here, because it is essential for us to know where we are coming from to
be able to see where we are going.

Procedure orientation is not invented as an optimal solution to our
problems. It was designed to be the answer of the original question of,
and original design purpose of the modern computer.

Do you remember why the original computer was invented? The key to why
we have procedure orientation as our main modeling tool in computers
lies in the answer.

The ancestor of all modern computers is ENIAC, designed after EDVAC.
EDVAC was one of the first computers designed, but had several problems.
Designers of ENIAC were working to solve these problems. 
The problem at hand for compters to solve was: There were people
(sometimes called computers, literally!) whose entire duty was to
perform a series of calculations on a huge amount of data. Such as
payroll, or bank account updates. Sure, there were IBM Hollerith card
processors that could automate this process, but they weren't flexible
enough.

During the design process, the design team asked Dr. John von Neumann,
one of the most respected mathematicians and computer figures of the
day, his ideas, along with EDVAC's and their proposed design. 
The memo von Neumann sent them back became a legendary paper and
influenced virtually all computer architecture beginning with ENIAC,
and, from then on became known as the von Neumann architecture. 

One of the key points of his suggestion was to use binary, instead of
the decimal system EDVAC was using. After investigating the problem, he
suggested, as they were trying to automate a person doing manual
calculations, a design involving a central processing unit (cpu) and a
memory. In this design, the cpu would replace (or automate) the person.
CPU would have an arithmetic-logic unit (alu) replacing the mechanical
calculator that the person was using. His or her short term memory would
become the registers, and the paper that kept the intermetiate results
(data) as well as the instructions (program) became the memory (Hence,
stored program machine).

To program a von Neuman machine one would need to supply instructions in
form of simple, imperative sentences, such as LOAD register with this
value, or AND 1 with the register. Since the aim of ENIAC was to
automate a human computer, nothing elaborate was needed. The simple
imperative sentences in form of op-codes (which tell the cpu what to do)
and operands (passive data, or a reference to tell the computer with
what) were organized in procedures. All one had to do was to invoke the
necessary procedure to perform that task. Such a simple and elegant
design.

SO THE MODERN COMPUTER WAS NOT DESIGNED TO BE A GENERAL PURPOSE
PROGRAMMING MACHINE. IT WAS A SPECIFIC MACHINE WITH A SPECIFIC TASK IN
MIND.

Up to now, I guess most people know the story. However, what's not
widely known is von Neumann's objections to other invented uses of the
system. When people saw that they would do a lot more than simple
calculations, and they started developing applications that would be far
beyond its intended use, Von Neumann repeatedly warned them, and
indicated that the use of this architecture anything beyond
simple-serial operations would be totally inappropriate. However, no one
wanted to hear his warnings. After all, they had such a wonderful
machine that could do anything. No one noticed that things would be
exponentially more complex when one tried to program more with that
machine. Von Neumann, in vein, started to design a new computer, but
died long before he could finish it. His last work 'The Computer and the
Brain' states his objections to the architecture ironicaly named after
him, while he was frantically working towards a different type of
computer (much like a brain) to be able to deliver these people the
right platform for what they wanted to do.

It is essential that we have to understand John von Neumann's
reservations about the architecture he designed himself. After all, he
was the only authority at that time who could understand the limitations
of his architecture. John von Neumann died while still writing his last
book. This book is now very difficult to find anywhere. However, in my
opinion, it should be read by everybody before writing even one line of
procedural code. His dire warnings about abusing this machine beyond
simple, serial operations are totally ignored, then forgotten.

<... the other stuff was related to what is the alternative (OO), and
what are the precursors for succeeding>

> >   programming one of the the most labor-oriented, miserable works
> >   available Today
> 
> I must violently disagree with you on this point.  I have stuffed
> tacos at Taco Bell; I have taken phone reservations for Super 8
> Motels; I have washed dishes and made sandwiches in a cafe; I have
> mixed tons of bubblebath, put it into bottles, put the bottles into
> boxes, and stacked the boxes on pallets.  All of these things I have
> done in the last two years.
> 
> Also, for the last year, I have spent part of my time administering a
> network, doing tech support, and teaching people about UNIX, and part
> of my time programming.  I assure you, programming is much less
> labor-intensive than any of my non-professional jobs, and even less
> labor-intensive than the other things I do now.
> 
> And miserable!  You have no *clue* what miserable is if you think
> programming is miserable.  I am happier programming than in any other
> part of my job, but *any* part of my job is infinitely better than
> when I was manufacturing bubblebath.  I don't have to do any of the
> following:
> 
> - work with detergent on my hands in an environment that's below freezing
> - risk falling into a vat of bubblebath with a spinning propeller mixing it
> - fight with 450-pound drums of mildly toxic chemicals
> - work 13-hour days of moving 25-pound boxes
> - clean up enormous bubblebath messes on the floor
> - get paid $5 an hour
> - work in an 85-dB ambient noise environment
> - never see the sun
> 
> But let me tell you something.  That bubblebath-factory job is
> infinitely better than the jobs many of the people in America have,
> and even *those* jobs are infinitely better than the jobs most of the
> people in Bangladesh have.
> 
> I think you owe an apology.  I think you have no business declaring
> that your job's misery is near that of mining coal or sewing clothes
> in sweatshops.
> 

I think you are right. I got carried away a bit. If I offended you by
saying that, I sincerely apologize. 

Perhaps, I can not choose words very well, after all English is a
second, and a relatively new language to me. Being born in a thirld
world country, and working in a metal factory counting bolts, brushing
bolts with metal brushes, and visually inspecting parts, and being paid
$5 a fortnight, I'm well aware of the conditions you're mentioning. 
I'll try to make myself clearer by stating what I actually tried to say
when I used the words "labor oriented" or "miserable".

The phenomenal success of computers is actually a big time bomb ticking.
Today, failed projects total about HUNDREDS of BILLIONS of DOLLARS every
year. No one will admit it, because they think that it has to be like
this. Software must be problemmatic. This waste of money is in my
opinion totally unnecessary and should be stopped right now. Talk about
the impact of this money to the misery of us here and the third world. 

I have personally witnessed a $100 Million project collapse after 5
years of effort, and closely followed another very similar project
collapse with $120 Million down the drain. These are your and my money
wasted. I simply can not tolerate it any more, and if I am using strong
language (sometimes inappropriately), I am sorry, but I don't
think that we have this luxury to throw money away.

When I am working in a project in a big organization that makes $1,5
Billion profit a year, if a project costs $10 Million, where I can see
it could cost far less than $1 Million and can't do anything about it,
then forgive me, but I am more miserable than the days I was counting
bolts. Not for myself, as a consultant I am paid very high $$, and work
far less than 13 hours a day in an air conditioned room. I should be
quite happy, the more chaos out there, the more people will seek my
services, and the more expensive I'll be. In fact people in my position
have been enjoying enormous rate increase. If you go to a place in
crisis, and make things only 20% better, you save them good money. But
this is the chaos they chose to be in it in the first place, and in the
long term, doesn't benefit any of us.

And, labor intensive: yes. This doesn't mean "hard labor", but it is
still labor. In fact people would like to think that programming is a
mind intensive operation, having had signatures under million line code
systems, IMO programming is an extremely labor intensive task, compared
to what it should have been. 
When you are using Unix, I am sure you realize how many man-years were
spent to deliver you that system. The system I'm using has software on
it (is a simple notebook with Win 95) has an incredible amount of effort
put on it just for people like me to be able to perform a number of
operations.

The most complicated structure on Earth became software since the MVS
operating system was declared just that in terms of its moving parts.
What does the MVS operating system do? Move mountains? No. Could it be
done much simpler? Yes. 

I still believe that we are more productive when we are stuffing taco
shells then when we are doing programming (I Just wish taco shell
fillers were paid accordingly). If we had to cook the shell, prepare the
sauce, and chop the salad every time, then it would be closer to
programming. In fact taco filling is a very component oriented visual 
assembly work with a level of maturity and sophistiction, it can only be
a programmer's envy. We still have years to catch the same technology. 
The problem is we can develop software just like we fill taco shells, 
and we don't. The awe that is created for us in computers in terms of
complexity is just a reflection of seeing a paste formed by leaving a
taco in a blender for a couple of minutes while it is running, instead
of a taco. It is not a virtue to create complex structures. The actual
virtue is to be able to do it as simple as possible.

My point there was to try to grab people's attention to investigate the
bridge they are on first, and see its collapse, before stoning the other
bridge that is currently their only savior.

This is a long issue, and takes days (even months) to fully explain my
point of view. I'm ready to answer all your questions as much as I can. 

Finally, I think we can all disagree, even strongly, but please not
violently

> Peace,

Always...

Tansel Ersavas
RASE Inc.
mailto:tansel@deep.net
http://www.rase.com/

RE: What is wrong with OO ?

[Patrick Ma]

On 12/14/96 Robert C. Martin <rmartin@oma.com>  wrote:

>OO is not a motivational discipline.  It does not take willpower and
>determination to "do things right".  Rather it takes knowledge and skill.

Robert,

	Without a doubt, it takes knowledge and skill to "do things right" in OO.
However, I do think OO is a discipline and it does take willpower and 
determination together with knowledge and skill to "do things right."

	Often, things were done wrong but not corrected even when they are
discovered because they were 
	1. done by higher ranked developers,
	2. done for a while or in too many places,
	3. insert your favorite scenarios.

	It is willpower and determination of OO discipline that is going to lead us to 
break through these hurdles created by our very own minds. 

------------------------------------------------------------------------
Patrick Ma                              < pma@partssolution.com >
partsSolution, Inc.                     < http://www.partssolution.com >
IBM Certified VisualAge for Smalltalk Developer
< SmallNews - a Smalltalk UQWK editor for offline news editing >

Re: What is wrong with OO ?

[Tansel Ersavas]

Ell wrote:


> If you say that OO can be used for simulation and that SIMULA was the
> ancestor of other OOPLs and its purpose was to simulate, then how can you
> say above that modelling the real world is simply "simulation" not OO?
> 

Simulation is a technique that is used to make educated guesses about
reality.

In fact, an appealing approach for OOA would be to simulate the problem
domain to develop a better understanding of it (however, for most, this
is only in theory, because they don't have such powerful tools to
simulate the problem domain as soon as necessary details are captured
about it. Our Snowball Rapid Systems Engineering Tool can be used for
this purpose).

In the sciences, there are three basic approaches to understand the
reality. These are:
. Experimentation
. Analysis
. Simulation
Experimentation develops the best understanding in most cases, but it is
usually very expensive, dangerous, or even impossible (such as a space
shuttle journey to Mars)
Analysis is where we use mathematical techniques to model, then using
this model to predict. This works when these types of techniques are
available and practical. It also makes strong assumptions about the
model which is rarely true in the real world
Simulation is an experimentation technique where we use a simulated
model instead of the real case for the experimentation. There are
advantages and drawbacks of this approach.

There are three types of simulation:
.Continuous simulation (much like analog computers)
.Discrete simulation (such as in activity oriented or event oriented
simulation systems)
.Object oriented simulation (can be viewed as a special case of OOP,
requires time related extensions)

My point is: there are many people trying to simulate the real world and
they don't use OO. They don't need to use OO, because there are many
non-OO simulation packages (such as the continuous and discrete
simulation packages). However, IME people benefit a lot when they use OO
in large simulations. One of my assignments was to develop a financial
modeling tool that would include simulation for an insurance company,
and I used OOS with great success in that area. I was involved in a few
more projects that were simulations, or involved simulations, so I know
that it is much easier to model it in an OO environment, especially if
it is a big - complex one.

It is up to the team or the person to choose the technique that they
want to employ simulation, but I highly recommend OO for simulations.   

Tansel

-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: What is wrong with OO ?

[Todd Hoff]

Robert C. Martin wrote:
> However, if you expect that you can use the technology of OO as a tool
> to help you manage the interdependencies between software modules in
> order to make software architectures that are reusable, resilient, and
> maintainable; then you will probably not be dissapointed.

I expect a largish group of diverce yet intelligent people
to effectively deploy OO*. So far i have not seen this to be
the case.

-------------------------------------------------------------
tmh@possibility.com        | The loyalty of small men can be
http://www.possibility.com | bought cheaply, for greed has no
                           | pride.  - Michael Kube-McDowell

Re: What is wrong with OO ?

[Joseph W. Seda]

Todd Hoff wrote:
> 
> I expect a largish group of diverce yet intelligent people
> to effectively deploy OO*. So far i have not seen this to be
> the case.
> 

This means that the market is FAR from saturated.  All the
better for my company. :)

Re: What is wrong with OO ?

[Tansel Ersavas]

Robert C. Martin wrote:
> 
> In article <32AA207E.3199@deep.net>, tansel@deep.net wrote:
> 
> > There are three major reasons why OO projects fail. All of them are
> > stated by the great wisdom of Jedi in "Star Wars".
> >
> > These are:
> >     "Do or do not. There is no try"
> >     Using my tools and techniques, I can prove you that I can produce
> >     better and faster systems using OO (Please read my notes at the end
> >     of this message). If I can do it, so you can.If you just try to do
> >     it, you will fail. Be determined to do it.
> 
> There is something to this.  However, OO will not work just because
> you are determined.  You must understand the mechanisms that make it work,
> and you must know what those mechamisms can, and cannot do.
>
I know. But when you are determined, you will be much more likely to
obtain the knowledge that you need to solve your problems. 


> OO is a great technique and it can help make software easier to reuse,
> modify and maintain.  But it is not a cure-all; and it must be understood
> in detail and weilded with skill.

Agreed.

> >
> >     "You must unlearn what you have learned"
> >     People cling so heavily to the baggage they have been carrying,
> >     they can not have an open mind about OO. SO the first thing I do
> >     in my training sessions is to create doubts and  questions about
> >     the problems of the procedural approach, and why procedure
> >     orientation is a very ineffective technique for most new problems.
> >     Of course, you should have a very good mentor that is capable of
> >     demonstrating these in practical terms.
> 
> Although I agree with your sentiment, I disagree with your terminology.
> We don't really want to unlearn anything.  We want to integrate the new
> tools and mechanisms of OO into our practices.

First of all, my opinion is, developing systems with procedure oriented
techniques is a dangerous, wasteful and unproductive process. So far OO
couldn't show a quantum leap of difference, but it is not mature yet.
When I train people, I look at their background. Usually the more
experienced in the traditional techniques they are, the less they
believe the necessity of learning a new technique. In my breakthrough
courses, for the first part, I challenge the traditional ways of systems
development and show that this way of developing systems is a historical
accident, and the more we insist on going that way, the more troubles we
will be in. 

Unfortunately, with their slow and wasteful structure, big companies can
absorb huge amounts of losses without blinking. This contributes a lot
to people not realizing how big the crisis is. In fact, even many
succesful systems Today are big money wasters. 

Procedural thinking and OO are not complimentary. Procedural thinking
requires a major transformation that affects all our thinking. I know
it, because I was a procedural programming freak, starting programming
with a 6502 board with hex keypad, and being a mad assembler, C and
later C++ person. Even when I was a C, C++ person my productivity was
substantially higher than others, I couldn't make the switch to OO until
I let my strong and enjoyable procedural skills go. Now I only program
with Smalltalk (not a prerequisite to anything, just a choice), and I do
everything in a much higher level previously unimaginable to me. My
productivity increased 5 fold, and I developed a tool to further
increase it another 5 fold. Now I know that the tools and techniques I
use are anywhere from 5 to 25 times better than my old techniques
before. These techniques are pure OO but I am reaching limits of them.
Therefore I expanded my horizons to other techniques that I combine with
OO which will increase my productivity another order of magnitude.

Anybody wishing to see these techniques in action, I'm happy to
demonstrate them. It is the only proof I can show to anyone that OO
works, and works much better than anything they have seen so far. And
without unlearning, it wouldn't have been possible. 

> >
> >     "You must believe in what you are doing"
> >     OO will help you. It will feel awkward at times, but you must
> >     persist with it. You will be eventually rewarded.
> 
> You can't just believe without evidence.  That evidence can be
> empirical. But there are so few controlled experiments that reliable
> empirical evidence is hard to find.  Or the evidence can be in the form
> of a believable rationale.  One that can be tested with thought experiements.

I'll remind you of the placebo effect. IMO belief creates miracles. But
it is also true that blind faith is dangerous.

Any time a new paradigm comes around there are pioneers. They make the
bold decisions to shape the history. They are less than 1% of the
participants. Pioneers are nothing but visioners and believers. They
create their evidence, and history.
Then there come early adopters. People who don't need "empirical
evidence". Who use their intuition to make sense of what the pioneers
are pointing to.
Then there are popularizers. People are quicker than the others, just
like the people who watch the other traffic lights to see when they are
going red so that they could be the first to respond to the green light.
They require evidence, but can act very quickly. 
Then there are followers, much like people passing at the green light.
They do nothing but go with the crowd. There must be empirical evidence
for them.
Follows the conservatives, after observing the great mass, they join
resentfully
And there are resistors, they will NEVER come to the band, no matter how
succesful it is.

So, empirical evidence is important depending on who you want to deal
with. 

We need people to create this evidence at the moment, and we are
desperately short of them.

> 
> OO is not a motivational discipline.  It does not take willpower and
> determination to "do things right".  Rather it takes knowledge and skill.

Not only being an OO trainer, but a motivational trainer, I would have
to disagree here. Every training should include a motivational
component. I totally agree that knowledge and skill are paramount. The
important thing is to be able to excite people to get this knowledge and
skill. The teacher is as good as he or she can motivate the participants
to eagerly accept what he or she is offering. One of the reasons that
children learn OO quickly is they are so easily excitable. The moment
you show them something, that becomes the most important thing on Earth.
But for the grown ups (or as they are labeled by children: "given ups")
a big dose of motivation is required to grab their attention.  

In fact, I can't follow all of it, but during this discussion about
what's wrong with OO I tried to observe any excitement, but couldn't see
much of it around.

 
> Robert C. Martin    | Design Consulting   | Training courses offered:
> Object Mentor       | rmartin@oma.com     |   Object Oriented Design
> 14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
> Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
> 
> "One of the great commandments of science is:
>     'Mistrust arguments from authority.'" -- Carl Sagan


Tansel Ersavas
RASE Inc.
mailto:tansel@rase.com
http://www.rase.com/

Re: What is wrong with OO ?

[Damon Feldman]

tmh@possibility.com wrote:
>Daniel Drasin wrote:
>> 
>
>> The problems I've seen with OO projects arise not from the use of OO,
>> but from the misuse of OO.  Programmers trying to use non-OO methods,
>> incorrectly applying OO concepts, etc.

>If i invented a hammer and 90% of people couldn't use
>it correctly would we blame the hammer or the people?
>It seems those who've "got" OO blame the people

Programming is a technichal discipline and you've got to know what you're 
doing.  By the 90% rule computers themselves would be considered useless.
It's just that all of us here know how to use them.

The question is whether or not spending time teaching OO properly and then 
applying that knowledge is effective or not.  The fact that people don't use 
OO properly when they have inadequate training can't legitamately be used to 
disparage OO.

Damon

Re: What is wrong with OO ?

[Tansel Ersavas]

drush@zakalwe.raleigh.ibm.com wrote:

> Regarding Objects & "real-world" modeling: I have also seen this as primarily
> a political ploy. Yes there are objects in the real world, but (nearly) as soon
> as you start doing analysis you are working in an abstracted realm. The real
> question is how to structure your abstractions, and that can frequently be
> done in many different ways.

In fact, as soon as you start to think, you start working on abstracted
realm. It is the basis of our thinking, our understanding. We can not
grasp things as they are, because anything has almost infinite
complexity. If you want to model a chair, to model it as is in the real
world, you have to model it down to the molecules, even quarks. All of
our thinking involves abstraction. 

OO provides us with a set of tools to abstract things in the real world,
imagined worlds, or anything. We should remember that there is a
discipline which their entire aim is to model the real world as close as
possible, and this discipline is simulation, not OO. There you need your
system to match the current reality as close as possible. OO can be used
for that, better then most other techniques available Today, and in fact
guess why Simula, the ancestor of most object oriented languages was
developed. 
 
> The "real-world" is the system that you're replacing. To inflict that structure
> on the system you're designing can be a *BIG* mistake.

Depends, it may be, or it may not be. There are real world systems,
their structure can only be our envy. Like a fish. None of the human
made ships can even come close to the perfection of a fish. They run
slightly over a 1/4 th of the efficiency of a fish. Only about two years
ago, scientists were able to learn some of the secrets of efficient
swimming and hydrodynamic structure by mimicking the fish, and
observing.

However, in the man made world we call "real", there are a lot of things
you don't want to incorporate into your design. Man made systems tend to
accumulate entropy, especially through the inflicted structure of
industrial era mentality companies. There you can find amusing examples
of how things should not be done. If you model what you see there, You
won't end up with a better mess, just a faster one.

Tansel
RASE Inc.
mailto:tansel@rase.com
http://www.rase.com/

Re: What is wrong with OO ?

[Ell]

Tansel Ersavas (tansel@deep.net) wrote:
: drush@zakalwe.raleigh.ibm.com wrote:
: 
:> Regarding Objects & "real-world" modeling: I have also seen this as primarily
:> a political ploy. Yes there are objects in the real world, but (nearly) as 
:> soon
:> as you start doing analysis you are working in an abstracted realm. The real
:> question is how to structure your abstractions, and that can frequently be
:> done in many different ways.

Classes as abstractions have been the basis of OO since it started, as far
as I can tell.  Real world modelling is modelling which uses abstractions
of real world entities.  I.e. there is no conflict between real world
modelling and the use of abstractions. 

: OO provides us with a set of tools to abstract things in the real world,
: imagined worlds, or anything. We should remember that there is a
: discipline which their entire aim is to model the real world as close as
: possible, and this discipline is simulation, not OO. There you need your
: system to match the current reality as close as possible. OO can be used
: for that, better then most other techniques available Today, and in fact
: guess why Simula, the ancestor of most object oriented languages was
: developed. 

If you say that OO can be used for simulation and that SIMULA was the
ancestor of other OOPLs and its purpose was to simulate, then how can you
say above that modelling the real world is simply "simulation" not OO? 

Elliott

Re: What is wrong with OO ?

[Tansel Ersavas]

In article <58s1uo$4m2@sun.sirius.com>, matt@mail.siruis.com wrote:
>Well, there must be something wrong with OO, 

>My own feeling is that:  What is it about building
>software in 1996 that is different from building
>factories in 1936, so that a new design paradigm
>must be invented?  Did factory components have reuse, 
>did their components have interfaces separate from 
>implementation, did they have a class hierarchy?

Funny, there is a big discussion in the manufacturing industry about
"what is wrong with the manufacturing, why the techniques we have been
using for centuries don't work any more?"; especially in management.
Many other industries feel the same thing. 

The answer lies in the fundamental shift in our approach to everything.
Now we are not in the industry age. We are in the information age. Not
even manufacturing use their 1936 techniques any more. The entire world
is in transition.

Tansel
RASE Inc.
mailto:tansel@rase.com
http://www.rase.com/

Re: What is wrong with OO ?

[Todd Hoff]

Kazimir Majorinc wrote:
> \x1eTansel Ersavas (tansel@deep.net) wrote:
> : 1. "The cancelled projects with money down the drain" is not a part of
> : the OO problem, but a general IS one. I know two 100 million projects
> : cancelled after 5 years of great hopes, money and sweat, and they
> : weren't OO projects. Every year, hundreds of BILLIONS of dollars are
> 
> Ubelievable. For that money I could do anything they want. Simulation of
> whole world economy? No problem! Programming language more complicated than
> C++? No problem! I do not understand? I can not imagine problem which can not
> be solved with that money, except if it comes from mathematical world.

More money makes the situation worse as it gives the illusion
of commitment, of doing something. Building large software systems
is fundamentally a social activity, technology isn't even
a close second. With the right tribe of people i'd build a system
using carrier pigeons. If it's not the right tribe all the
money, tools, and consultants won't make a difference.

-------------------------------------------------------------
tmh@possibility.com        | The loyalty of small men can be
http://www.possibility.com | bought cheaply, for greed has no
                           | pride.  - Michael Kube-McDowell

Re: What is wrong with OO ?

[Tansel Ersavas]

Todd Hoff wrote:
> 
> More money makes the situation worse as it gives the illusion
> of commitment, of doing something. Building large software systems
> is fundamentally a social activity, technology isn't even
> a close second. With the right tribe of people i'd build a system
> using carrier pigeons. If it's not the right tribe all the
> money, tools, and consultants won't make a difference.
> 

Right on the spot. 

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
                               A.C. Clarke
-----------------------------------------------------------------------

RE: What is wrong with OO ?

[Patrick Ma]

On 12/15/96 Todd Hoff <tmh@possibility.com>  wrote:

>Building large software systems
>is fundamentally a social activity, technology isn't even
>a close second. With the right tribe of people i'd build a system
>using carrier pigeons. If it's not the right tribe all the
>money, tools, and consultants won't make a difference.

Todd,

	Exactly my thought that I have been trying to add to this thread. Thank you.
A 'tribe of people' with OO discipline, willpower and determination is the key to
a successful OO project. I wouldn't go as far as using carrier pigeons though. ;-)

	Of course, like I have mentioned earlier in this thread, knowledge and skill
are essential but discipline, willpower and determination are critical factors, too.

------------------------------------------------------------------------
Patrick Ma                              < pma@partssolution.com >
partsSolution, Inc.                     < http://www.partssolution.com >
IBM Certified VisualAge for Smalltalk Developer
< SmallNews - a Smalltalk UQWK editor for offline news editing >

Re: What is wrong with OO ?

[Bob Kettig]

In article <32B3B440.46CF@possibility.com> Todd Hoff,
tmh@possibility.com writes:
>
> More money makes the situation worse...
> ...
> With the right tribe of people I'd build a system using carrier pigeons.
> ...
> The loyalty of small men can be bought cheaply,...

Hmmm...  So it's a tribe of diminutive males that we seek?    
  :-)

- Bob

Re: What is wrong with OO ?

[Nick Leaton]

Tansel Ersavas wrote:
> In fact, as soon as you start to think, you start working on abstracted
> realm. It is the basis of our thinking, our understanding. We can not
> grasp things as they are, because anything has almost infinite
> complexity. If you want to model a chair, to model it as is in the real
> world, you have to model it down to the molecules, even quarks. All of
> our thinking involves abstraction.

Abstraction or generalisation is involved, but when modeling you can
distort reality, or delete realilty. In your case of the chair you may
choose to delete atomic structure as outside your model boundary. You
might choose to model they material(s) used in making the chair, wood,
steel plastic and ignore the type of wood. Distortion would be where you
modeled benches and chairs as a single class and ignored the restriction
on number of people that can sit on one instance at any time.

Building a model does not just involve abstraction

-- 

Nick

Re: What is wrong with OO ?

[Nick Leaton]

Robert C. Martin wrote:

> No code should be produced without an architecture and a design to direct
> it.  However, no architecture or design should be produced without code
> to verify that it is correct.  At frequent intervals, designers should
> commit their (probably unfinished) designs to code to verify that they
> can be implemented and that they work.  Those designs can then be built
> upon, improved, and extended.  The process is iterative and evolutionary.

Can you produce code without an architecture? I think you can. I asked
you to produce a set of classes to model employees, or clients you could
probably make a very good job of it. These classes could be used in 
a multitude of architectures. In fact, one of the criteria for a good
design of client classes should be that they could be used in different
architectures without changes. The dependency is one way. 

-- 

Nick

Re: What is wrong with OO ?

[Samuel S. Shuster]

Nick Leaton,

 >>   I've got an opinion as to why. VisualBasic does not promote a disciplined
 >> approach to development. [ yadda-yadda-my-babble ]
 >
 >It also fails because it is 'visual'. People think building the UI is
 >building the system. Building a model is not the usual disciplined
 >approach taken with VB. You can do this with VB, but I haven't seen 
 >many examples.

  Ok, but only to a point. There is nothing inherently wrong with Visual
programming. Read on. There is significant problems with 99% of the tools out
there that are "Visual" today. The problem is that they focus the Visual stuff
totally on the "View" - User Interface. There is no Visual Application Modeling,
there is no Visual Domain Modeling (well, no Dynamic stuff, just static CASE -
ER Modeling BS), there is no Visual Persistence Modeling, there is no Visual
Coordinator Modeling, etc.

  Each of these things CAN be presented with Visual tools. I worked on a project
(Continuum) that was doing this. The fact that these tools don't exist
commercially, doesn't in and of itself make "Visual" bad. Only the current
myopic set of tools that focus on the least meaningful end of the development
continuum... the User Interface.

  That said, yes, people think building the UI is building the system, and its
not only the cart in front of the horse, it's the whole buggy before there's a
road to ride it on. It is wrong, and it is promoted by almost every visual tool
on the market.

  Because of this, Visual/Declaritive development probably won't see it's full
potential. This is sad. I just don't believe that it's a fundamental problem of
"Visual Development"... any more than it was a fundamental problem of the IDE
tools of the previous generation.
                                And So It Goes
                                     Sames

============================================================================
sshuster@parcplace.com
ParcPlace-Digitalk
Consultant
All opinions are my own.
============================================================================

Re: What is wrong with OO ?

[Bill Gooch]

Tansel Ersavas wrote:
> 
> In fact, as soon as you start to think, you start working on abstracted
> realm. It is the basis of our thinking, our understanding. We can not
> grasp things as they are, because anything has almost infinite
> complexity.

Complete agreement, except for the "almost" part.

> If you want to model a chair, to model it as is in the real
> world,

..then you'd have to model it *physically*, e.g. by building 
another chair (maybe a miniature one).  Software modeling by 
nature is based entirely on abstract mental models.  

> you have to model it down to the molecules, even quarks. All of
> our thinking involves abstraction....

You said it.  Molecules and quarks are abstract models of what
we think we know about "the real world."  Physical reality 
itself is something else again.

Nick Leaton wrote:
> 
> Abstraction or generalisation is involved, but when modeling you can
> distort reality, or delete realilty. In your case of the chair you may
> choose to delete atomic structure as outside your model boundary. You
> might choose to model they material(s) used in making the chair, wood,
> steel plastic and ignore the type of wood. Distortion would be where you
> modeled benches and chairs as a single class and ignored the restriction
> on number of people that can sit on one instance at any time.

I would argue that in these terms, both distortion and
deletion are inherent in all software modeling.  The only
problem is that sometimes people seem to ignore or gloss 
over the fact that these phenomena are unavoidable.

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: What is wrong with OO ?

[Tom Bushell]

On Sat, 14 Dec 1996 19:55:11 -0800, Tansel Ersavas <tansel@deep.net>
wrote:

>Von Neumann, in vein, started to design a new computer, but
>died long before he could finish it. His last work 'The Computer and the
>Brain' states his objections to the architecture ironicaly named after
>him, while he was frantically working towards a different type of
>computer (much like a brain) to be able to deliver these people the
>right platform for what they wanted to do.

Tansel,

I, at least, would be very interested in learning some more about von
Neuman's objections to a procedural approach, and what he was
proposing as an alternative.  (Should be in a separate thread,
though.)

In other sub-threads, I've commented about the "gap" in abstraction
between high level design and code.  I believe one of the contributors
to this gap is that current design models don't seem to explicitly
model the underlying proceedural nature of the hardware they must run
on.  I've been looking for ways to push a more proceedural structure
up into higher levels of the design models.

Your post hints at a diametrically opposite approach - perhaps a
better one. I'd like to know more.

Thanks,

-Tom



----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Bob Kettig]

In article <32B36929.12B51408@probe.net> Jeff Miller,
jmiller@probe.net writes:
> ...
> you would be amazed at how easy it is to tear through $100 million.

Reminds me of something a U.S. Senator (whose name I don't
recall) once said, which is humorous, out-of-context:

    "A million here, a million there, and pretty soon 
     you're talking about real money."
                                                             -
anon

- Bob

Re: What is wrong with OO ?

[David Bradley]

Jeff Miller <jmiller@probe.net> wrote:

>why is it that all software is not written that way? Why is it that
>corporations continue to build these crazy, wasteful, failure-prone
>development departments when all they really needed to do was stuff
>a couple of talented programmers in a garage for a few months?

One, is that any such person would be caught dead in such a company.
Second there aren't that many out there.

--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com

Re: What is wrong with OO ?

[David Bradley]

Todd Hoff <tmh@possibility.com> wrote:

>I expect a largish group of diverce yet intelligent people
>to effectively deploy OO*. So far i have not seen this to be
>the case.

What, that a large group of intelligent people are unable to "deploy
OO" or that a large group of intelligent people were used to deploy
OO?

--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com

Re: What is wrong with OO ?

[Bob Kettig]

In article <32b6a57d.342498767@news> David Bradley,
davidb@datalytics.com writes:
>Jeff Miller <jmiller@probe.net> wrote:
>>Why is it that
>>corporations continue to build these crazy, wasteful, failure-prone
>>development departments when all they really needed to do was stuff
>>a couple of talented programmers in a garage for a few months?
>...
>...there aren't that many out there.

That's at least partly because once is enough for most folks. 
You may climb Mt.Everest once, but you probably won't want to
do it again.

- Bob

Re: What is wrong with OO ?

[Karen A. Morrissey]

Robert C. Martin wrote:
> [...]
> In some sense OO has attracted programmers the way that new weight
> loss methods attract people who want to lose weight.  They will grasp
> at anything new to solve their problems.
> 
> OO is a great technique and it can help make software easier to reuse,
> modify and maintain.  But it is not a cure-all; and it must be understood
> in detail and weilded with skill.
> [...]

This reminds me of the hoopla surrounding the introduction, to the
masses, of "knowledge bases" and OODBMSs. When asked about each I
remarked, sounding perhaps a bit like Eeyore (the old, cynical, donkey
from Winnie-the-pooh), "Great. Now there's another paradigm that
everyone will use but no one will bother to learn."

-- 
Karen A. Morrissey       kxmorr4@uswest.com (USW business)
US West Communications   kmorris692@aol.com (other business & personal)
1801 California          (on assignment from Analysts International)
Suite 310
Denver, CO 80202         "Everything comes in fives."
303-965-8473                        -- Hagbard Celine

Re: What is wrong with OO ?

[Tansel Ersavas]

Nick Leaton wrote:
> 
> Tansel Ersavas wrote:
> > In fact, as soon as you start to think, you start working on abstracted
> > realm. It is the basis of our thinking, our understanding. We can not
> > grasp things as they are, because anything has almost infinite
> > complexity. If you want to model a chair, to model it as is in the real
> > world, you have to model it down to the molecules, even quarks. All of
> > our thinking involves abstraction.
> 
> Abstraction or generalisation is involved, but when modeling you can
> distort reality, or delete realilty. 

In fact in any attempt to model anything, with exceptions of
mathematical models of perfect imaginery shapes, surfaces, etc. you
delete irrelevant parts of reality. When you model, you are making
certain assumptions which are shaped by your understanding of the
problem, and your version of reality, which may be different if someone
else did it. 

I'll include some material by Klir and Folger, which may enlighten the
subject a little bit more: 

Klir and Folger state: 

"... the complexity of an object is in the eyes of the observer.

In most cases there is virtually an unlimited number of ways in which
one can interact with an object. As a consequence, the interaction is
almost never complete. It is based on a limited (and usually rather
small) number of attributes of the object that the observer is capable
of distinguishing and that are relevant to his or her interests. These
attributes are not available to the observer directly but only in terms
of abstract images, which are results of perception or of some specific
measurement procedures. Let these abstract images of attributes be
called variables.
When a set of variables is established as a result of our interaction
with an object of interest, we say that a system is distinguished on the
object. The term system is thus always viewed as an abstraction - or an
image - of some aspects of the object and not as a real thing. In other
words, a system is a way of looking at the world.  "

> In your case of the chair you may
> choose to delete atomic structure as outside your model boundary. You
> might choose to model they material(s) used in making the chair, wood,
> steel plastic and ignore the type of wood. 

It very much depends on what you want to do with the chair. Your
observation and modeling parameters will be influenced by your purpose.
For instance: 
  1. If you are a store that sells 10000 items, a chair is just another
item with a price, color, dimensions, weight, etc.
  2. If you are a 3-D modeler, all you want is to keep the surfaces,
texture, color, and looks of the chair, your model wouldn't involve
structural parameters essential
  3. If you are a designer in a furniture store, and you want to create
a chair model for stress test (i.e. continous application of changing
forces simulating someone sitting on it, jumping to it, etc. your
approach would involve a certain way of modeling

The list can go on.
It is very difficult to come up with a universal chair class that will
satisfy all needs, even if it would be possible, it wouldn't be
practical. But there are ways of modularizing these, and a component
based modeling and programming is possible.

> Distortion would be where you
> modeled benches and chairs as a single class and ignored the restriction
> on number of people that can sit on one instance at any time.
> 

Yup

> Building a model does not just involve abstraction
> 

I haven't said that. What I said was, abstraction is not only an
important part of modeling, but our thinking as well. In fact my OO
modeling principles list is longer than those "essentials of OO".

> Nick

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
                               A.C. Clarke
-----------------------------------------------------------------------

Re: What is wrong with OO ?

[Robert C. Martin]

> On 12/15/96 Todd Hoff <tmh@possibility.com>  wrote:
> 
> >Building large software systems
> >is fundamentally a social activity, technology isn't even
> >a close second. With the right tribe of people i'd build a system
> >using carrier pigeons. If it's not the right tribe all the
> >money, tools, and consultants won't make a difference.

I agree that you have to have the right people on the team.  However,
you must also have the right technology.  If you don't have the
technology, you can't build the project.

Building large software systems is a technical activity that requires
social interaction.  Both aspects are critically important.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Robert C. Martin]

In article <32B54439.26E@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk> wrote:

> Robert C. Martin wrote:
> 
> > No code should be produced without an architecture and a design to direct
> > it.  However, no architecture or design should be produced without code
> > to verify that it is correct.  At frequent intervals, designers should
> > commit their (probably unfinished) designs to code to verify that they
> > can be implemented and that they work.  Those designs can then be built
> > upon, improved, and extended.  The process is iterative and evolutionary.
> 
> Can you produce code without an architecture? I think you can. I asked
> you to produce a set of classes to model employees, or clients you could
> probably make a very good job of it. These classes could be used in 
> a multitude of architectures. In fact, one of the criteria for a good
> design of client classes should be that they could be used in different
> architectures without changes. The dependency is one way. 

The classes would participate in a single architecture that could be used
as the foundation of many applications.  It is far less likely that they
could be used in lots of different architectures.

I agree that the dependency is one way.  But the direction is towards the
architecture.  Classes belong to architectures; they conform to the rules
and protocols that those architectures demand.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Robert C. Martin]

In article <01bbeb6f$e2220c40$371883cc@beast.advancedsw.com>, "Roger T."
<roger@advancedsw.com> wrote:

> Robert C. Martin <rmartin@oma.com> wrote in article
> <rmartin-1412962003340001@vh1b-035.wwa.com>...
> > In article <58aj6t$1ch@news3.digex.net>, ell@access2.digex.net (Ell)
> wrote:
> > > 
> > > If you are speaking of Martin, he has only accepted that project coders
> > > should be required to follow architecture within the last 6 months
> > > (partially at my urging).  WRT analysis he has never to my knowledge
> > > accepted that an overall analysis should be done at the outset of a
> > > project and that it should lead the creation of project architecture. 
> 
> [snip]
> > 
> > No code should be produced without an architecture and a design to direct
> > it.  However, no architecture or design should be produced without code
> > to verify that it is correct.  At frequent intervals, designers should
> > commit their (probably unfinished) designs to code to verify that they
> > can be implemented and that they work.  
> 
> Although I am in agreement with what Robert posts above I also have an
> addition to the development scenario. 
> 
> I believe that the environment the designers operate in should allow them
> to, if deemed necessary, *completely* discard the prototype code that is
> built during these iterations. 

Absolutely!  This is their perogative.  The code was first written
as a test to see if the concepts were correct.  Any of that code that survives
that test may find its way into the actual product.  As time goes on, and
more and more of these test are run, the more likely it is that the test code 
will be usable.  But any part of it that is not usable should be discarded
without a second thought.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Robert Dewar]

Bob said

"Reminds me of something a U.S. Senator (whose name I don't
recall) once said, which is humorous, out-of-context:

    "A million here, a million there, and pretty soon
     you're talking about real money."
                                                             -
anon"


It was Senator Everett Dirkson (I am not 100% sure of spelling) from
Illinois, and the original quote is billion not million :-)

Re: What is wrong with OO ?

[Marin David Condic, 561.796.8997, M/S 731-93]

Matt Kennel <mbk@CAFFEINE.ENGR.UTK.EDU> writes:
>Nick Leaton (nickle@calfp.co.uk) wrote:
>: Piercarlo Grandi wrote:
>
>: > Perhaps the reverse: if the tools were really advanced, perhaps
>: > including a program generator (and despite claims to the contrary no
>: > such thing has been yet produced), then high level design activity would
>: > be almost all the project.
>
>: Available now, called a programer.
>
>Exactamundo.   The 'tool' is known as a "programming language".
>
>I don't understand the obsession with "high level design tools" outside
>programming languages.
>
>Programming langauges *are* the proper "high level design tool", and despite
>seeming fuddy-duddy and old-fashioned, progress in programming language has
>always been, and will continue to be, the most potent means to deliver the
>fruits of research to programmers.
>
    I've seen this happen at my company. We built a "design" tool
    which enables logic developers to draw pictures of their logic and
    a picture compiler spits out Ada code. It works pretty well and
    yes indeed, we reduced the number of "programmers" who were
    previously translating logic diagrams into Ada code. However, the
    logic designers suddenly had to become cognizant of number
    scalings, correct syntax, data dictionaries, compilation order,
    etc. Their workload went up some. In effect, they simply became
    programmers in a "picture language" instead of a "word language".

    One has to wonder if it wouldn't have simply saved time to teach
    the logic designers how to write code directly in Ada???

    Yet in the end, it's still a good idea for us and did save us in
    the area of productivity. You see, the Gummit spake and said:
    "Thou shalt make for us a book with lots of pictures in it" so we
    were going to make the pictures anyway. Might just as well get
    some automatic code generation out of the work you were going to
    do anyway.

    But then again, one must remember that our type of software has to
    live in a very unusual world. The guys who are writing spreadsheet
    programs or word processors don't have the same requirements and
    so they don't likely need the same sorts of "design tools" (if
    they need any at all?)

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "There is just one thing I can promise you about the outer-space
    program: your dollars will go farther."

        --  Wernher von Braun
===============================================================================

Re: What is wrong with OO ?

[Nick Leaton]

Samuel S. Shuster wrote:

>  >>   I've got an opinion as to why. VisualBasic does not promote a disciplined
>  >> approach to development. [ yadda-yadda-my-babble ]
>  >
>  >It also fails because it is 'visual'. People think building the UI is
>  >building the system. Building a model is not the usual disciplined
>  >approach taken with VB. You can do this with VB, but I haven't seen
>  >many examples.
> 
>   Ok, but only to a point. There is nothing inherently wrong with Visual
> programming. Read on. There is significant problems with 99% of the tools out
> there that are "Visual" today. The problem is that they focus the Visual stuff
> totally on the "View" - User Interface. There is no Visual Application Modeling,
> there is no Visual Domain Modeling (well, no Dynamic stuff, just static CASE -
> ER Modeling BS), there is no Visual Persistence Modeling, there is no Visual
> Coordinator Modeling, etc.
> 
>   Each of these things CAN be presented with Visual tools. I worked on a project
> (Continuum) that was doing this. The fact that these tools don't exist
> commercially, doesn't in and of itself make "Visual" bad. Only the current
> myopic set of tools that focus on the least meaningful end of the development
> continuum... the User Interface.
> 
>   That said, yes, people think building the UI is building the system, and its
> not only the cart in front of the horse, it's the whole buggy before there's a
> road to ride it on. It is wrong, and it is promoted by almost every visual tool
> on the market.
> 
>   Because of this, Visual/Declaritive development probably won't see it's full
> potential. This is sad. I just don't believe that it's a fundamental problem of
> "Visual Development"... any more than it was a fundamental problem of the IDE
> tools of the previous generation.
>                                 And So It Goes

I agree, I think you can produce good systems with VB. However you need
to use VB to produce top quality objects that then get used in different
ways. In a bank there should be a counterparty object, that you can use
to select counterparties, input them if you have the right etc. However
everybody I have seen doing VB writes there own screens to do this, with
SQL or otherwise interacting with the DB. More coordination would help
but in a RAD environment, it tends to go out of the window. 

-- 

Nick

Re: What is wrong with OO ?

[Tansel Ersavas]

Samuel S. Shuster wrote:

>  >It also fails because it is 'visual'. People think building the UI is
>  >building the system. Building a model is not the usual disciplined
>  >approach taken with VB. You can do this with VB, but I haven't seen
>  >many examples.
> 
>   Ok, but only to a point. There is nothing inherently wrong with Visual
> programming. Read on. There is significant problems with 99% of the tools out
> there that are "Visual" today. The problem is that they focus the Visual stuff
> totally on the "View" - User Interface. There is no Visual Application Modeling,
> there is no Visual Domain Modeling (well, no Dynamic stuff, just static CASE -
> ER Modeling BS), there is no Visual Persistence Modeling, there is no Visual
> Coordinator Modeling, etc.

That's quite right. The object model can be represented, as well as the
existing code can be visualized with the right visual tools, and this
can be very enlightening. In fact I have been using visual tools to not
only program, but teach OO and Smalltalk. Have you ever seen the entire
class structure of Smalltalk visually? It is quite a sight. Logical
grouping to categories, viewing a small part of the class hierarcy,
visually adding, deleting classes, changing the inheritence structure in
your favorite notation right on the spot? These are very powerful
features, and allow you to model your system, not only the UI, with the
user. 
  
> The fact that these tools don't exist
> commercially, 

This statement will not be true after we release our new OO modeling
tool "Snowball Rapid Systems Engineering Tool" very soon.
...
All deleted stuff, very much agreed
...
>   Because of this, Visual/Declaritive development probably won't see it's full
> potential. This is sad. I just don't believe that it's a fundamental problem of
> "Visual Development"... any more than it was a fundamental problem of the IDE
> tools of the previous generation.

Times are changing. We have such a tool, and we are very convinced that
this is the way of future. However, our approach to the problem is quite
different to most other people's approach. First of all, we didn't
invent a visual programming language. What we did was to take an
existing language, and create a visual layer (aka a visual editor) on
top of it. This language had to be very flexible, so most of the current
populer languages didn't qualify, except Smalltalk. 

Our approach to visual programming is to visualize the system in any of
its canonical forms the developer requests instantly: class diagrams,
category diagrams, std diagrams. We are also adding to this list object
diagrams that are dynamically generated while your program is running,
and you can use them as visual inspectors-debuggers. We use a trademark
techniques that we developed to visualize the system and create source
from the system we call "Instant Reverse Engineering(tm)", and "Instant
Code Generation(tm)". With these techniques, the moment you draw a class
on a screen, your corresponding Smalltalk class is ready. You can switch
between the textual and visual views of the system within seconds, and
work at the level you feel comfortable. If a class represents a window,
then you can switch between the class diagram view, window design view,
stm view, or source code. You can create an instance and test it at any
time. You can also create documentation related to not only visual parts
of the system, but for non visual parts as well. 

I think, we can now show people how visual programming can really bump
up their productivity. It also accelerates learning, and promotes more
high level thinking. Visual programming is to textual programming what
is textual programming to assembly language.

>                                 And So It Goes
>                                      Sames

Tansel Ersavas
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
                               A.C. Clarke
-----------------------------------------------------------------------

Re: What is wrong with OO ?

[David Bradley]

"Karen A. Morrissey" <kxmorr4@netmail.mnet.uswest.com> wrote:

>This reminds me of the hoopla surrounding the introduction, to the
>masses, of "knowledge bases" and OODBMSs. When asked about each I
>remarked, sounding perhaps a bit like Eeyore (the old, cynical, donkey
>from Winnie-the-pooh), "Great. Now there's another paradigm that
>everyone will use but no one will bother to learn."

So true.  Unfortunately it seems that many think they can get
something for nothing.

--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com

Re: What is wrong with OO ?

[Robert Dewar]

Jeff Miller <jmiller@probe.net> wrote:
>Why is it that
>corporations continue to build these crazy, wasteful, failure-prone
>development departments when all they really needed to do was stuff
>a couple of talented programmers in a garage for a few months?


it's a nice fantasy, but not remotely connected to reality. The domain
of programs that can be attacked this way is a small fraction of 
real life programs. 

Re: What is wrong with OO ?

[Robert Dewar]

Tansel says

"First of all, my opinion is, developing systems with procedure oriented
techniques is a dangerous, wasteful and unproductive process."

It is this kind of unsupporable hyperbole that gives OO a bad name!

Why is it that when anyone comes along with new techniques that represent
a useful incremental advance in our knowledge in this area (e.g. 
functional programming, proof of correctness, your-favorite-fad-here)
they feel compelled to hype them like this with the approach

"what we have done before is an unmitigated disaster, but my new technique
will make a revolutionary difference".

The trouble with such hype is that inevitably it does not deliver, and then
there is a danger of throwing out the baby with the bathwater and
discarding what is useful along with the hype.

The fact of the matter is that there is NO giant shift of paradigm involved
here, despite what anyone says. Just look at the OO programs that people
produce. They are not radically different from conventional procedural
programs, and one would not expect them to be.

OO techniques are a useful way of extending the conceptual design domain,
and OO features in programming languages allow added flexibility in
the solution space. Good! But trying to fit everything into the OO mold
is as reasonable as believing these ads on TV that suggest that all your
handy-man's problems at home can be solved with one amazing tool!

Re: What is wrong with OO ?

[Roger T.]

Robert C. Martin <rmartin@oma.com> wrote in article
<rmartin-1612962254140001@vh1-047.wwa.com>...
> In article <01bbeb6f$e2220c40$371883cc@beast.advancedsw.com>, "Roger T."
> <roger@advancedsw.com> wrote:
> > Although I am in agreement with what Robert posts above I also have an
> > addition to the development scenario. 
> > 
> > I believe that the environment the designers operate in should allow
them
> > to, if deemed necessary, *completely* discard the prototype code that
is
> > built during these iterations. 
> 
> Absolutely!  This is their perogative.  The code was first written
> as a test to see if the concepts were correct.  Any of that code that
survives
> that test may find its way into the actual product.  As time goes on, and
> more and more of these test are run, the more likely it is that the test
code 
> will be usable.  But any part of it that is not usable should be
discarded
> without a second thought.

This brings up a succeeding issue.

Let's assume that coders are given the freedom to discard their prototypes.
The next problem facing me as a manager is to make sure they actually use
that freedom.

The desire to paste functionality onto the prototypes to "fix" them so they
support new functionality is very seductive when it means a short term time
savings. To some extent you are re-inventing the wheel, though in a better
form.

Designers must realize that prototype extinction is not only allowed but is
encouraged if it has the effect of creating long term product robustness.

How would you encourage/enforce that philosophy with your developers?

Roger T.

Re: What is wrong with OO ?

[Tansel Ersavas]

Adam Beneschan wrote:
> 
> OO techniques are a relatively recent development.  Major software has
> been developed for the last several decades.  If the above statement
> were true as written, one would have to draw the conclusion that
> software developers, whose best tool was "procedure-oriented
> techniques", were unable to produce ANY good software, and the
> software they did produce was dangerous.

OO techniques are not a relatively recent development. OO has been
around since SIMULA (1965-1967). 

> 
> Clearly, that isn't the case--a lot of good software has been produced
> over the last 30-40 years.  Procedure-oriented programming has its
> limitations, and OO pioneers must be credited with exposing its flaws
> and, more importantly, developing a viable alternative.  This hardly
> makes procedure-oriented techniques dangerous or wasteful or
> unproductive.

This is true, depending on the criteria that you are using. There are a
lot of procedure oriented systems that I developed or was the architect
of, and are considered very good. Individual success stories don't
change the following facts though: 

a) Software industry is in a crisis. 
b) The application gap is still growing
c) Every year abandoned software costs the world economy unmentionable
billions of dollars.
d) Even many so called successful projects Today are big money drains
e) The approach we use for systems development influence a, b, c and d

How can we justify massive collapses of big systems with hundreds of
millions of dollars down the drain with a cool face? If we don't call
this a failure, what are we going to call? If it not waste, I would like
to learn your definition of waste. And, dangerous, yes, because it
creates a false sense of security once people get used to it.

>  >So far OO
>  >couldn't show a quantum leap of difference, but it is not mature yet.
> 
> Another reason there isn't a quantum leap is that procedure-oriented
> programming is not the demonic evil you make it out to be.
 
I never said procedure oriented programming was the demonic evil. I just
said, wasteful, dangerous, and unproductive. I must admit, when I was
developing procedure oriented systems, I would enjoy developing them. 

Something can be dangerous, but still enjoyable; take motorcycle riding.
It is very enjoyable, and the bikes are beautiful, but it doesn't change
the fact that they are a few times more dangerous that cars. How can I
say that motorcycle riding is evil? But it doesn't stop me from pointing
out dangers to myself and others. 
Or take guinea pigs, they are lovely pets, but they are wasteful, and
unproductive IF you have all females (males tend to fight, and
male-female combinations are extremely productive) but they just are,
they make cute pets and we enjoy them. 
Things just are. We simply observe them, and put out our comments from
our perspective. We don't want to sort things out as good or evil.
Potential dangers should be noted though. I.e. it is a nice idea to mark
quicksand as dangerous, especially if you saw some people drowning. 
 
> I'd hardly call it a "historical accident".  Procedure-oriented
> ("structured programming") techniques were a huge improvement over
> what was done before, which was to write code haphazardly and
> completely unstructured.  Whether we had the know-how at the time to
> develop OO techniques instead of procedural techniques, I don't know.
> Probably not.  I suspect that the structured-programming "revolution"
> was a necessary step in the evolution of software engineering
> techniques that is now leading us to OO techniques and will probably
> lead to something completely different a couple decades hence.  In
> other words, our experiences with structured programming have taught
> us a lot of the things we needed to know in order to develop OO
> techniques--things we wouldn't have found out if the evolutionary step
> you call a "historical accident" had never taken place.

In fact, you are right. I shouldn't have called it a historical
accident. It is actually a series of historical accidents. I'll put some
of these historically important milestones to somewhere in my site, so
that it can be visited like a museum, for people have tendency to
quickly forget. 

As an example would you like to tell me say, how and why one of the most
popular languages "C" was developed to prove your point that the
language which is very widely used now and enjoyed by many (which
includes me) is not a historical accident? And yes, there are undeniably
a few moments in recent history which were carefully planned attempts to
solve problems, but they are more exception than the norm.

Also, I would like to clarify that structured programming is NOT
procedure orientation. Writing code haphazardly is also procedure
orientation. Procedure oriented programming is the technique we apply
when we write code directly for a von Neumann machine. I don't deny that
structured programming, structured design and structured analysis are
all big improvements over unstructured procedural approach, and all of
them are procedural as much as a spaghetti code, they are only more
structured.

I have explained in a few of my previous postings, and I get many
requests to repost them, but, I feel that people are already getting
sick, I'll organize this information and present it in our web site:
http://www.rase.com/ after the new year break. So if you want to know
what I mean by "historical accidents", and other information that I
present, along with the proper references. Please browse after the new
year's eve, and if you have any questions or problems I'll be happy to
discuss either publicly or via e-mail. 

> The rest of this post, which I didn't quote, runs along the same
> lines. To be honest, if I was in a management position and needed OO
> training, I wouldn't consider using your training services, since I
> can't tell whether you're turning out good software engineers or
> engineers who go around chanting "Four legs good, two legs bad" . . .
> er, "OO good, Procedural bad".

Again, something, I couldn't possibly have told, or taught without
reason.
 
On the other hand, as a trainer (which I am occasionally, only because I
enjoy it so much), If I were to be able to help you, I'm sure both of us
would benefit. I feel that sharing what I know is a duty. I am not
sentimental. It wouldn't bother me if you wouldn't come to me Today, but
in 5 years, things may change, and if you come to me then, I'll do my
best to accommodate training your people. And a guarantee, nobody will
be chanting anything without solidly supporting these ideas with figures
and references. 

Why is it difficult to accept any questions, comments and criticisms
about procedure orientation? If you accept the premise that procedure
orientation was as good as you say it is, how do you explain a big
failure rate in complex software, and lost billions? 

> Come on.  OO is a better mousetrap, not a knight on a white horse come
> to save the world from the evil oppression of procedural thinking.
> Thinking about it in such a polarized manner is not going to produce
> engineers who understand software engineering issues realistically.

OO can be a mousetrap, yes, but guess for whom? It is clearly a knight
for some. Remember, only the princess who kissed the frog got a prince,
to some other, it was just a frog.

Coming to the issue of engineers that understand software engineering
issues realistically, If we don't change things right now, Tomorrow will
be the same. Many people rightly pointed out that as long as the
university curriculums don't change, engineers of Tomorrow will not be
so much different to engineers of Today. All I want to do is to start
changing things Today, so that I can tell my children that I have done
what I could.
 
>                                 -- Adam


Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
                               A.C. Clarke
-----------------------------------------------------------------------

Re: What is wrong with OO ?

[Ralph Cook]

Adam Beneschan wrote:

Re: What is wrong with OO ?

[Adam Beneschan]

In article <32B3F45C.5140@deep.net> tansel@deep.net writes:
 
 >First of all, my opinion is, developing systems with procedure oriented
 >techniques is a dangerous, wasteful and unproductive process. 

OO techniques are a relatively recent development.  Major software has
been developed for the last several decades.  If the above statement
were true as written, one would have to draw the conclusion that
software developers, whose best tool was "procedure-oriented
techniques", were unable to produce ANY good software, and the
software they did produce was dangerous.

Clearly, that isn't the case--a lot of good software has been produced
over the last 30-40 years.  Procedure-oriented programming has its
limitations, and OO pioneers must be credited with exposing its flaws
and, more importantly, developing a viable alternative.  This hardly
makes procedure-oriented techniques dangerous or wasteful or
unproductive.  
 
 >So far OO
 >couldn't show a quantum leap of difference, but it is not mature yet.
 
Another reason there isn't a quantum leap is that procedure-oriented
programming is not the demonic evil you make it out to be.

 >When I train people, I look at their background. Usually the more
 >experienced in the traditional techniques they are, the less they
 >believe the necessity of learning a new technique.  In my breakthrough
 >courses, for the first part, I challenge the traditional ways of systems
 >development and show that this way of developing systems is a historical
 >accident, and the more we insist on going that way, the more troubles we
 >will be in. 

I'd hardly call it a "historical accident".  Procedure-oriented
("structured programming") techniques were a huge improvement over
what was done before, which was to write code haphazardly and
completely unstructured.  Whether we had the know-how at the time to
develop OO techniques instead of procedural techniques, I don't know.
Probably not.  I suspect that the structured-programming "revolution"
was a necessary step in the evolution of software engineering
techniques that is now leading us to OO techniques and will probably
lead to something completely different a couple decades hence.  In
other words, our experiences with structured programming have taught
us a lot of the things we needed to know in order to develop OO
techniques--things we wouldn't have found out if the evolutionary step
you call a "historical accident" had never taken place.

 >Unfortunately, with their slow and wasteful structure, big companies can
 >absorb huge amounts of losses without blinking. This contributes a lot
 >to people not realizing how big the crisis is. In fact, even many
 >succesful systems Today are big money wasters. 
 
 >Procedural thinking and OO are not complimentary. Procedural thinking
 >requires a major transformation that affects all our thinking. I know
 >it, because I was a procedural programming freak, starting programming
 >with a 6502 board with hex keypad, and being a mad assembler, C and
 >later C++ person. Even when I was a C, C++ person my productivity was
 >substantially higher than others, I couldn't make the switch to OO until
 >I let my strong and enjoyable procedural skills go. Now I only program
 >with Smalltalk (not a prerequisite to anything, just a choice), and I do
 >everything in a much higher level previously unimaginable to me. My
 >productivity increased 5 fold, and I developed a tool to further
 >increase it another 5 fold. Now I know that the tools and techniques I
 >use are anywhere from 5 to 25 times better than my old techniques
 >before. These techniques are pure OO but I am reaching limits of them.
 >Therefore I expanded my horizons to other techniques that I combine with
 >OO which will increase my productivity another order of magnitude.

The rest of this post, which I didn't quote, runs along the same
lines.  To be honest, if I was in a management position and needed OO
training, I wouldn't consider using your training services, since I
can't tell whether you're turning out good software engineers or
engineers who go around chanting "Four legs good, two legs bad" . . .
er, "OO good, Procedural bad".

Come on.  OO is a better mousetrap, not a knight on a white horse come
to save the world from the evil oppression of procedural thinking.
Thinking about it in such a polarized manner is not going to produce
engineers who understand software engineering issues realistically.

                                -- Adam

Re: What is wrong with OO ?

[Adam Beneschan]

In article <32B3F45C.5140@deep.net> tansel@deep.net writes:

 >Not only being an OO trainer, but a motivational trainer, I would have
 >to disagree here. Every training should include a motivational
 >component. I totally agree that knowledge and skill are paramount. The
 >important thing is to be able to excite people to get this knowledge and
 >skill. The teacher is as good as he or she can motivate the participants
 >to eagerly accept what he or she is offering. One of the reasons that
 >children learn OO quickly is they are so easily excitable. The moment
 >you show them something, that becomes the most important thing on Earth.
 >But for the grown ups (or as they are labeled by children: "given ups")
 >a big dose of motivation is required to grab their attention.  

"Every training should include a motivational component"???  This is
probably true for trainings that are likely to include a bunch of
unmotivated people who don't want to be there and are in the training
only because their boss is making them and who were hoping to go
through the rest of their lives making money by doing the same thing
over and over without having to learn anything new.  Hopefully, I
wouldn't have any such people working for me.  I also wouldn't want
employees who are able to get so excited that they would "eagerly
accept" what a teacher is teaching them; I'd prefer those who are
smart enough to look at the material analytically, so that they would
understand when, how, and why to apply it.

[By the way, I'm speaking as someone who spent a lot of time and money
in the past in courses that could be called "motivational" or
"self-development" seminars.  While they did me a world of good, my
experiences have convinced me that the practice of exciting trainees
so that they accept things eagerly (and unquestioningly) has great
potential for harm as well as for good.]

Finally, does anyone else feel insulted by Tansel's post?  There seems
to be an undercurrent that those who don't believe in OO as fervently
as he does [I'm assuming Tansel is a "he"] are unmotivated, have
"given up", don't want to learn anything new, are "followers", etc.
This seems like it would be insulting to many truly professional
engineers.

                                -- Adam

Re: What is wrong with OO ?

[drush]

"Roger T." <rogher@advancedsw.com> wrote in message <01bbec50$0abb3380$371883cc@beast.advancedsw.com>
>[Comments about discarding prototype code snipped]
>This brings up a succeeding issue.

>Let's assume that coders are given the freedom to discard their prototypes.
>The next problem facing me as a manager is to make sure they actually use
>that freedom.

You are a unique manager. I have all too frequently been in the posisition
of taking code that should have been tossed in the garbage as a basis for
expanded functionality. In one case, we even had universal recognition from
management that the code should have been tossed, but were directed to modify
the prototype because the schedule wouldn't allow us to do it right.

>The desire to paste functionality onto the prototypes to "fix" them so they
>support new functionality is very seductive when it means a short term time
>savings. To some extent you are re-inventing the wheel, though in a better
>form.

>Designers must realize that prototype extinction is not only allowed but is
>encouraged if it has the effect of creating long term product robustness.

>How would you encourage/enforce that philosophy with your developers?

Schedule according to engineering realities, not psychological needs.
Educate clients about the hidden costs of doing a slap-dash design job.
Shield engineers from clueless higher management.
Etc...

DeMarco and Lister (in Peopleware) got it pretty right, I think. The reasons
why projects fail are rarely technical; they are usually organizational.

	david rush
	mailto:kumo@intercenter.net

	I bill $100/min for reading commercial E-mail.

Re: What is wrong with OO ?

[Matt Kennel]

Tom Bushell (tbushell@fox.nstn.ns.ca) wrote:
: On Tue, 17 Dec 1996 00:45:47 -0800, Tansel Ersavas <tansel@deep.net>
: wrote:

: >I think, we can now show people how visual programming can really bump
: >up their productivity. It also accelerates learning, and promotes more
: >high level thinking. Visual programming is to textual programming what
: >is textual programming to assembly language.

: Good analogy.

Is it really?  Can a painting communicate subtle ideas as clearly as 
literature?

: -Tom

--
Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ 

Re: What is wrong with OO ?

[Matt Kennel]

Roger T. (roger@advancedsw.com) wrote:

: This brings up a succeeding issue.

: Let's assume that coders are given the freedom to discard their prototypes.
: The next problem facing me as a manager is to make sure they actually use
: that freedom.

: The desire to paste functionality onto the prototypes to "fix" them so they
: support new functionality is very seductive when it means a short term time
: savings. To some extent you are re-inventing the wheel, though in a better
: form.

: Designers must realize that prototype extinction is not only allowed but is
: encouraged if it has the effect of creating long term product robustness.

: How would you encourage/enforce that philosophy with your developers?

Perhaps I am naive, but what about asking them?

     "How much of the prototype did you keep?  Was it good enough to keep
      or do you wish you would have time to re-do it from scratch?  Don't
      assume I wouldn't have let you." 

: Roger T.

--
Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ 

Re: What is wrong with OO ?

[Adam Beneschan]

In article <32B758D7.61EF@deep.net> tansel@deep.net writes:

 >Why is it difficult to accept any questions, comments and criticisms
 >about procedure orientation? If you accept the premise that procedure
 >orientation was as good as you say it is, how do you explain a big
 >failure rate in complex software, and lost billions? 

It would take me some time to look over and prepare a response to your
entire response to my post (assuming I decide to respond at all rather
than let others address your points).  But I can deal with this one
now.

Nowhere did I say that procedure orientation is immune from criticism
or question.  In fact, I've been working as a programmer for 20 years,
and almost since the beginning I've had a sense that there should be a
better way.  I've always been interested in languages with totally
different paradigms, such as "pure" Lisp, Prolog, Backus' FP, Lucid,
dataflow, some 4GL ideas, more recently Haskell, and several other
experimental languages that have gotten write-ups in SIGPLAN notices
and have since seemingly disappeared from the face of the earth.
(Whatever happened to M'PAL?)  OO is, in fact, another idea that I've
been really interested in, and I think it's a significant step forward
in software engineering.  (I did, after all, describe it as a "better
mousetrap.")

What I object to is not the idea that OO is better than what we were
doing before (I think it is), nor that "procedure orientation" is
flawed (I'm sure it is).  Rather, it's the black-and-white tone of
your post, that OO is completely wonderful, that "procedure
orientation" has no value whatsoever, and that programmers who don't
see things that way are simply unwilling to change, or unwilling to
try something new, or have been using procedural techniques so long
that they are stuck with them, or just hate new ideas or some such.
The fragment I've quoted above is a symptom of this kind of thinking;
apparently because I criticized your first post, you've assumed,
without justification, that I find it difficult to accept questions or
criticisms about procedure orientation.  Nothing could be further from
the truth.

                                -- Adam

Re: What is wrong with OO ?

[Tansel Ersavas]

Matt Kennel wrote:
> 
> Tom Bushell (tbushell@fox.nstn.ns.ca) wrote:
> : On Tue, 17 Dec 1996 00:45:47 -0800, Tansel Ersavas <tansel@deep.net>
> : wrote:
> 
> : >I think, we can now show people how visual programming can really bump
> : >up their productivity. It also accelerates learning, and promotes more
> : >high level thinking. Visual programming is to textual programming what
> : >is textual programming to assembly language.
> 
> : Good analogy.
> 
> Is it really?  Can a painting communicate subtle ideas as clearly as
> literature?

A picture is worth a thousand words.

BTW I do not defend a total pictorial approach. There are certain things
I can do faster and better in text. In fact, I still don't much use the
Windows file management facilities and drop down to dos prompt
(especially while no one is around). However, When I am using the right
kind of visual tool, there are certain things that I can do which is
definitely a higher level, where I have no hope of achieving with the
same ease if I did it at the text level. For example, changing the
parent class of a class, I find it quite useful to do it at a visual
level. It is much easier to move the tip of an inheritance line from one
class to another, and having the underlying mechanism to do all
necessary checks for you, and change the class hierarchy for that class.

There are many things that we can do much more faster and at a higher
level with visuals, but most visual tools I found weren't practical, and
limiting. You should be able to switch between text view of your program
and visual view within a blink of an eye, and anything you do textually
should be reflected in the visual view, and vice versa. 

Besides, it is much more easier to teach people visually, if it is done
correctly. Once they learn it visually first, then people tend to stick
to visuals. When they grasp the concepts, they can dwelve into text if
they want to. 

Still I believe that the next generation will work predominantly with
pictures and will rarely revert to bulky chunks of text, unless it is a
meaningful whole. In one of our new projects, we are developing an
object oriented systems development tool for children to develop their
own games. This is a visual development tool, and we had great success
with children with early prototypes of it. It needs a lot of work, but
watching this experiment gave me the feeling that, the next generation
will have an entirely different understanding of computers, languages,
and programming. It is a scary feeling, but also a most enjoyable one. 

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: What is wrong with OO ?

[Matt Austern]

Tansel Ersavas <tansel@rase.com> writes:

> > Is it really?  Can a painting communicate subtle ideas as clearly as
> > literature?
> 
> A picture is worth a thousand words.

Literally so?  In that case, that suggests an interesting challenge.
The article I'm replying to, <32B89D8D.7999@rase.com>, consists of 552
words.  That figure includes some initial praise of visual
programming, Matt Kennel's skeptical question about the ability of a
painting to communicate subtle ideas, and a response defending visual
programming in some detail.  (And actually, 552 is probably an
overestimate: I used wc to get that number, and it includes the header
lines and the .sig file.)

So is a picture worth five hundred words?  Can someone come up with a
picture that says the same things that this 552 word article does?

Re: What is wrong with OO ?

[Caitlin]

Patrick Ma wrote:

> 
>         I am not trying to make the point that OO is more professional than any
> other technique. IMO, OO has a rich set of principles that makes ME see it
> as a discipline besides being a technology. As a discipline that I practice, I find
> myself more determined to identify and correct OO errors and bad practices
> that others may let go for the reasons I mentioned above. I believe in OO and I
> want to promote it. I want others to see OO as a discipline in addition to being
> an excellent technology, IMO.

OO, particularly OOA, has a lot of potential and IMHO is essential to defining software
with resuable components. However, I hope you are not claiming that it is more suitable to a
disciplined approach than the classical structure techniques. These techniques, while perhaps
at a deadend and in need of fundamental re-thought to encourage re-use and evolutionairy
development, are rich in accumulated wisdom and objective criteria that can be applied to
a design. Information Engineering afficionados can find flaws in Information Models without
even knowing the target application. When OOA achieves a TENTH of the accumulated consensus
and rigorous agreed upon rules the Structured Analysis, Structured Design and Information
Engineering have accumulated it will finally be getting somewhere.

Re: What is wrong with OO ?

[Ralph Cook]

Tansel Ersavas wrote:
> 

Re: What is wrong with OO ?

[Harry Protoolis]

On 14 Dec 1996 23:19:51 -0500, Patrick Ma <pma@panix.com> wrote:
>On 12/14/96 Robert C. Martin <rmartin@oma.com>  wrote:
>
>>OO is not a motivational discipline.  It does not take willpower and
>>determination to "do things right".  Rather it takes knowledge and skill.
>
>Robert,
>
>	Without a doubt, it takes knowledge and skill to "do things right" in OO.
>However, I do think OO is a discipline and it does take willpower and 
>determination together with knowledge and skill to "do things right."
>
>	Often, things were done wrong but not corrected even when they are
>discovered because they were 
>	1. done by higher ranked developers,
>	2. done for a while or in too many places,
>	3. insert your favorite scenarios.
>
>	It is willpower and determination of OO discipline that is going to lead us to 
>break through these hurdles created by our very own minds. 

What's OO got to do with it ?

Idenitifying and changing errors and bad practices is a matter of
*Professionalism*, there is nothing unique to OO that makes it more
professional that any other technique.

Of course, turning professional programmers into 'code monkeys' is just
begging for this sort of problem ...

H
--
Harry Protoolis                              alt.computer pty ltd                 
harry@alt.net.au                             software development consultants

Re: What is wrong with OO ?

[Harry Protoolis]

On Fri, 13 Dec 1996 10:32:03 -0500, Ronald Servant <rservant@nortel.ca> wrote:
>Harry Protoolis wrote:
>
>> [...]. My rule-of-thumb is that overall
>> architecure should consist of a small (say < 10) number of fairly
>> simple diagrams. You should be able to get it across to the project team
>> in a single ~ 1 hour presentation.
>
>Now, what size of a project are you talking about?  Are taking about 
>the problem domain model or the actual architectual solution to that
>problem domain?

I am talking about the overall architectural vision, obviously there is
an arbitrary amount of detail to be added later, but that is more
effectively done during the iterative process, i.e at the same time as 
design and implementation.

As for size, I think this is an effective upper limit, but I admit
that my experience is with projects up to about 15 person-years, or
perhaps a bit larger.

If it were any bigger I would break it up into co-operating but autonomous
sub-projects.

As for serious death-march-fodder projects (> 100 person years), I
honestly don't know.

>I believe I understand and agree with your point, but when you use a
>number like 10 it makes me wonder.

The number was plucked out of the air, I admit. The one hour limit is
more important because that is about how long most people can concentrate
on a presentation for, the number 10 is an estimate of how much you
can get though in an hour.

Also, you can pin 10 diagrams up on a wall ...

H
--
Harry Protoolis                              alt.computer pty ltd                 
harry@alt.net.au                             software development consultants

p.s. the term 'Death March' for doomed software projects was coined by
Ed Yourdon and I beleive it is the title of his upcoming book.

Re: What is wrong with OO ?

[Ell]

Harry Protoolis (harry@matilda.alt.net.au) wrote:
: On 14 Dec 1996 23:19:51 -0500, Patrick Ma <pma@panix.com> wrote:
: >On 12/14/96 Robert C. Martin <rmartin@oma.com>  wrote:
: >
: >>OO is not a motivational discipline.  It does not take willpower and
: >>determination to "do things right".  Rather it takes knowledge and skill.

: >Without a doubt, it takes knowledge and skill to "do things right" in OO.
: >However, I do think OO is a discipline and it does take willpower and 
: >determination together with knowledge and skill to "do things right."

I do not think it's primarily any of those things.  I think mainly its a
matter of approach and perspective.

: >It is willpower and determination of OO discipline that is going to
: >lead us to 
: >break through these hurdles created by our very own minds. 
 
: What's OO got to do with it ?
: 
: Idenitifying and changing errors and bad practices is a matter of
: *Professionalism*, there is nothing unique to OO that makes it more
: professional that any other technique.
: 
: Of course, turning professional programmers into 'code monkeys' is just
: begging for this sort of problem ...

Many programmers turn themselves into "code monkeys".  Imo, because they
belittle the big logical picture.

Elliott

RE: What is wrong with OO ?

[Patrick Ma]

On 12/18/96 Harry Protoolis <harry@matilda.alt.net.au>  wrote:

>On 14 Dec 1996 23:19:51 -0500, Patrick Ma <pma@panix.com> wrote:
>>On 12/14/96 Robert C. Martin <rmartin@oma.com>  wrote:
>>
>>>OO is not a motivational discipline.  It does not take willpower and
>>>determination to "do things right".  Rather it takes knowledge and skill.
>>
>>Robert,
>>
>>	Without a doubt, it takes knowledge and skill to "do things right" in OO.
>>However, I do think OO is a discipline and it does take willpower and 
>>determination together with knowledge and skill to "do things right."
>>
>>	Often, things were done wrong but not corrected even when they are
>>discovered because they were 
>>	1. done by higher ranked developers,
>>	2. done for a while or in too many places,
>>	3. insert your favorite scenarios.
>>
>>	It is willpower and determination of OO discipline that is going to lead us to 
>>break through these hurdles created by our very own minds. 
>
>What's OO got to do with it ?
>
>Idenitifying and changing errors and bad practices is a matter of
>*Professionalism*, there is nothing unique to OO that makes it more
>professional that any other technique.

	I am not trying to make the point that OO is more professional than any
other technique. IMO, OO has a rich set of principles that makes ME see it
as a discipline besides being a technology. As a discipline that I practice, I find
myself more determined to identify and correct OO errors and bad practices
that others may let go for the reasons I mentioned above. I believe in OO and I
want to promote it. I want others to see OO as a discipline in addition to being
an excellent technology, IMO.  

------------------------------------------------------------------------
Patrick Ma                              < pma@partssolution.com >
partsSolution, Inc.                     < http://www.partssolution.com >
IBM Certified VisualAge for Smalltalk Developer
< SmallNews - a Smalltalk UQWK editor for offline news editing >

RE: What is wrong with OO ?

[Patrick Ma]

On 12/18/96 Ell <ell@access5.digex.net>  wrote:

>Harry Protoolis (harry@matilda.alt.net.au) wrote:
>: On 14 Dec 1996 23:19:51 -0500, Patrick Ma <pma@panix.com> wrote:
>: >On 12/14/96 Robert C. Martin <rmartin@oma.com>  wrote:
>: >
>: >>OO is not a motivational discipline.  It does not take willpower and
>: >>determination to "do things right".  Rather it takes knowledge and skill.
>
>: >Without a doubt, it takes knowledge and skill to "do things right" in OO.
>: >However, I do think OO is a discipline and it does take willpower and 
>: >determination together with knowledge and skill to "do things right."
>
>I do not think it's primarily any of those things.  I think mainly its a
>matter of approach and perspective.

Elliott,

	Perhaps, we are all driving at the same goal using different terminologies.
The point I am trying to make is when I have the chance to preach/teach OO, I
want to not only make it a technology issue. I like to also make it as a discipline
so that people can follow and practice OO principles with consistency. You use 
the words approach and perspective and Harry used professionalism. Correct
me if I am wrong. I see these words also promoting 'follow and practice OO
principles with consistency.'   

>: >It is willpower and determination of OO discipline that is going to
>: >lead us to 
>: >break through these hurdles created by our very own minds. 
> 
>: What's OO got to do with it ?
>: 
>: Idenitifying and changing errors and bad practices is a matter of
>: *Professionalism*, there is nothing unique to OO that makes it more
>: professional that any other technique.
>: 
>: Of course, turning professional programmers into 'code monkeys' is just
>: begging for this sort of problem ...
>
>Many programmers turn themselves into "code monkeys".  Imo, because they
>belittle the big logical picture.

	Can I say they got turned into "code monkeys" because they didn't have
professionalism, the right approach and prespective or discipline? :) I hope we
are all saying the same thing.


------------------------------------------------------------------------
Patrick Ma                              < pma@partssolution.com >
partsSolution, Inc.                     < http://www.partssolution.com >
IBM Certified VisualAge for Smalltalk Developer
< SmallNews - a Smalltalk UQWK editor for offline news editing >

Re: What is wrong with OO ?

[Nick Leaton]

Robert C. Martin wrote:
> I agree that the dependency is one way.  But the direction is towards the
> architecture.  Classes belong to architectures; they conform to the rules
> and protocols that those architectures demand.

I suspect that there is a difference of understanding of the word
'architecture' My understanding is the framework that glues classes
together.

If you believe that architecture comes first, how do people design and
code lower level libraries, that don't in themselves do anything, unless
they are part of an architecture? When they are designed, the
architectures in many case have not been designed.
-- 

Nick

Re: What is wrong with OO ?

[Tansel Ersavas]

Robert Dewar wrote:
> 
> Tansel says
> 
> "First of all, my opinion is, developing systems with procedure oriented
> techniques is a dangerous, wasteful and unproductive process."
> 
> It is this kind of unsupporable hyperbole that gives OO a bad name!

Unsupportable? Hyperbole? Are we mentioning about the software gap, or
failed projects, or wasted money?
Why don't you look at statistics about these?

Turning a blind eye on Today's problems will not get us anywhere. First
of all, we should admit that we have a problem, then find a solution to
it. We ALL contribute to lost billions by ignoring what's happening
around us. 

> Why is it that when anyone comes along with new techniques that represent
> a useful incremental advance in our knowledge in this area (e.g.
> functional programming, proof of correctness, your-favorite-fad-here)
> they feel compelled to hype them like this with the approach

OO is not an incremental advance. It has started and continued that way,
because SIMULA was an extension to Algol, and some of the most dominant
languages are extensions of procedure oriented languages. This does more
harm than good to OO. Many professionals I have talked to told me that
until they made a switch ( or some of them call it a "click") they
weren't able to benefit from OO a lot. It is more difficult to have that
"click" if we have to work in an environment and a language which is
basically an OO extension to a procedural background. 
It is true that every newcomer announces that it is a significant
advancement over procedure orientation. This is because people are
worried about the current paradigm, and they in search for a better one. 

> "what we have done before is an unmitigated disaster, but my new technique
> will make a revolutionary difference".

These are not my words

> The trouble with such hype is that inevitably it does not deliver, and then
> there is a danger of throwing out the baby with the bathwater and
> discarding what is useful along with the hype.

OO as is now, is a struggling, and not much appreciated figure around.
It has its troubles, but they are slowly being ironed out. Yes, there
may be a short term backlash against OO, it may even go back a couple of
years. This is not important. It will come back, and will eventually
dominate.  

> The fact of the matter is that there is NO giant shift of paradigm involved
> here, despite what anyone says. Just look at the OO programs that people
> produce. They are not radically different from conventional procedural
> programs, and one would not expect them to be.

Unfortunately, many OO programs that people produce are produced by
people who are learning. They will be better and better, the gap will be
larger and larger, and differences will be more and more obvious.

People have short memories. A very similar sort of discussion with
similar tones was done when first high level languages were introduced.
Proponents of machine code and assembly languages said, this new
paradigm was nothing new, just a bigger, bulkier way of doing the same
thing with speed penalties, it was not practical, people would never
program with them in masses, etc, etc. Now we see everything has settled
down, there are still people write code in assembly and nothing else,
however they are the minority.

Same things will happen with object orientation. It is a big paradigm
shift even if you deny it. The current object orientation that we use is
a layer on top of procedure oriented architectures. That may fool some
people into thinking that OO is an incremental advance. It is not. The
real benefits of OO will come when the underlying architecture supports
it. Then, a new breed of object oriented OSs, languages and tools will
emerge, and procedure orientation will shrink into minority. 

> OO techniques are a useful way of extending the conceptual design domain,
> and OO features in programming languages allow added flexibility in
> the solution space. Good! But trying to fit everything into the OO mold
> is as reasonable as believing these ads on TV that suggest that all your
> handy-man's problems at home can be solved with one amazing tool!

So far, we benefited marginally by molding everything into procedure
oriented paradigm even if it did not naturally fit into it. In fact we
tried to use one amazing tool called procedure oriented paradigm for
every one of our problems. I admire what we achieved with it because it
requires much greater talent and effort than molding everthing into an
OO paradigm. But this extra effort and talent can be used somewhere else
if we can embrace methodologies which teach us ways of easier and more
economical ways of doing it.

Kind Regards
Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: What is wrong with OO ?

[Tansel Ersavas]

Adam Beneschan wrote:

> "Every training should include a motivational component"???  This is
> probably true for trainings that are likely to include a bunch of
> unmotivated people who don't want to be there and are in the training
> only because their boss is making them and who were hoping to go
> through the rest of their lives making money by doing the same thing
> over and over without having to learn anything new.  Hopefully, I
> wouldn't have any such people working for me.  I also wouldn't want
> employees who are able to get so excited that they would "eagerly
> accept" what a teacher is teaching them; I'd prefer those who are
> smart enough to look at the material analytically, so that they would
> understand when, how, and why to apply it.

I would like to congratulate you if you  were able to organize such a
group. IME only small software houses or very autonomous, independent
sections of big companies are able to collect such people. Sadly, in
many other cases there are a bunch of people in the courses just because
their company want them to be in that course. If you have a group of
people who know what they want, and ready to absorb, that would be
great. IME, even for eager classes , still use a touch of motivation,
which is embedded in my own (as you say) eagerness, and ability to show
what can be done with OO, and how different and better it would be. 
Also my mention of motivation shouldn�t be mixed with pure motivational
techniques, which I also use sometimes at my and the people�s
discretion.  Training can be thread by itself, and I guess it has no 
place in comp.object unless it is "how to teach OO" which I think should
be discussed as well. Meanwhile I know the effectiveness of my
techniques, and I�ll continue to use them.
 
> 
> [By the way, I'm speaking as someone who spent a lot of time and money
> in the past in courses that could be called "motivational" or
> "self-development" seminars.  While they did me a world of good, my
> experiences have convinced me that the practice of exciting trainees
> so that they accept things eagerly (and unquestioningly) has great
> potential for harm as well as for good.]

That's true, but what harm could they get from eagerly learning OO?
Applying it more rigorously? IME I get more benefit, and hardly any
harm. 

> Finally, does anyone else feel insulted by Tansel's post?  There seems
> to be an undercurrent that those who don't believe in OO as fervently
> as he does [I'm assuming Tansel is a "he"] are unmotivated, have
> "given up", don't want to learn anything new, are "followers", etc.
> This seems like it would be insulting to many truly professional
> engineers.

The quote about the "pioneers", "early adopters" "followers" etc. comes
from  "Diffusion of Innovations" by Everett Rogers, and I quote it a lot
along with the percentages. However, I haven't had anybody offended or
insulted by these statistics. Yes,  IMO anybody joining OO before OO
becomes a mainstream will be pioneers or early adopters. If you are
looking at penetration of OO to the mainstream computing, we are far off
the mainstream as yet. So I couldn't have possibly said or implied that
anybody not coming to the OO bandwagon right now would be followers. 
Besides, even if I implied that, what could be wrong if someone chooses
to be a follower? I have the strong belief that people have a right to
be where they are, and do what they want. From time to time, I would
like to be a follower, rather than a pioneer or an early adopter, and
that would be my choice. Anyone pointing that out to me, I would simply
state my reasons to be a follower, and listen to the other person with
an open mind. I would choose to be a follower or even a conservative if
I think that there won't be any benefits, or even some harm can be done
by following a certain path. So even if someone declares that they are a
conservative, I would listen to what they say, try to understand their
reasons. Because I can learn from them, and to a conservative I am the
other extreme. I would hope that he or she could do the same for me.

Sometimes there is a wisdom of being ahead or behind, it is very
healthy, and I have respect for ALL of them.

All I want to do is create a little bit excitement for OO, because I can
clearly see the benefits of it. So I want everybody to look into it.  

BTW I heard the "given ups" comment from a child at one of our
conversations about computers, and I sometimes quote it because it is an
interesting point of view to come out of a 10 year old , not in any way
to deride people.

>                                 -- Adam
Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: What is wrong with OO ?

[Tom Bushell]

On Tue, 17 Dec 1996 00:45:47 -0800, Tansel Ersavas <tansel@deep.net>
wrote:

>I think, we can now show people how visual programming can really bump
>up their productivity. It also accelerates learning, and promotes more
>high level thinking. Visual programming is to textual programming what
>is textual programming to assembly language.

Good analogy.  Although this may sound like marketing hype, my
exposure to _true_ visual programming tools (ie the Prograph language)
leads me to believe that Tansel is not just talking through his hat.
Sounds like Snowball does many of the things I've been advocating in
other posts to this thread.

So, when will Snowball be available?  What Smalltalks does it run
with?  Cost?

Tansel, if you need a beta tester for the MS-Windows version, keep me
in mind.  :-)

-Tom



----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Risto Lankinen]

Hi!

Matt Austern <austern@isolde.mti.sgi.com> wrote in article
<fxtohfrfpkk.fsf@isolde.mti.sgi.com>...
> Tansel Ersavas <tansel@rase.com> writes:
> 
> > > Is it really?  Can a painting communicate subtle ideas as clearly as
> > > literature?
> > 
> > A picture is worth a thousand words.
> 
> So is a picture worth five hundred words?  Can someone come up with a
> picture that says the same things that this 552 word article does?

Of course no one can.  Put another way, someone might say...

"A high level language statement is worth ten machine instructions"

... and still not be able to represent most given ten machine instructions
in a single statement of any HLL (if at all).

terv: Risto

Re: What is wrong with OO ?

[Tom Bushell]

On 18 Dec 1996 19:19:05 GMT, mbk@caffeine.engr.utk.edu (Matt Kennel)
wrote:

>: >Visual programming is to textual programming what
>: >is textual programming to assembly language.
>
>: Good analogy.
>
>Is it really?  Can a painting communicate subtle ideas as clearly as 
>literature?

Sometimes more clearly, and more efficiently - although perhaps the
ideas are less verbal.  Think of the Mona Lisa's smile, Alanis
Morrissette's expression in her videos, the sense of grandeur and
isolation you often get from a single shot in a Kubrick movie...

I think this is an artistic analogy, and I'm more comfortable with
engineering analogies for software development (though I don't deny
that there's a strong element of craft or art in SW development when
practiced well).

Most other engineering disciplines use visual representations as
fundamental tools.  Civil engineers use blueprints, electrical
engineers use schematics, and so on.  IME, a good diagram _is_ worth a
thousand words.  (Unfortunately, I haven't seen many good diagrams for
SW systems.)  The main benefits I see are quickly conveying larger
scale structure, and connections and relationships among system
components.  Text is too linear to convey this sort of information
well, although text is a necessary adjunct to most diagrams.

I basicly agree with Tansel - programming will become much more visual
in the medium term future.  Text will still be required, but mainly
for commenting, not for code.

What makes a good diagram is a fascinating subject, but way off topic
for this thread.  I'm starting a new one on comp.object and
comp.software-eng, if anyone's interested.

-Tom


----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Ell]

Tom Bushell (tbushell@fox.nstn.ns.ca) wrote:
: On 18 Dec 1996 19:19:05 GMT, mbk@caffeine.engr.utk.edu (Matt Kennel)
: wrote:
: 
: >: >Visual programming is to textual programming what
: >: >is textual programming to assembly language.
: >
: >: Good analogy.

: >Is it really?  Can a painting communicate subtle ideas as clearly as 
: >literature?
 
: Sometimes more clearly, and more efficiently - although perhaps the
: ideas are less verbal.  Think of the Mona Lisa's smile, Alanis
: Morrissette's expression in her videos, the sense of grandeur and
: isolation you often get from a single shot in a Kubrick movie...

Diagrams should be the major deliverable between the analysis,
architecture, and object/category design phases.

Elliott

Re: What is wrong with OO ?

[Jeffrey C. Dege]

On 18 Dec 1996 19:19:05 GMT, Matt Kennel <mbk@caffeine.engr.utk.edu> wrote:
>Tom Bushell (tbushell@fox.nstn.ns.ca) wrote:
>: On Tue, 17 Dec 1996 00:45:47 -0800, Tansel Ersavas <tansel@deep.net>
>: wrote:
>: >Visual programming is to textual programming what
>: >is textual programming to assembly language.
>
>: Good analogy.
>
>Is it really?  Can a painting communicate subtle ideas as clearly as 
>literature?

Easily.  Can painting communicate non-visual ideas as _precisely_ as
literature?  Not a chance.

-- 
Never worry about theory as long as the machinery does what it's
supposed to do.
		-- R. A. Heinlein

Re: What is wrong with OO ?

[Nick Leaton]

Tansel Ersavas wrote:
> Or take guinea pigs, they are lovely pets, but they are wasteful, and
> unproductive IF you have all females (males tend to fight, and
> male-female combinations are extremely productive) but they just are,
> they make cute pets and we enjoy them.

If you want, I can find you some recipes.
-- 

Nick

Re: What is wrong with OO ?

[Tansel Ersavas]

Tom Bushell wrote:
> 
> On Tue, 17 Dec 1996 00:45:47 -0800, Tansel Ersavas <tansel@deep.net>
> wrote:
> 
> >I think, we can now show people how visual programming can really bump
> >up their productivity. It also accelerates learning, and promotes more
> >high level thinking. Visual programming is to textual programming what
> >is textual programming to assembly language.
> 
> Good analogy.  Although this may sound like marketing hype, my
> exposure to _true_ visual programming tools (ie the Prograph language)
> leads me to believe that Tansel is not just talking through his hat.
> Sounds like Snowball does many of the things I've been advocating in
> other posts to this thread.

We are glad to see our ideas are shared by professionals. I personally
believe in visual programming, even though I am still a command-line
person from time to time, especially in Unix. But with the right tool,
even if we don't spend the majority of our time in the tool, we can
achieve a lot, as I observed it in the case with Snowball. I also find
it very useful as a documentation tool. In many projects, even though
documentation is kept in high $$ CASE tools, it is practically
impossible to reverse engineer the entire system and regenerate the
document every time documentation is required. Snowball generates this
documentation every time directly from the source, because Smalltalk is
used as a specification and a repository for all the documentation
information. So it is very useful even for people who won't do any
visual programming, but want to have access to the visual views of their
system at any time on demand, such as presentations. 

Most visual tools limit us do things their own way. They look nice in
demos, but when we start using them in real life, we feel limited. That
is one of the issue we wanted to address clearly in Snowball. We wanted
Snowball to be a non-intrusive tool.  When it is invoked, Snowball will
understand your work without forcing you to any special format, or
restrictions. It is available within a matter of seconds, and after you
have made your changes, or even while you are doing changes, you can
return to the Smalltalk environment and do what you want there.

> So, when will Snowball be available?  What Smalltalks does it run
> with?  Cost?

Snowball Rapid Systems Engineering Tool is currently available for
purchase from our site for VSE only. We do not promote it as yet,
because we are waiting on some non-technical issues to be resolved. We
will announce it either late December, or very early January. We plan to
come out with ST/V STExpress version, followed by IBM VA, and VW.

Costwise, we are determined to keep it as down as possible. Our aim is
to make Snowball available to every OO enthusiast at a reasonable price.
Our current target is for most versions, the basic edition without
source should be under $200, and the developers edition with source and
meta-tools for developing your own extensions-graphical notations with
extensive documentation should be under $600. If we can release a
STExpress edition, we want to keep it under $100.
 
> Tansel, if you need a beta tester for the MS-Windows version, keep me
> in mind.  :-)

We will certainly do that, Tom. I'll contact you via e-mail after the
new year's day.
 
> -Tom

Tansel Ersavas
Designer and Developer of Snowball Rapid Systems Engineering Tool
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: What is wrong with OO ?

[Robert C. Martin]

In article <dewar.850825775@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> The fact of the matter is that there is NO giant shift of paradigm involved
> here, despite what anyone says. Just look at the OO programs that people
> produce. They are not radically different from conventional procedural
> programs, and one would not expect them to be.
> 
> OO techniques are a useful way of extending the conceptual design domain,
> and OO features in programming languages allow added flexibility in
> the solution space. Good! But trying to fit everything into the OO mold
> is as reasonable as believing these ads on TV that suggest that all your
> handy-man's problems at home can be solved with one amazing tool!

I certainly agree with this sentiment; with one minor exception.
While there may not be a "Giant Shift" of paradigm; there is a paradigm
shift, and it can be overwhelming for some.

The shift is, for the most part, a shift in priorities.  We shift our focus
from the details of what needs to be done to the structure of the code that
will do it.  We think more in terms of abstractions and interfaces than
functions and data.  We guard against undesirable dependencies rather than
just depending on what we think we need at the time.  We think about
cogent groupings of data and function that can implement those interfaces as
a single unit rather than just the data and functions that will do the job.

Some engineers have a great deal of trouble making this kinds of shift. In
some cases the problem is conceptual.  i.e. the engineer just can't see the
interfaces, the groupings, the structure, etc.  In other cases the problem
is a fear of overdesign.  By building the abstractions and structures the
engineer feels that he/she is wasting time and not actually making the
program work.

In either case, the shift of thinking, the paradigm shift, can be quite
difficult to make.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Robert C. Martin]

In article <01bbec50$0abb3380$371883cc@beast.advancedsw.com>, "Roger T."
<roger@advancedsw.com> wrote:

> Let's assume that coders are given the freedom to discard their prototypes.
> The next problem facing me as a manager is to make sure they actually use
> that freedom.
> 
> The desire to paste functionality onto the prototypes to "fix" them so they
> support new functionality is very seductive when it means a short term time
> savings. To some extent you are re-inventing the wheel, though in a better
> form.
> 
> Designers must realize that prototype extinction is not only allowed but is
> encouraged if it has the effect of creating long term product robustness.
> 
> How would you encourage/enforce that philosophy with your developers?

One of my clients produces a document called: "Flexibility requirements".
These enumerate all the different flexibilities that the software must have.
e.g. That it must be easy to make certain kinds of changes, that it must be
easy to port to certain platforms, that it must be easy to replace certain
policies without affecting others, etc.

His test plan includes tests for these flexibilities.  

Thus, any prototype that does not meet these flexibility criteria must
be redesigned.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Matt Kennel]

Roger T. (roger@advancedsw.com) wrote:
: Matt Kennel <mbk@caffeine.engr.utk.edu> wrote in article
: <599fak$l5v@gaia.ns.utk.edu>...

: > 
: > : This brings up a succeeding issue.
: > : How would you encourage/enforce that philosophy with your developers?
: > 
: > Perhaps I am naive, but what about asking them?
: > 
: >      "How much of the prototype did you keep?  Was it good enough to keep
: >       or do you wish you would have time to re-do it from scratch?  Don't
: >       assume I wouldn't have let you." 

: That is certainly one avenue. However I can imagine that this we become
: annoying if someone was constantly asking these questions.

: I guess what I am really after are some subtle structural or procedural
: techniques that could be made integral to the development
: environment/process and would encourage prototype extinction without
: overtly badgering the developers.

Who cares about subtle??

"If you re-do the full framework and deliver on time and I agree that it's
 really cool, you get a $5,000 bonus." 

--
Matthew B. Kennel/mbk@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/ 

Re: What is wrong with OO ?

[David Bradley]

mbk@caffeine.engr.utk.edu (Matt Kennel) wrote:

>Is it really?  Can a painting communicate subtle ideas as clearly as 
>literature?

The thing that comes to my mind, is if visual is so much better then
why are we still "reading" books.

I'm sure visual has its advantages, but I think at best the visual
would augment written programming not supplant it.

--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com

Re: What is wrong with OO ?

[Robert C. Martin]

In article <32B758D7.61EF@deep.net>, tansel@deep.net wrote:
> 
> a) Software industry is in a crisis. 
> b) The application gap is still growing
> c) Every year abandoned software costs the world economy unmentionable
> billions of dollars.
> d) Even many so called successful projects Today are big money drains
> e) The approach we use for systems development influence a, b, c and d
> 
> How can we justify massive collapses of big systems with hundreds of
> millions of dollars down the drain with a cool face? If we don't call
> this a failure, what are we going to call? If it not waste, I would like
> to learn your definition of waste. And, dangerous, yes, because it
> creates a false sense of security once people get used to it.

The logical leap that you are making is that "procedural programming" is
responsible for points a-e.  I'd like to see some concrete evidence to
that effect.  The other logical leap you are implying is that OO corrects
points a-e.  Again, I'd like to see some empirical evidence.

Now, my belief is, (and my own experiences bear this out) that proper
(repeat *proper*) use of OO techniques can help to make large software
projects somewhat more maintainable, more flexible, more robust, and more 
reusable. (Did I get all the buzz words in there?)  Not that they didn't
have some of those traits before; its just that OO can enhance those
particular traits by some amount.  And it seems reasonable (although I
have only the most miniscule amount of real empirical evidence to 
support this) that enhancing these traits has an impact upon your points
a-e above.  But I have no proof as yet.  And, as far as I know, neither
does the industry at large.

On the other hand, there are costs associated with OO.  Done properly,
the structural complexity of applications increases, sometimes dramatically.
This complexity is what enhances the maintainability, flexibility, etc.  But
the cost is real.  I have experienced the payback.  I know that OO is
almost always worth the cost.  Indeed, when a large supply of reusable
components is assembled into a framework, the savings can be significant.
But the cost must still be paid.  (See my paper "ETS Case Study" available
from the freeware section of my website).

Another point is that there is massive confusion in the industry regarding
methodology.  Should you use Booch?  OMT?  UML? How about Shlaer/Mellor?  Some
of these methods are remarkably different from the others.  Which one yeilds
the best benefits.  IMHO, some of them work quite well, and some are 
exceedingly dangerous.  But who do you believe?

Thus, for the typical software manager, the costs of OO may overwhelm the
potential benefits.  If he makes the wrong choices with respect to methodology,
if he fails to adequately train his people in the proper use of OO, if he
expects to immediately reduce his costs, then for him OO will be more wasteful
and dangerous than procedural.

The manager who is careful to research the methods, who checks as much
empirical data as possible, who carefully runs trials without committing
his whole organization, who energetically trains his people, who makes
sure they are properly mentored during their first few projects; this manager
may reap the benefits of OO by producing systems that are easier to change, 
easier to maintain, and easier to reuse.  This manager may be able to build
up a stockpile of reusable software and arrange it in a framework that allows
applications to be developed in significantly less time than before.  But those
are very big IFs.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Robert I. Eachus]

In article <01bbec0b$03cb9690$1e8c71a5@dhoossr> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:

   > It was Senator Everett Dirkson (I am not 100% sure of spelling) from
   > Illinois, and the original quote is billion not million :-)

   Actually, the original was, "A hundred million here, a hundred
million there.."

   I believe he said it during a debate about expressing the federal
budget resolution to the nearest hundred million instead of the
nearest $10,000.  (For those not familar with the details of US
government budgeting, the budget bill is where most of the infighting
takes place, but the appropriations bills actually parcel out the
money.)


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: What is wrong with OO ?

[Samuel Mize]

In article <32B3DD77.2F17@deep.net>, Tansel Ersavas  <tansel@deep.net> wrote:
>drush@zakalwe.raleigh.ibm.com wrote:
>
>> Regarding Objects & "real-world" modeling: I have also seen this as primarily
...
>OO provides us with a set of tools to abstract things in the real world,
>imagined worlds, or anything. We should remember that there is a
>discipline which their entire aim is to model the real world as close as
>possible, and this discipline is simulation, not OO. There you need your
>system to match the current reality as close as possible. OO can be used
>for that, better then most other techniques available Today, and in fact
>guess why Simula, the ancestor of most object oriented languages was
>developed. 

This discussion has been pushing one of my hot buttons, and you just
crystallized my response.  Thanks!

One of my problems with many OO "gurus" is the frequent mantra that the
OO products should match the real world's objects, right down to the code.
They claim that this will make the code easier to understand, and that
current processors are so fast that any moderate inefficiency is invisible.

Both of these claims are patently false.

I work in simulation.  A critical issue in simulation is "level of
fidelity" -- how closely do you want to simulate the real-world object?
More fidelity implies greater cost.

I've seen subsystems that could have been coded simply, that became
baroque and incomprehensible because they tried to hew to the "real
world model" approach instead of computing the needed results.

I've seen a subsystem burning multiples of its execution-time budget
because it was coded to map to the real world.  Specifically, we
were using a hydraulic model to generate realistic flow dynamics, when
a binary flow/no-flow model would have been adequate.  This wasn't
directly an OO problem -- we should have timed large models much
earlier than we did -- but the OO paradigm, as promoted in that project,
helped obscure the problem until late in development.

I have often found object-oriented analysis, design and coding methods
to be extremely helpful.  I look forward to being able to use Ada95's
OO features in a significant way (right now I'm doing maintenance and
upgrade work).

But I have heard too often the claim that an OO design should just be
a deeper iteration of the analysis, and I haven't found that to be the
case.  Even after the project is done, the analysis and design should
often NOT match -- although the mismatches should be understood,
explained, and documented.

The analysis should match the real world -- it should show what the
real world will be like with your system in it.  The design should be a
structure that will implement (part of) the analysis model, and it might
do so differently from a current real-world system, or from an external
view of its actions.

Figuring out the DIFFERENCES that should exist between the analysis and
design models is the essence of high-level OO design.

>> The "real-world" is the system that you're replacing. To inflict that structure
>> on the system you're designing can be a *BIG* mistake.
>
>Depends, it may be, or it may not be.

Yep.  It may not be, but it "can be a *BIG* mistake."  As you said,

>However, in the man made world we call "real", there are a lot of things
>you don't want to incorporate into your design.

I think we three basically agree.  Thanks for sparking me off.

Samuel Mize

Re: What is wrong with OO ?

[Robert C. Martin]

In article <32B7C305.3970@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk> wrote:

> Robert C. Martin wrote:
> > I agree that the dependency is one way.  But the direction is towards the
> > architecture.  Classes belong to architectures; they conform to the rules
> > and protocols that those architectures demand.
> 
> I suspect that there is a difference of understanding of the word
> 'architecture' My understanding is the framework that glues classes
> together.

That is also my definition.
> 
> If you believe that architecture comes first, how do people design and
> code lower level libraries, that don't in themselves do anything, unless
> they are part of an architecture? When they are designed, the
> architectures in many case have not been designed.

Architectures often arise out of humble beginnings.  One might design a 
small libarary of utilities and then discover an abstraction that makes
that library easier for users to use.  That abstraction becomes part of
the architecture.  The library may have come first, and have seeded the
architecture.  

That's not always the way it works, but sometimes it does.  Other times
the architecture is born before the libraries are fleshed out.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Jon S Anthony]

In article <599g39$l5v@gaia.ns.utk.edu> mbk@caffeine.engr.utk.edu (Matt Kennel) writes:

> Tom Bushell (tbushell@fox.nstn.ns.ca) wrote:
> : On Tue, 17 Dec 1996 00:45:47 -0800, Tansel Ersavas <tansel@deep.net>
> : wrote:
> 
> : >I think, we can now show people how visual programming can really bump
> : >up their productivity. It also accelerates learning, and promotes more
> : >high level thinking. Visual programming is to textual programming what
> : >is textual programming to assembly language.
> 
> : Good analogy.
> 
> Is it really?

Typically, no.

> Can a painting communicate subtle ideas as clearly as literature?

In general, no.  Also, they don't convey abstract ideas too well
either.

And it is a well known problem that it is rather difficult to convey
information consisting of many dimensions (facets) visually that does
not lose semantic content.  3D even 4D, not too much a problem.
100-D?  Infinite-D?  How about transfinite?  These are all more or
less trivial to capture algebraically.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Jon S Anthony]

In article <32B89D8D.7999@rase.com> Tansel Ersavas <tansel@rase.com> writes:

> A picture is worth a thousand words.

A cliche with only limited basis in reality.  Give me a single picture
that conveys the total information caught by "mountain".


> Besides, it is much more easier to teach people visually, if it is done

It is well known that this depends on the cognitive bias of the
person.  A cut with an ax taxonomy would start with "geometers" and
"algebraists"


> Still I believe that the next generation will work predominantly with
> pictures and will rarely revert to bulky chunks of text

Hmmmm, do you really think any attempt you try to provide for my first
question will be any where near as light weight as "mountain"???????
Take a look at the "byte-size" of even the simplest graphic in any
representation you care to and compare it to a "corresponding textual
description".

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Tom Bushell]

On 19 Dec 1996 06:36:05 GMT, jdege@jdege.visi.com (Jeffrey C. Dege)
wrote:

>>Is it really?  Can a painting communicate subtle ideas as clearly as 
>>literature?
>
>Easily.  Can painting communicate non-visual ideas as _precisely_ as
>literature?  Not a chance.

"How is a raven like a writing desk?" -The Mad Hatter

My whole point here is to grope towards better ways to think about and
represent software systems.  

Do I think a software system is like a painting?  No.

Do I think a software system is like a novel or other work of
literature, designed to be read from start to finish?  No.  Do you?

Do I think a software system is like a technical document or user's
manual - highly structured, and designed to be read non-linearly?
Sort of.

Do I think a software system is like an electronic schematic -
emphasizing connection and flow - in parallel?  You betcha! ;-)

-Tom





----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Bill Gooch]

Jon S Anthony wrote:
> 
> Give me a single picture
> that conveys the total information caught by "mountain".

Easy - I have lots of mountain pictures.  Any one will do.

> Hmmmm, do you really think any attempt you try to provide for my first
> question will be any where near as light weight as "mountain"???????

The word "mountain" *by itself* conveys nothing whatsoever.
Its meaning is known via a learned association, which is
not inherent in the word itself.  It could just as well mean
"a small furry animal with a pink nose," if we chose to use 
it that way.  A picture of a mountain, OTOH, needs no 
definition, and carries a lot more than just the generic 
concept "mountain" with it - it shows the specific shape
and character of a particular mountain, i.e. it has a much 
more refined meaning than the word, or quite a large verbal
description, for that matter.  Try to describe the geometry
and terrain detail shown in the picture verbally, and it 
will no doubt take quite a few thousand words. 

None of this has much bearing on the use of diagrammatic 
object models for OO analysis and design, however.  Those
models are of abstractions, and have no "natural" interpretation
by themselves.  Like words, their meanings must be defined.  
Still, a few graphic symbols put together can often carry the 
same meaning as quite a few words.  IME, both the diagrams
and the words that describe them (especially in terms of object
dynamics, which are very hard to show using static graphics)
can be very helpful.

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: What is wrong with OO ?

[Nigel Tzeng]

In article <32b00803.2304210038@news>,
David Bradley <davidb@datalytics.com> wrote:

[snip]

>Unfortunately they jumped into the OOP pool without first learning how
>to swim.  They may have taken a lesson or two and could hold their own
>in calm waters, but when things get rough they drown.  In stead of
>realizing they lack knowledge and accepting the responsibility for
>their failure they point the finger at OOP.

Well...never ever try to run a project with a new technique, process
or metholodgy unless you have a few folks who have "mastery" over it
and the majority of the staff at the "journeyman" level unless you
don't particularly care about if it delivers on time or not.

I don't believe that statistics of this sort either "prove" or
"disprove" that OO is a success or failure.  On the other hand it does
show that once again silver bullets don't exist and if you have a shop
of SASD folks you need invest quite a bit of money and time before
expecting to EQUAL current levels of productivity and quality.

After all there are a lot of shops finally getting SASD more or less
correct that blowing away a mature process for eventual improvement
two or three projects down the line may not be the worlds brightest
move a company banking on the success of the current project.

I wonder how many SEI level 4+ orgs are OO vs SASD.

>David Bradley         davidb@datalytics.com

Nigel Tzeng
  

Re: What is wrong with OO ?

[Chris Brand]

David Bradley wrote:
- 
- mbk@caffeine.engr.utk.edu (Matt Kennel) wrote:
- 
- >Is it really?  Can a painting communicate subtle ideas as clearly as
- >literature?
- 
- The thing that comes to my mind, is if visual is so much better then
- why are we still "reading" books.
- 

Kids aren't. They're watching TV or movies.

-- 
Chris
Stating my own opinions, not those of my company.

Re: What is wrong with OO ?

[Tansel Ersavas]

Jon S Anthony wrote:

> 
> > Can a painting communicate subtle ideas as clearly as literature?
> 
> In general, no.  Also, they don't convey abstract ideas too well
> either.
> 
> And it is a well known problem that it is rather difficult to convey
> information consisting of many dimensions (facets) visually that does
> not lose semantic content.  3D even 4D, not too much a problem.
> 100-D?  Infinite-D?  How about transfinite?  These are all more or
> less trivial to capture algebraically.
> 
> /Jon

Well, that explains the popularity of algebra around circles. We use
canonical forms of systems to get only the "relevant" information about
that system for our certain needs. Nobody is talking about representing
the entire information in one diagram, or even representing entire
systems with only diagrams. However, I will not debate the usefulness of
diagrams. It is trivial dealing with 10,000 lines of code, but if you
have a million lines of code, you have no other way but summarize some
of the information into some diagrams if you want to communicate them
effectively. (Unless of course, you want to stuff them into 100-D
matrixes).

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
                               A.C. Clarke
-----------------------------------------------------------------------

Re: What is wrong with OO ?

[Tansel Ersavas]

Robert C. Martin wrote:
> 
> The logical leap that you are making is that "procedural programming" is
> responsible for points a-e.  I'd like to see some concrete evidence to
> that effect.  The other logical leap you are implying is that OO corrects
> points a-e.  Again, I'd like to see some empirical evidence.

It is known that a vast majority of Today's systems (about 92%) are
procedure oriented systems. Do you think this is not enough? 
OO corrects this? There are no controlled studies so far, however we
plan to start one using our systems development tool late next year in
colloboration with various universities. There is also a big problem
with how we interpret, and apply OO which in most cases I observed far
less than optimal. 

> Another point is that there is massive confusion in the industry regarding
> methodology.  Should you use Booch?  OMT?  UML? How about Shlaer/Mellor?  Some
> of these methods are remarkably different from the others.  Which one yeilds
> the best benefits.  IMHO, some of them work quite well, and some are
> exceedingly dangerous.  But who do you believe?

With most dominant methodologies molding to one, the holy "Unified"
methodology with Booch, Rumbaugh and Jacobson together, I guess the
current battle is over with them having a big chunk of the market, at
least for now. I still expect some more action in methodologies corner,
especially from the RDD side. 
Which methodologies are you referring to as exceedingly dangerous ones?
 
> Thus, for the typical software manager, the costs of OO may overwhelm the
> potential benefits.  If he makes the wrong choices with respect to methodology,
> if he fails to adequately train his people in the proper use of OO, if he
> expects to immediately reduce his costs, then for him OO will be more wasteful
> and dangerous than procedural.
 
> The manager who is careful to research the methods, who checks as much
> empirical data as possible, who carefully runs trials without committing
> his whole organization, who energetically trains his people, who makes
> sure they are properly mentored during their first few projects; this manager
> may reap the benefits of OO by producing systems that are easier to change,
> easier to maintain, and easier to reuse.  This manager may be able to build
> up a stockpile of reusable software and arrange it in a framework that allows
> applications to be developed in significantly less time than before.  But those
> are very big IFs.

This is a problem I observed when I first started practicing OO. Your
observations parallel mine where switching to OO techniques were brought
at a significant cost. It does not have to be that way. 

OO in its current form is costly, because it is pushed as a useful
incremental advance over the procedural techniques. I will explain why.
<< Please do not separate any of this segment to quote,  because it is
extremely important that it is presented as a whole to keep its meaning
>>
<< Begin segment >>
We have been taught to solve problems in a certain way (i.e.
procedurally). When we are introduced to OO, we still subliminally think
in procedural terms.  The OO techniques are taught, and the development
process starts. We think, "OK, these concepts of classes and objects,
inheritence, polymorphism, and encapsulation seem to be cool" and start
applying these techniques.

If we stop there, by doing nothing but exactly using these above, all we
can get is very much like a manual and labor intensive data compression
over our procedural approach. Inheritance, besides creating a much
greater understanding about what we are dealing with, allows us to
structure our classes in nice tree forms so that we can locate
duplicated chunks easily, and promote reuse through automatic access to
procedures and data at higher levels through generalization and
specialization. Polymorphism simplifies things by allowing us to use
same familiar interface to custom tailored individual response, and
encapsulation allows us to hide implementations of these classes and
objects from others. 

All the above gives us is a different, but neat looking way of  solving
problems. We start developing systems with this approach, soon we find
out that it is difficult. Why? Because we are manually applying a "data
compression" like algorithm on top of our existing procedure orientation
approach. We can not haphazardly introduce new data and code, we have to
know about the system a lot. In the end, after a sweating experience, we
can show that our new system took longer to develop, however, it looks
somehow simpler, this much shorter and that much easier to maintain. 

If this is the approach we are taking, it is not going to be
significantly better the next time. Because we will still be using the
same compression algorithm, slightly improved after our lessons from the
first project. The results of the previous systems development effort
can offer us some reusable material, but no one will bother unless it is
made extremely simple by creating  repositories over this vast
structure. Using this technique, depending on our understanding of the
problem at hand, and ability to deliver, we can come up with ratios
similar to 1:2 to 1:5 with especially initially working much harder than
the procedural approach. 
My initial understanding of OO was something similar along these lines,
and it didn�t take me anywhere. This approach is not a major paradigm
shift and in this case all people saying that OO is an incremental
advance over procedure orientation are right if that�s all they saw so
far. 
<< End segment >>

At its simplest, data compression is an analogy that I wanted to use
because it resembles Today's OO systems development efforts. However,
there is always an overhead of data compression, it may not be feasible
for certain data, and results widely change from data to data as well as
the compression algoritm.

One of my initial failures while practicing OO was that I hadn�t
realized the most important difference of  OO to all other previous
approaches. I would like to ask this question here.

<< $1,000,000.- Question >>
What is the most important difference between the procedural paradigm
and the object oriented paradigm that makes OO a significantly different
one? 
<< End question >> 

I will answer to this question after I see peoples� responses by
referring to one of the forefathers of object orientation and one of the
great visionaries of our times.  First to answer correctly (IMO) to this
question will get a small surprise present if he or she e-mails me a
copy of the post. I am missing a lot of the postings, so there is no
guarantee that I�ll see the posted ones. If someone can actually pull
out who I am hinting about, I will have a bigger present for that
person. 

Meanwhile I would like to thank all the people sent e-mail to me. I�ll
do my best to reply them, however there are too many of them which will
take me some time to reply. I would like to thank to each and every one,
including flames, for each of them teach me something, or confront me
with questions I can come across somewhere else.

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: What is wrong with OO ?

[Tansel Ersavas]

Jon S Anthony wrote:
> 
> > Still I believe that the next generation will work predominantly with
> > pictures and will rarely revert to bulky chunks of text
> 
> Hmmmm, do you really think any attempt you try to provide for my first
> question will be any where near as light weight as "mountain"???????
> Take a look at the "byte-size" of even the simplest graphic in any
> representation you care to and compare it to a "corresponding textual
> description".

I remember similar discussions that took place when GUIs were first
introduced. However, it didn't change the fact that GUI dominated. When
CERN fist introduced the text based ancestor of Mosaic, it didn't really
motivate any users to participate until the hyper-media concept was
introduced. Rest is history. It is not the hyper-link concept that
started the web-mania. This was around before. It is the ability to
combine text, sound and images together to offer a whole. Same things
will happen, in fact already happening in the systems development area.
The first examples mostly suck, but they will be better, and will
eventually dominate.

One should also remember that text is a visual represenatation as well.
We have nice little icons that represent letters. So it is just one way
of pictorial representation. It is a fascinating evolution how we ended
up with text, and I enjoy reading about how iconic languages became
textual ones. This subject is very deep, and would start several
threads, so I'll keep quiet about it now.

I don't think that we can justify the graphical craze in measurable
terms such as of ease of use, or or ease of learning. Indeed, when the
icon based file interface first introduced in Lisa, there were a series
of tests with users about the ease of learning of this new approach. To
many people's surprise they didn't turn out to be faster to learn than
the other concepts when they were first introduced. Even error rates
came about the same. What was different, though, people's enjoyment of
the "little pictures" as they defined it. This enjoyment in turn
promoted wider use, and indirectly more efficient learning. Pictures are
sexier. They can immediately grab our attention. 

BTW I also sometimes watch with worry as GUIS dominate, because they
disadvantage one group of people, namely blind people. To the blind,
text is as meaningless as pictures unless it is converted to sound or
braille. However text can be converted to either of these mediums
easily, while GUIs can not be. The ideal solution is to keep the
development model independent of its views, and show it to people who
want to view it in text as text, pictures as pictures, or sound, and any
other views imaginable, and that lies in the core of some new systems we
are developing.

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: What is wrong with OO ?

[Michael Malak]

In article <32BB2C50.2B0B@rase.com>, Tansel Ersavas  <tansel@rase.com> wrote:
>
><< $1,000,000.- Question >>
>What is the most important difference between the procedural paradigm
>and the object oriented paradigm that makes OO a significantly different
>one? 
><< End question >> 

OO reduces complexity in a system by reducing the number of
dependencies.  A good OO system will have a number of loosely
coupled objects, with much of the detail encapsulated in the
objects themselves.

Moreover, OO systems are resiliant to change.  In OO, one
identifies the "objects", the "things" in the domain.  It
turns out that these boundaries change less frequently
than do their implementations.  Objects may (and are
almost always) expanded, but not "changed" as the system
grows.

In procedural systems, boundaries are less common (to be sure,
different "subsystems" are independent, but that's the big
exception) and less rigid.  Dependencies are combinatorically
more prevalent.  Worse, the dependencies are not necessarily
organized or recognized in any explicit way, so that a change
to one part of the system has unknown effects in other parts
of the system.

OO exploits (and relies upon) human being's ability to
abstract -- to be able to see a table and recognize its
"tableness" -- in order to "magically" reduce dependencies,
complexity, and brittleness (w.r.t. change).

-- 
Michael Malak         Magic forwarding e-mail address:
Washington, DC        malak@acm.org

Re: What is wrong with OO ?

[Willy]

> And miserable!  You have no *clue* what miserable is if you think
> programming is miserable.  I am happier programming than in any other
> part of my job, but *any* part of my job is infinitely better than
> when I was manufacturing bubblebath.  I don't have to do any of the
> following:
> 
> - work with detergent on my hands in an environment that's below freezing
> - risk falling into a vat of bubblebath with a spinning propeller mixing it
> - fight with 450-pound drums of mildly toxic chemicals
> - work 13-hour days of moving 25-pound boxes
> - clean up enormous bubblebath messes on the floor
> - get paid $5 an hour
> - work in an 85-dB ambient noise environment
> - never see the sun

Miserable?  Hey, give me the babes working the bubblebath shift. 
Which would you rather have, a hot babe from the soap shift for a
night of steamy sex in her Tennessee double-wide, or some ditzy
tofu eating C programming bitch?  The choice is yours.

Re: What is wrong with OO ?

[David Bradley]

tbushell@fox.nstn.ns.ca (Tom Bushell) wrote:

>I basicly agree with Tansel - programming will become much more visual
>in the medium term future.  Text will still be required, but mainly
>for commenting, not for code.

I think it will be more a combination of both.  Its easier to manage
relationships and interactions visually, but its easier to describe
the objects in text.  However, I don't think such a solid line should
be drawn there.  Sometimes it may be easier to describe a relationship
than to draw it.  I also know some people work better with one or the
other.

--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com

Re: What is wrong with OO ?

[David Bradley]

"Dann Corbit" <dcorbit@solutionsiq.com> wrote:

>Think of an architect, designing a building.  In the high level
>drawing, they do not have a picture of every fastener and joint.
>But somewhere, the detail will eventually be stored.

True, but even at the high level there are annotations on the drawing
that can not be caputured in images and are more than just comments.
Thus I'd love a system where I can interact visually but be able to
revert to a language when the need arose.  

>Back to the original subject, "What's wrong with OO?", there is
>nothing wrong with Object Oriented programming.  But it is not
>the ultimate tool for each and every business problem.  First,
>you need to have an object model that fits the OO paradigm you
>are using.  Not all physical business problems can best be expressed
>in this way (most of them can).  Then you need to have someone
>who knows OO techniques.  There's the old lame joke about someone
>who was having trouble with his chainsaw.  He took it in to the
>salesman to find out what the problem was.  When the salesman started
>it, he said, "What's that noise?"
>
>Know your tools.

Quite true.  I don't think anything is wrong OO.  It's only failed for
two reasons.  One is lack of knowledge, the other is lack of proper
design.  People tend to forget that OO only makes programming easier
for those who know how to use it.  A poorly design OO system can be
worse than a poorly design procedural system.  Lack of good design
results in a very brittle system.

Alas no one seems to look beyond the short term.  They don't want to
make the investment upfront.  "Just get it done".


--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com

Re: What is wrong with OO ?

[Jeffrey C. Dege]

On Mon, 23 Dec 1996 13:11:46 GMT, David Bradley <davidb@datalytics.com> wrote:
>tbushell@fox.nstn.ns.ca (Tom Bushell) wrote:
>
>>I basicly agree with Tansel - programming will become much more visual
>>in the medium term future.  Text will still be required, but mainly
>>for commenting, not for code.
>
>I think it will be more a combination of both.  Its easier to manage
>relationships and interactions visually, but its easier to describe
>the objects in text.  However, I don't think such a solid line should
>be drawn there.  Sometimes it may be easier to describe a relationship
>than to draw it.  I also know some people work better with one or the
>other.

Personnally, I will limit my use of visual programming tools until they
provide merge and diff tools.  I need to be able to tell what has
been changed between versions 2.3B and 2.3D and I need to be able to
merge those changes into the trunk in a semi-automated fashion.

Supporting old releases, or providing several versions of the current
current release customized for particular clients is not at all
unusual.  Combine that with a system comprising >2000 classes and
you have a system that _cannot_ be managed without automatic
differencing tools.

There are fairly good diff and merge tools available for text files,
and textual programming languages can take advantage of them.  I've 
seen some graphical tools store their output in a text format that
could be merged by textual tools with some success, but not many.
I've seen many graphical tools that provided no method for comparing
different versions of a file, and these are, IMO, suitable only for
one-off, throw-away systems.

-- 
Never worry about theory as long as the machinery does what it's
supposed to do.
		-- R. A. Heinlein

Re: What is wrong with OO ?

[Jon S Anthony]

In article <32BB2C13.A38@rase.com> Tansel Ersavas <tansel@rase.com> writes:

> Jon S Anthony wrote:
> > 
> > > Still I believe that the next generation will work predominantly with
> > > pictures and will rarely revert to bulky chunks of text
> > 
> > Hmmmm, do you really think any attempt you try to provide for my first
> > question will be any where near as light weight as "mountain"???????
> > Take a look at the "byte-size" of even the simplest graphic in any
> > representation you care to and compare it to a "corresponding textual
> > description".
> 
> I remember similar discussions that took place when GUIs were first
> introduced. However, it didn't change the fact that GUI dominated. When

True, but irrelevant.  Your point was that pictures were less "bulky"
than text.  That is simply untrue.


> CERN fist introduced the text based ancestor of Mosaic, it didn't really
> motivate any users to participate until the hyper-media concept was

Sure, everyone understands that flash sells.


> will happen, in fact already happening in the systems development area.
> The first examples mostly suck, but they will be better, and will
> eventually dominate.

They may, but they will be bulky and resource intensive.  It is
interesting to note that in general you can get most of the "useful"
information content of the Web with somethin like Lynx which is very
very light weight.  Netscape and other such browsers are very heavy
weight.  And they don't offer a lot of real value added.  At least not
yet.  Perhaps they will.


> One should also remember that text is a visual represenatation as well.
> We have nice little icons that represent letters. So it is just one way
> of pictorial representation. It is a fascinating evolution how we ended

Fine, using this argument it is easy to say that pictures are text
(especially when you consider pictograms and hieroglyphs).  So, now
you've managed to remove any content from the discussion.


> of tests with users about the ease of learning of this new approach. To
> many people's surprise they didn't turn out to be faster to learn than
> the other concepts when they were first introduced. Even error rates
> came about the same. What was different, though, people's enjoyment of
> the "little pictures" as they defined it. This enjoyment in turn

This is not particularly surprising.  The same thing can be said, at a
finer granularity, about embedded formating text processors and
WYSIWYG.


> promoted wider use, and indirectly more efficient learning. Pictures are
> sexier. They can immediately grab our attention. 

This is clearly true.  At least for the majority of people.  It is
also rather uninteresting as it is boringly obvious.  Just look at
what is more popular: TV or books.  Also, just look at what has more
content: Books or TV.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Jon S Anthony]

In article <32BB2C3D.68CB@rase.com> Tansel Ersavas <tansel@rase.com> writes:

> that system for our certain needs. Nobody is talking about representing
> the entire information in one diagram, or even representing entire
> systems with only diagrams. However, I will not debate the usefulness of
> diagrams.

Diagrams are cleary useful and sometimes basically essential.  The
same thing can be said about textual representation.


> It is trivial dealing with 10,000 lines of code, but if you have a
> million lines of code, you have no other way but summarize some of
> the information into some diagrams if you want to communicate them
> effectively. (Unless of course, you want to stuff them into 100-D
> matrixes).

It is not obvious how diagrams would communicate this _abstraction_
significantly more effectively than a corresponding reduction
utilizing text symbols.  The key isn't necessarily a diagram it is the
abstraction.  Whether communicated via a picture or textual symbols,
or for that matter a set of sounds or texture or what have you.
Mathematics has done this sort of thing for millenia.

At the end of the day, nothing that's been said here or in the many
other places I've read and examined on this subject, is in any way
convincing that diagrams, by their nature, somehow capture and/or
communicate concepts in a way that is somehow so intuitive that you
can ken the information merely by taking a quick look or something.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Nigel Tzeng]

In article <32B3F45C.5140@deep.net>, Tansel Ersavas  <tansel@deep.net> wrote:
>Robert C. Martin wrote:
>> 
>> In article <32AA207E.3199@deep.net>, tansel@deep.net wrote:
>> 
>> > There are three major reasons why OO projects fail. All of them are
>> > stated by the great wisdom of Jedi in "Star Wars".
>> >
>> > These are:
>> >     "Do or do not. There is no try"
>> >     Using my tools and techniques, I can prove you that I can produce
>> >     better and faster systems using OO (Please read my notes at the end
>> >     of this message). If I can do it, so you can.If you just try to do
>> >     it, you will fail. Be determined to do it.

Why does this remind me of the get rich on real estate seminars?  Well, gee
people fail using my strategy becuase they weren't committed enough.  They
didn't truly believe it would work so it failed....

[snip]
 
>First of all, my opinion is, developing systems with procedure oriented
>techniques is a dangerous, wasteful and unproductive process. So far OO

Any particular reason why?  Do you have metrics that show that procedure
oriented techniques are inherently dangerous or wasteful?  What do you
mean by dangerous anyway?

>couldn't show a quantum leap of difference, but it is not mature yet.
>When I train people, I look at their background. Usually the more
>experienced in the traditional techniques they are, the less they
>believe the necessity of learning a new technique. In my breakthrough

IMHO this is more likely the case of being around the block a couple
of times and seeing several "silver-bullet" approaches fail miserably
rather than some inherent dislike of doing something different.

We are an OO shop and there are many advantages to doing OO design but
is it the savior of all programming projects?  Nah.  Is it really THAT
much more efficient or successful than SASD?  Nah.

Why?  Becuase the root cause of a lot of project failure isn't with
the underlying technology (OO vs SASD) but due to the politics and
social dynamics of any project.

My opinion is that peopleware issues are more important than the
underlying methodology used in a project...and that you are far more
likely to see these "order of magnitude" productivity changes by
adhering to Peopleware than OO (not that Peopleware is a silver bullet
mind you :).

[procedural thinking vs OO deleted]

>Anybody wishing to see these techniques in action, I'm happy to
>demonstrate them. It is the only proof I can show to anyone that OO
>works, and works much better than anything they have seen so far. And
>without unlearning, it wouldn't have been possible. 

I think that most members of this newsgroup are open to new ideas and
success stories.  Feel free to share your experience.

[snip]

>I'll remind you of the placebo effect. IMO belief creates miracles. But
>it is also true that blind faith is dangerous.

Great...well I suppose that we can increase productivity by changing the 
light level every couple of months.

>Any time a new paradigm comes around there are pioneers. They make the
>bold decisions to shape the history. They are less than 1% of the
>participants. Pioneers are nothing but visioners and believers. They
>create their evidence, and history.

And never ever let one of these folks lead your project.  Yeah, they will
strike gold 1% of the time but do you really want to be on the other 99%
of the projects?

Now these folks can change the face of the market...but it's too bad
that in general some popularizer steals the market from the visionary.

Steve Jobs lives here...

>Then there come early adopters. People who don't need "empirical
>evidence". Who use their intuition to make sense of what the pioneers
>are pointing to.

These folks have a higher success rate but people who live on the cutting 
edge tend to bleed.  Will they really gain a significant market advantage?
Depends a little on luck...but if there's nothing to lose.

I'd say Netscape lives here...they scored big by early adoption of
internet technology and splitting off from NCSA.

>Then there are popularizers. People are quicker than the others, just
>like the people who watch the other traffic lights to see when they are
>going red so that they could be the first to respond to the green light.
>They require evidence, but can act very quickly. 

Probaby the best place to live...the visionaries and early adopters
has weeded out the "looked like a good idea on paper" strategies out
and there are valuable lessons to be mined from their successes and
failures.

Here be Microsoft...or maybe a little lower. Wherever they live they
seem to real good at stealing markets from visionaries and early
adopters :)

>Then there are followers, much like people passing at the green light.
>They do nothing but go with the crowd. There must be empirical evidence
>for them.

And most of us sit here.  After all, most of us aren't doing anything
to win Nobel prizes over or changing the face of the market.

[snip]

>In fact, I can't follow all of it, but during this discussion about
>what's wrong with OO I tried to observe any excitement, but couldn't see
>much of it around.

The thing is that the best programmers out there are constantly
learning, making improvements and adopting new technology as it
becomes useful.  But they don't tend to be zealots over any particular
tool or even set of tools...because one you buy into a particular
paradigm with heart and soul you're a lot less likely to change or to
see the problems with the paradigm.  

Besides...methodologies are only tools...important in that they help
us get the job done but they are not and should not be the focus of
our excitement (unless we are researchers).

There is an interesting comment I read in a home theater magazine
where an individual states that he never wanted to be one of those
people who said "Hey, you have to come over and see/hear my system!"
because the objective is to come over and see a movie or hear music.
The A/V equipment should be so good as to be unnoticable.

Likewise I'd rather say "Hey, come use my great new product" and not
"Hey, we designed this thing using OO isn't that great!"

>> Robert C. Martin    | Design Consulting   | Training courses offered:

>Tansel Ersavas

Nigel

Re: What is wrong with OO ?

[Ell]

Willy (clean@johnson.willy.com) wrote:
: > And miserable!  You have no *clue* what miserable is if you think
: > programming is miserable.  I am happier programming than in any other
: > part of my job, but *any* part of my job is infinitely better than
: > when I was manufacturing bubblebath.  I don't have to do any of the
: > following:
: > 
: > - work with detergent on my hands in an environment that's below freezing
: > - risk falling into a vat of bubblebath with a spinning propeller mixing it
: > - fight with 450-pound drums of mildly toxic chemicals
: > - work 13-hour days of moving 25-pound boxes
: > - clean up enormous bubblebath messes on the floor
: > - get paid $5 an hour
: > - work in an 85-dB ambient noise environment
: > - never see the sun
 
: Miserable?  Hey, give me the...

[Male chauvanist pig stuff deleted, which we don't need.]

Elliott

Re: What is wrong with OO ?

[Fraser Wilson]

clean@johnson.willy.com (Willy) writes:

>Miserable?  Hey, give me the babes working the bubblebath shift. 

[snip]

Your forgery had "netcom loser" written all over it even before
I checked the headers.

Go back to haunting alt.personals, honey.

(ObOO: A good tool, but not to be the entire focus of a design.  Which
is why Ada 95 works so well: you get the OO for when it's appropriate,
and an astonishingly rich and robust language to back it up.  Yum!)

Fraser xxx
--
  ____   Fraser Wilson          | email: fraser@cs.mu.oz.au     __o
  \ _/__ The more I learn of    | voice: +61 3 9344 9341      _-\<,_
   \X  / C++, the more I like   | fax:   +61 3 9348 1184     (_)/ (_)
     \/    --- Ada 95 ---       | www:   http://www.cs.mu.oz.au/~fraser/

Re: What is wrong with OO ?

[Weiqi Gao]

Nick Leaton <nickle@calfp.co.uk> wrote in article
<32B12311.5D8E@calfp.co.uk>...
> : I once visited a large municipal government computing shop with 130
> : people
> : working there.  I was told by the boss that as far as he's concerned,
> : his
> : "systems analysts" are to do all the thinking and his programmers, he
> : called them "coders", are just supposed to translate those lofty
> : thoughts
> : into code.  He then thought that the reason the average programmer
> : only
> : stayed 18 months (remember that's the average, I wonder what the good
> : ones
> : were doing!) was because that was the nature of the business and
> : programmers
> : were defective people anyway!
> 
> And the analyst spend more time telling the programmers what to do than
> it takes to produce the code, and since the actual coding is a small
> part of the overall time it is not suprising they have a high staff
> turnover.

Us coders usually gather together and joke about the mistakes the analysts
put into the design, and then turn around and code it exactly the wrong
way!  Because we are not paid enough to correct the stupid mistakes they
made.

-- 
Weiqi Gao
weiqigao@crl.com

Re: What is wrong with OO ?

[Matthew S. Whiting]

Weiqi Gao wrote:
> 
> Us coders usually gather together and joke about the mistakes the analysts
> put into the design, and then turn around and code it exactly the wrong
> way!  Because we are not paid enough to correct the stupid mistakes they
> made.
> 

Glad you said "coder" and not software engineer!  Maybe if you DID use
your skills rather than intentionally not use them, you'd be better
paid.

Matt

Re: What is wrong with OO ?

[Mike Rubenstein]

"Weiqi Gao" <weiqigao@crl.com> wrote:

> Nick Leaton <nickle@calfp.co.uk> wrote in article
> <32B12311.5D8E@calfp.co.uk>...
> > : I once visited a large municipal government computing shop with 130
> > : people
> > : working there.  I was told by the boss that as far as he's concerned,
> > : his
> > : "systems analysts" are to do all the thinking and his programmers, he
> > : called them "coders", are just supposed to translate those lofty
> > : thoughts
> > : into code.  He then thought that the reason the average programmer
> > : only
> > : stayed 18 months (remember that's the average, I wonder what the good
> > : ones
> > : were doing!) was because that was the nature of the business and
> > : programmers
> > : were defective people anyway!
> > 
> > And the analyst spend more time telling the programmers what to do than
> > it takes to produce the code, and since the actual coding is a small
> > part of the overall time it is not suprising they have a high staff
> > turnover.
> 
> Us coders usually gather together and joke about the mistakes the analysts
> put into the design, and then turn around and code it exactly the wrong
> way!  Because we are not paid enough to correct the stupid mistakes they
> made.

Which is probably one of the best ways to ensure that you will never
be paid enough to correct the stupid mistakes.

Michael M Rubenstein

Re: What is wrong with OO ?

[drush]

Chris Brand <cbrand@ccgate.hac.com> *wrote*:
~David Bradley wrote:
~- 
~- mbk@caffeine.engr.utk.edu (Matt Kennel) wrote:
~- 
~- >Is it really?  Can a painting communicate subtle ideas as clearly as
~- >literature?
~- 
~- The thing that comes to my mind, is if visual is so much better then
~- why are we still "reading" books.
~- 

~Kids aren't. They're watching TV or movies.

Speak for youself. Mine are voracious readers. As are their parents :)

	david rush
	mailto:kumo@intercenter.net

	I bill $100/minute for reading commercial email.

ObTextVsPicturesOpinion:
	Text *is* more accurate. Nobody uses hieroglyphics anymore. (And yes
	I *also* read Kanji).

Re: What is wrong with OO ?

[drush]

*Text* from the keyboard of Tansel Ersavas:
>I remember similar discussions that took place when GUIs were first
>introduced. However, it didn't change the fact that GUI dominated. When
>CERN fist introduced the text based ancestor of Mosaic, it didn't really
>motivate any users to participate until the hyper-media concept was
>introduced. 

BZZZZ - There were also a lot less people connected back then, too. I was
there. Hypertext systems were gaining in popularity everywhere, from
Apple's Hypercard to on-line help systems, to project documentation
(think Web and info).

  I run about 90% of the time in "no-images mode" using netscrape,
and I only use netscrape because the folx desigining web pages think
that layout is more important than content. NS seems to be able to
keep pages intelligible even without the pics.

>One should also remember that text is a visual represenatation as well.

Pedant. Please pick your terms then. Verbal vs pictorial? Logical vs
Gestalt? Procedural vs OO?

We all know the semantic tension about which we are speaking. The
representation is *not* the issue.

>We have nice little icons that represent letters This subject is very
>deep, and would start several threads, so I'll keep quiet about it now.

Thank you.

>I don't think that we can justify the graphical craze in measurable
>terms such as of ease of use, or or ease of learning.

To quote Robert Heinlein, "If you can't measure it, it's not science."

This does not mean, however, that it is worthless.

I was going to comment on his final paragraph (about text, pictures,
blind people, and software architecture), but untangling the good from
the silly was too tiresome.

bleah -
	david rush
	mailto:kumo@intercenter.net

	Go away.

Re: What is wrong with OO ?

[Bob Jarvis]

Weiqi Gao <weiqigao@crl.com> wrote in article <01bbf2b8$d2873080$0f0171a5@weiqigao>...
> Us coders usually gather together and joke about the mistakes the analysts
> put into the design, and then turn around and code it exactly the wrong
> way!  Because we are not paid enough to correct the stupid mistakes they
> made.

I encourage you maintain this attitude, and fervently hope you'll soon be working for
any firm I have to compete with.
-- 
Bob Jarvis

Re: What is wrong with OO ?

[Arthur Gold]

When all is said and done:
   Good programmers write/contibute to good programs.

As for the pictures vs. text debate:
   Text is great for linear/sequential ideas.
   Pictures are better at expressing relationships.
   Both are valuable _and_ necessary.

So what's wrong with OO?
   Well put it this way: 
      Issac Stern can make a student violin sound wonderful.
      At best, I would make a Stradivarius sound horrid.

Just my nickel...(inflation)
-- 
Onward,
           **************   
           * Artie Gold *
*************************************                
* agold@bga.com * ArtieGold@aol.com *   WWW Home Page:
*     74562.1167@compuserve.com     *   (coming soon!!!!!!!)
*************************************

Re: What is wrong with OO ?

[Tansel Ersavas]

Nigel Tzeng wrote:

...

> >First of all, my opinion is, developing systems with procedure oriented
> >techniques is a dangerous, wasteful and unproductive process. So far OO
> 
> Any particular reason why?  Do you have metrics that show that procedure
> oriented techniques are inherently dangerous or wasteful?  What do you
> mean by dangerous anyway?

I have stated this in a few of my previous postings. However, I will
post about this subject in detail after the new year. You might also
want to look at my reply to David Rush (drush@zakalwe.raleigh.ibm.com).

...
 
> We are an OO shop and there are many advantages to doing OO design but
> is it the savior of all programming projects?  Nah.  Is it really THAT
> much more efficient or successful than SASD?  Nah.

The problem is how we currently apply the OO approach. It CAN be THAT
much more efficient than SA SD. Again, you might want to browse my reply
to David Rush. 
 
> Why?  Becuase the root cause of a lot of project failure isn't with
> the underlying technology (OO vs SASD) but due to the politics and
> social dynamics of any project.
> 
> My opinion is that peopleware issues are more important than the
> underlying methodology used in a project...and that you are far more
> likely to see these "order of magnitude" productivity changes by
> adhering to Peopleware than OO (not that Peopleware is a silver bullet
> mind you :).

That is very true, indeed I have stated it in many of my postings. I
stated that the only silver bullet is to have the right people, right
type of organization, right type of approach and right types of tools
all together. One missing, efficiency reduces dramatically
 
...
> 
> >Anybody wishing to see these techniques in action, I'm happy to
> >demonstrate them. It is the only proof I can show to anyone that OO
> >works, and works much better than anything they have seen so far. And
> >without unlearning, it wouldn't have been possible.
> 
> I think that most members of this newsgroup are open to new ideas and
> success stories.  Feel free to share your experience.

I'll sure do that. So far, I only had to reply to individual postings,
which can not give clear view of my ideas. I plan to prepare a posting
about this discussion and send it after the new year, time permitting.  

... 
> Great...well I suppose that we can increase productivity by changing the
> light level every couple of months.

Which can be done, of course. And if you don't believe me, just visit a
hen battery to see how they are, or can be tricked to get twice the eggs
by changing the light level twice a day. (Not recommending it for
anybody though)
 
> >Any time a new paradigm comes around there are pioneers. They make the
> >bold decisions to shape the history. They are less than 1% of the
> >participants. Pioneers are nothing but visioners and believers. They
> >create their evidence, and history.
> 
> And never ever let one of these folks lead your project.  Yeah, they will
> strike gold 1% of the time but do you really want to be on the other 99%
> of the projects?
> 
> Now these folks can change the face of the market...but it's too bad
> that in general some popularizer steals the market from the visionary.
> 
> Steve Jobs lives here...

I agree with your sentiments.
 
> >Then there come early adopters. People who don't need "empirical
> >evidence". Who use their intuition to make sense of what the pioneers
> >are pointing to.
> 
> These folks have a higher success rate but people who live on the cutting
> edge tend to bleed.  Will they really gain a significant market advantage?
> Depends a little on luck...but if there's nothing to lose.
> 
> I'd say Netscape lives here...they scored big by early adoption of
> internet technology and splitting off from NCSA.

That's true as well
 
> >Then there are popularizers. People are quicker than the others, just
> >like the people who watch the other traffic lights to see when they are
> >going red so that they could be the first to respond to the green light.
> >They require evidence, but can act very quickly.
> 
> Probaby the best place to live...the visionaries and early adopters
> has weeded out the "looked like a good idea on paper" strategies out
> and there are valuable lessons to be mined from their successes and
> failures.

That's also very agreeable, which is just about where we are coming in
OO. 

...
 
> >Then there are followers, much like people passing at the green light.
> >They do nothing but go with the crowd. There must be empirical evidence
> >for them.
> 
> And most of us sit here.  After all, most of us aren't doing anything
> to win Nobel prizes over or changing the face of the market.
 
And there's nothing wrong with it. In many issues, I choose to be a
follower, even conservative in some. 

...

> The thing is that the best programmers out there are constantly
> learning, making improvements and adopting new technology as it
> becomes useful.  But they don't tend to be zealots over any particular
> tool or even set of tools...because one you buy into a particular
> paradigm with heart and soul you're a lot less likely to change or to
> see the problems with the paradigm.

That's true. However, that's naturally done by many in the form of
unconsciously clinging to the existing paradigm, probably till its
collapse. However we deny it, paradigms shape our thinking, which is at
the center of this discussion. Many people think that they can look at
procedure orientation from a neutral point of view, but they can't.
Here, I can't help but quote from Ed Yourdon: 

<< Please only quote this as a whole >>
" 'From Emerging Software Technologies by Ed Yourdon:'
. Software methodologies are often supported and marketed by a 
  specific vendor, or guru
. The guru becomes dependent on the success of his/her methodology in 
  order to pay rent and maintain credibility/status/ego
. The fiery, young revolutionary often becomes conservative old fart, 
  defending his/her paradigm as more and more exceptions and problems 
  found
. Methodology collapses under its own weight when a critical mass of 
  people believes that it no longer serves their needs - but the change 
  is often delayed for years and decades  because of inertia, 
  politics, etc. "
<< End quote >>

 
> Besides...methodologies are only tools...important in that they help
> us get the job done but they are not and should not be the focus of
> our excitement (unless we are researchers).

That's true, but there is also nothing wrong about being excited about
something that you can see it can clearly improve your productivity
dramatically.
 
> There is an interesting comment I read in a home theater magazine
> where an individual states that he never wanted to be one of those
> people who said "Hey, you have to come over and see/hear my system!"
> because the objective is to come over and see a movie or hear music.
> The A/V equipment should be so good as to be unnoticable.

This is probably more relevant to computers themselves, being ugly bulks
of heat producing masses with primitive user interfaces that still tend
to alienate a reasonable chunk of people from what they can offer. I
agree with what you say about this subject.  

> Likewise I'd rather say "Hey, come use my great new product" and not
> "Hey, we designed this thing using OO isn't that great!"

That's true. In fact what people will call OO will be largely defined by
themselves. It is not very right to apply a rigid classification and
divide things in two, and unconditionlly defend one. However, it is also
important the differences of different apporaches and their potential
benefits to make people more aware of what is possible with other
approaches.
 
> Nigel

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: What is wrong with OO ?

[Bill Gooch]

Tansel Ersavas wrote:
> ...
> Here, I can't help but quote from Ed Yourdon:
> 
> << Please only quote this as a whole >>
> " 'From Emerging Software Technologies by Ed Yourdon:'
> . Software methodologies are often supported and marketed by a
>   specific vendor, or guru
> . The guru becomes dependent on the success of his/her methodology in
>   order to pay rent and maintain credibility/status/ego
> . The fiery, young revolutionary often becomes conservative old fart,
>   defending his/her paradigm as more and more exceptions and problems
>   found
> . Methodology collapses under its own weight when a critical mass of
>   people believes that it no longer serves their needs - but the change
>   is often delayed for years and decades  because of inertia,
>   politics, etc. "
> << End quote >>

I wonder where Ed Yourdon fits into his own model...
I think that a true visionary (Alan Kay, Nicholas
Negroponte and Buckminster Fuller are a few who come 
to mind) never becomes a "conservative old fart," 
because s/he is never fully satisfied.  New ideas and 
refinements of old ideas are always worth exploring.

A couple of years ago, I heard Alan Kay talk about 
"inventing the future."  He said that most people
using Smalltalk have apparently "missed the point,"
because they don't bother replacing the class hier-
archy with one of their own devising.   

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: What is wrong with OO ?

[Ell]

Bob Jarvis (jarvisb@timken.com) wrote:
: Weiqi Gao wrote:
: > Us coders usually gather together and joke about the mistakes the analysts
: > put into the design, and then turn around and code it exactly the wrong
: > way!  Because we are not paid enough to correct the stupid mistakes they
: > made.
 
: I encourage you maintain this attitude, and fervently hope you'll soon be 
: working for
: any firm I have to compete with.

:-}

Not to mention the fact that analysts shouldn't be doing coding
architectural and local design.  They should only formulate a _logical_
application outline which should form the basis of coding architecture and
local design.

That is, coding architecture and local design should follow the domain
abstractions and semantics used by, and the logical solutions given by,
the analysts.  While coding architecture, and local design should be done
by, you guessed it, the coders.

Elliott

Re: What is wrong with OO ?

[clovis]

In <32B81DA7.6D08@deep.net>, Tansel Ersavas <tansel@deep.net>, in a fit of
extreme hubris, wrote:

>Robert Dewar wrote:
>> 
>> Tansel says
>> 
>> "First of all, my opinion is, developing systems with procedure oriented
>> techniques is a dangerous, wasteful and unproductive process."
>> 
>> It is this kind of unsupporable hyperbole that gives OO a bad name!
>
>Unsupportable? Hyperbole? Are we mentioning about the software gap, or
>failed projects, or wasted money?
>Why don't you look at statistics about these?

The problem is bad coders.  Those of us who have been around for 20 years have
long ago noticed that 10% of the world's programmers could do 100% of the work
and not have it spontaneously collapse, by doing it right the first time.

This has nothing to do with paradigm. It has everything to do with a quality attitude
and the ability to conceptualize.

What OO will do is help wash some of the dross out of the coding pool.

But I've done enough Smalltalk in the past year to know that I can write just as
sloppily in Smalltalk, and make even bigger errors, harder to correct, as I code
my way along, without a previously completed design, as I can with anything.

If anything, Assembly Language is easier to fix, precisely because the procedures
are more amenable to "redesign" and "reuse" than a single hirearchy.

>Turning a blind eye on Today's problems will not get us anywhere. First
>of all, we should admit that we have a problem, then find a solution to
>it. We ALL contribute to lost billions by ignoring what's happening
>around us. 

What problems? The lack of good software is due to the lack of good education,
high levels of intelligence distributed all around in the people doing the work, and
so on.  People do programming.  OO CAN be easier, in something like Smalltalk,
because there is so much framework for grunt stuff like the GUI.

So I greatly differ with your take on things here.

>> Why is it that when anyone comes along with new techniques that represent
>> a useful incremental advance in our knowledge in this area (e.g.
>> functional programming, proof of correctness, your-favorite-fad-here)
>> they feel compelled to hype them like this with the approach
>
>OO is not an incremental advance. It has started and continued that way,
>because SIMULA was an extension to Algol, and some of the most dominant
>languages are extensions of procedure oriented languages. This does more
>harm than good to OO. Many professionals I have talked to told me that
>until they made a switch ( or some of them call it a "click") they
>weren't able to benefit from OO a lot. It is more difficult to have that
>"click" if we have to work in an environment and a language which is
>basically an OO extension to a procedural background. 
>It is true that every newcomer announces that it is a significant
>advancement over procedure orientation. This is because people are
>worried about the current paradigm, and they in search for a better one. 

Smalltalk and other OO paradigms are an unmitigated disaster at certain kinds
of problems.  Ask me about Modified Midpoint integration or, say, adaptive Runge-
Kutta under Smalltalk.  We give up as much as two orders of magnitude in
computational efficiency.  The more a tool does for you, the more it also does
to you.

What is being complained about here is that you treat OO as though a pure OO
language "gives" all this good stuff without a price.  And, in reality, the price is
quite high.

>> The trouble with such hype is that inevitably it does not deliver, and then
>> there is a danger of throwing out the baby with the bathwater and
>> discarding what is useful along with the hype.
>
>OO as is now, is a struggling, and not much appreciated figure around.
>It has its troubles, but they are slowly being ironed out. Yes, there
>may be a short term backlash against OO, it may even go back a couple of
>years. This is not important. It will come back, and will eventually
>dominate.  

I don't find anything "struggling" about using VisualWorks or IBM's VisualAge on
Windows, OS/2 or OSF/Motif platforms -- they are basically just extentions of
GUI paradigms built on top of Smalltalk/80 to begin with, so they are quite
natural and straightforward to use -- ONCE ONE HAS CRACKED INTO THE HIREARCHY.

The chief complaint I have about OO is that one has to learn a hirearchy, and one
which is in the general case sloppily and amateurishly documented, instead of the
better understood and generally much better documented procedural library.

This inferior documentation is, in my view, the reason for OO's lack of popular
success.  It is, much as you are displaying here, more of a religion for its 
adherents than it is regarded as what it should be -- a convenience tool.

There is nothing OO can do that pure object code can't do.

All we're doing is adding the hirearchy to raise the level of abstraction, so one
doesn't have to spend as much time fussing with daily details.

>> The fact of the matter is that there is NO giant shift of paradigm involved
>> here, despite what anyone says. Just look at the OO programs that people
>> produce. They are not radically different from conventional procedural
>> programs, and one would not expect them to be.
>
>Unfortunately, many OO programs that people produce are produced by
>people who are learning. They will be better and better, the gap will be
>larger and larger, and differences will be more and more obvious.

Duh! This is arrogant nonsense, sir. OO cannot and will not make a case for itself
until it can demonstrate to the average working programmer something in the way
of return for the struggle to learn the hirearchy.

>People have short memories. A very similar sort of discussion with
>similar tones was done when first high level languages were introduced.
>Proponents of machine code and assembly languages said, this new
>paradigm was nothing new, just a bigger, bulkier way of doing the same
>thing with speed penalties, it was not practical, people would never
>program with them in masses, etc, etc. Now we see everything has settled
>down, there are still people write code in assembly and nothing else,
>however they are the minority.

Yes, Assembler is the minority.  And as a result Microsoft Word wants 120 megs on
a disk, where WordStar lived comfortably in 64k, code and data both.  Word does
very little more.

Seems we were told the truth to begin with, eh?

Word barely runs in 8 megs of RAM.

You started out talking about waste.  Why 8 megs instead of 64k?

We have some differences of opinion here.

Regards,

Frank

Re: What is wrong with OO ?

[clovis]

In <32B9607F.470B@rase.com>, Tansel Ersavas <tansel@rase.com> writes:
>We are glad to see our ideas are shared by professionals. I personally
>believe in visual programming, even though I am still a command-line
>person from time to time, especially in Unix. But with the right tool,
>even if we don't spend the majority of our time in the tool, we can
>achieve a lot, as I observed it in the case with Snowball. I also find
>it very useful as a documentation tool. In many projects, even though
>documentation is kept in high $$ CASE tools, it is practically
>impossible to reverse engineer the entire system and regenerate the
>document every time documentation is required. Snowball generates this
>documentation every time directly from the source, because Smalltalk is
>used as a specification and a repository for all the documentation
>information. So it is very useful even for people who won't do any
>visual programming, but want to have access to the visual views of their
>system at any time on demand, such as presentations. 

Sounds interesting.  I'll be interested in seeing it when it arrives.

VisualAge from IBM is good, but in certain respects, especially as based on ENVY
Smalltalk, it is very limiting.

I'd personally prefer something more towards the VisualWorks model.  This is a 
VERY visible system, even though I'm current tied to IBM's stuff in my current
project.

>Most visual tools limit us do things their own way. They look nice in
>demos, but when we start using them in real life, we feel limited. That
>is one of the issue we wanted to address clearly in Snowball. We wanted
>Snowball to be a non-intrusive tool.  When it is invoked, Snowball will
>understand your work without forcing you to any special format, or
>restrictions. It is available within a matter of seconds, and after you
>have made your changes, or even while you are doing changes, you can
>return to the Smalltalk environment and do what you want there.

I hope this is true!  If so, you are pushing things a great step foward.

Re: What is wrong with OO ?

[Jacqueline U. Robertson]

In article <59vr2s$55r@masters0.InterNex.Net>,  <clovis@wartech.com> wrote:
>In <32B81DA7.6D08@deep.net>, Tansel Ersavas <tansel@deep.net>, in a fit of
>Yes, Assembler is the minority.  And as a result Microsoft Word wants 120 megs on
>a disk, where WordStar lived comfortably in 64k, code and data both.  Word does
>very little more.
>
>Seems we were told the truth to begin with, eh?
>
>Word barely runs in 8 megs of RAM.
>
>You started out talking about waste.  Why 8 megs instead of 64k?
>
>We have some differences of opinion here.
>
Well, I was with you to some extent until you got here.  Code bloat is a 
simple trade-off for increased maintainability and extensibility.  Quite
simply, it's easier to maintain and extend a decently written application
in high level code than it is to maintain and extend a decently written
application in assembler.  Why ?  Because the high level language applied is
easier to read, particularly for follow on developers who were not involved
in the original work.  The trade-off is that the assembly level application was more compact (both in disk space and in memory usage) - but harder to extend
and modify.  There's a reason that assembly level development is limited
to small areas (such as in the limited resource milieu of deep space probes) -
the trade off in favor of high level languages has generally been worth it,
as increased disk space and increased amounts of RAM are economically cheaper
than the 'more efficient' assembler writing. 

I'd guess that over time (and in this case I'm guessing a fairly long 
interval), machine generated applications will end up being cheaper than hand
written ones for much the same reason.  



James A. Robertson
email: jamesr@parcplace.com
phone: 410 952-0471

<note that I am posting through my wife's account.  I don't claim to speak for
her>

>Regards,
>
>Frank

Re: What is wrong with OO ?

[Tore Lund]

clovis@wartech.com wrote:
> 
> (snip)
>
> Yes, Assembler is the minority.  And as a result Microsoft Word wants
> 120 megs on a disk, where WordStar lived comfortably in 64k, code and 
> data both.  Word does very little more.
> 
> Seems we were told the truth to begin with, eh?
> 
> Word barely runs in 8 megs of RAM.
> 
> You started out talking about waste.  Why 8 megs instead of 64k?

Finally a voice of reason - also in the parts snipped out here. The main
problem with OO and functional programming and all the other bright
"paradigms" is their sectarian tendencies. They suffer from an utter
inability to face their own shortcomings and cooperate with other modes
of programming.

As for the quote above - 8 megs vs. 64k - one must suspect that it is a
conscious strategy to squeeze more money out of end users. (Who just
*love* this sort of squeeze, judging from their reactions.) Or, it is
due to the incompetence of Microsoft and the general megalomania of
these times. In any case, OO as such is not to blame for it.
-- 
Tore Lund <tl001@sn.no>

Re: What is wrong with OO ?

[Tore Lund]

James Robertson wrote:
> 
> In article <59vr2s$55r@masters0.InterNex.Net>,  <clovis@wartech.com> wrote:
> > (snip)
> >You started out talking about waste.  Why 8 megs instead of 64k?
> 
> Well, I was with you to some extent until you got here.  Code bloat is 
> a simple trade-off for increased maintainability and extensibility.  
> Quite simply, it's easier to maintain and extend a decently written 
> application in high level code than it is to maintain and extend a 
> decently written application in assembler.  Why ? 

Yes, why? The most important reason is that most programmers don't know
assembler or bother to learn it well enough to write decent code in it.

You don't agree, of course, but the point here is is that the 64k
program written in assembler will still be < 100k when written in C.
There is no need for "code bloat" on the scale of 8 megs for
maintainability purposes.
-- 
Tore Lund <tl001@sn.no>

Re: What is wrong with OO ?

[clovis]

In <5a0niaINNlda@topdog.cs.umbc.edu>, jur@cs.umbc.edu (Jacqueline U. Robertson) writes:

Big snip, to save bandwidth

>Well, I was with you to some extent until you got here.  Code bloat is a 
>simple trade-off for increased maintainability and extensibility.  Quite
>simply, it's easier to maintain and extend a decently written application
>in high level code than it is to maintain and extend a decently written
>application in assembler. 

What you are saying is a damnable lie, but let's hear your reason for thinking
something as inaccurate as this.

> Why ?  Because the high level language applied is
>easier to read, particularly for follow on developers who were not involved
>in the original work.  

Would someone PLEASE and QUICKLY hang those who insist that code is
"self-documenting?"  Bad algorithms can be written in anything, and so can "cute"
an impenetrable code -- AND hirearchies.

So you have entirely the wrong answer here.  Bad hirearchies are even MORE
impenetrable than spaghetti code.

>The trade-off is that the assembly level application was more compact (both in disk space and in memory usage) - but harder to extend
>and modify.  There's a reason that assembly level development is limited
>to small areas (such as in the limited resource milieu of deep space probes) -
>the trade off in favor of high level languages has generally been worth it,
>as increased disk space and increased amounts of RAM are economically cheaper
>than the 'more efficient' assembler writing. 

This is also wrong. The reason that "paradigms" proliferate is obvious; people, and
managers in particular, are trying to get something for nothing.  Compared to
procedural languages, it takes 3 lines of assembler to equal one line of, say,
PASCAL stuff.  And it generally takes 5 lines of PASCAL to equal a line of Smalltalk
in a properly constructed hirearchy.  Any operation one needs to do should not
be a series of lines, but a single method, and a single message sent to the instance.
There are exceptions, but with the compactness come other problems.

>I'd guess that over time (and in this case I'm guessing a fairly long 
>interval), machine generated applications will end up being cheaper than hand
>written ones for much the same reason.  

Assuming that we can afford the machines that generate these applications, and
the amount of RAM required to run them.

Microsoft WORD is not as reliable, in my experience, as WordStar.  And it's not a
fraction as friendly.  Purportedly it does more, but I think that's only purportedly.

The more code paths and code there is, the more there is to go wrong.  This is the
same, simple principle as Consumer Reports has been telling people about for
years -- the more buttons, the sooner it will break down, and the more often it
will require repair after it breaks.  If you're just blending Mai Tais, no big deal.
If on the other hand you lose a file you've been working on all day, not so good.

>James A. Robertson
>email: jamesr@parcplace.com
>phone: 410 952-0471
>
><note that I am posting through my wife's account.  I don't claim to speak for
>her>

The problem remains one of having better programmers rather than better
languages.  I've done superb work in assembler, and all other paradigms, and I've
also hacked out really ugly stuff in Smalltalk.

If you design thoroughly, and document thoroughly, it turns out pretty well, if one
understands the problem one is trying to solve at all.  If you don't, it's a mess, and
the particular language, paradigm etc is  pointless.

OO is NOT a panacea.

It is more useful than not ONLY if it is used properly.  And that remains a function
of a good computer scientist, properly pursuing the trade, eh?

Think about it and get back to me.

Regards,

Frank

Re: What is wrong with OO ?

[clovis]

In <32C3E34F.5DC5@sn.no>, Tore Lund <tl001@sn.no> writes:

>Finally a voice of reason - also in the parts snipped out here. The main
>problem with OO and functional programming and all the other bright
>"paradigms" is their sectarian tendencies. They suffer from an utter
>inability to face their own shortcomings and cooperate with other modes
>of programming.

Why, Thanks, Tore!  I've been around the block a few times, and it sounds as
though you have been as well.  Differential equations, solved in Smalltalk, are
no bargain.  Neither are they solved best in C (although Smalltalk seems to lack a
coherent assembly language interface for genuine engineering-based problems;
I find this to be a major shortcoming, almost as though the Smalltalk folks who
work on these systems have not paid their dues).

>As for the quote above - 8 megs vs. 64k - one must suspect that it is a
>conscious strategy to squeeze more money out of end users. (Who just
>*love* this sort of squeeze, judging from their reactions.) Or, it is
>due to the incompetence of Microsoft and the general megalomania of
>these times. In any case, OO as such is not to blame for it.

True.  My point in all of this is that it comes down to a responsible and disciplined
PROGRAMMER, a software professional.  After that, the paradigm hardly matters;
it is chosen to fit the problem at hand.  Smalltalk and C++ are ridiculous for
diagnostics, just as Assembly Language makes no sense coding for OSF/Motif's
front end.

We make hammers in different sizes, and screws and screwdrivers.  I believe the
same is true of languages; they are tools, not ends in themselves.  And the good
workmanship is done by those who know which tool to use for what, and don't
try to drive screws with a hammer, or nails with the butts of screwdrivers.

I would think long and hard before I would forsake Smalltalk for GUI programming.
But there may well come a time when the task is sufficiently unusual that it
makes more sense than not.  

The primary loyalty has to be to good work, and nothing else at all.

Regards,

Frank

Re: What is wrong with OO ?

[Tansel Ersavas]

> *Text* from the keyboard of Tansel Ersavas:

Incidentally, sire, I don't think that message was from my keyboard. As
I am working on integrating voice recognition into my software suite, I
try to use a beta of IBM's VoiceType as much as possible, including
recording at least parts of these messages such as this one(I can't
exactly remember about that message, but there is a big change it
isn't).

>>I remember similar discussions that took place when GUIs were first
>>introduced. However, it didn't change the fact that GUI dominated. When
>>CERN fist introduced the text based ancestor of Mosaic, it didn't really
>>motivate any users to participate until the hyper-media concept was
>>introduced. 
>
>BZZZZ - 

Having fun, are we?

>There were also a lot less people connected back then, too. I was
>there. Hypertext systems were gaining in popularity everywhere, from
>Apple's Hypercard to on-line help systems, to project documentation
>(think Web and info).

Nice to know who were there, and what they were doing. It is true that
hypertext was gaining popularity. But tell me since when text based
hypertext browsers were available, and how many people were using them.
Also tell me when Mosaic was introduced and how it affected the number
of people and the web traffic, and tell me one difference between these
browsers.

>  I run about 90% of the time in "no-images mode" using netscrape,
>and I only use netscrape because the folx desigining web pages think
>that layout is more important than content. NS seems to be able to
>keep pages intelligible even without the pics.

In that case I recommend Lynx. It is very good and I use it from time to
time when I access the net over a slow modem. However, as I do not have
a personal dislike for pictures, I only seldom disable pics when I am on
the road, in the office with a T1 line they are blinking fast anyway.

>>One should also remember that text is a visual representation as well.
>
>Pedant. Please pick your terms then. Verbal vs pictorial? Logical vs
>Gestalt? Procedural vs OO?

I am not talking about pictures VS text. I have stated that IMO they are
complimentary. It would be worthwhile to read the entire series of posts
so that you could understand my stand there. I never defended a total
pictorial approach, but a pictorial layer, more an alternative view of
the system that can show you any canonical form of the system in
question, easily switchable between text and pics. You could type text
till you drop and I wouldn't mind as long as I can view what you did in
text and in pics.  When I say pictures will dominate, I do not say that
they will replace text. I am not trying to take away your right to use
text. I just want to introduce my right to use pics as well as text. You
may want to filter out the pictures but I'll keep text, but access,
layer, and enrich it with pictures, and if I want to avoid text as much
as possible, I'll be able to do it.

...

>>so I'll keep quiet about it now.
>
>Thank you.

On second thought, lets talk about it a bit. What do you think text is?
Would you like to look at these following articles and come back and
discuss the subject?

DeRose, S. J., Durand, D. G., Mylonas, E., and Renear A. H. (1990),
'What is Text, Really?', Journal of Computing in Higher Education, 1.2:
3-26.

DeRose, S. J., Durand, D. G., Mylonas, E., and Renear A. H. (1995),
'Refining our Notion of What Text Really Is: The Problem of Overlapping
Hierarchies' in Research in Humanities Computing, Oxford University
Press, edited by Nancy Ide and Susan Hockey

>>I don't think that we can justify the graphical craze in measurable
>>terms such as of ease of use, or or ease of learning.
>
>To quote Robert Heinlein, "If you can't measure it, it's not science."
>
>This does not mean, however, that it is worthless.

Here, here. Still, diagrams can be measured as well as text if the
underlying concept is measurable. I also think Heinlein's quote is
limiting. "Precision" is a term we have to forego some of it when we
deal with complex systems. Some of the measurements are irrelevant, as
the precision of some of them are as well. Modeling sending a rocket to
the Moon is a relatively simple problem that requires a lot of precision
if you compare to modeling driving a car to airport, that requires a
very high number of measurements many of them not needing a great degree
of precision. This may be the reason science in it current cycle can not
have perfect formulas for driving cars. Art is not measurable, but I
would love to hear you call it "worthless". IMO systems development is
an art as much as, if not more than, science.

>I was going to comment on his final paragraph (about text, pictures,
>blind people, and software architecture), but untangling the good from
>the silly was too tiresome.

I thought you were doing a great job so far

>bleah -

>        Go away.

Not a chance, David. However, I recommend filtering out my postings if
they upset you.

-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: What is wrong with OO ?

[Tansel Ersavas]

> > >The problem is bad coders.  Those of us who have been around for 20
> > >years have
> > >long ago noticed that 10% of the world's programmers could do 100% of
> > >the work
> > >and not have it spontaneously collapse, by doing it right the first
> > >time.

I have similar observations as well. However, I would think that would
be only one of the problems, and the approach we have in teaching
systems development has a great impact on these people.

> > >This has nothing to do with paradigm. It has everything to do with a
> > >quality attitude
> > >and the ability to conceptualize.

IMO that has a lot to do with paradigm. However, I won't have enough
time to explain it now. 

> > >What OO will do is help wash some of the dross out of the coding pool.
> > >
> > >But I've done enough Smalltalk in the past year to know that I can write
> > >just as
> > >sloppily in Smalltalk, and make even bigger errors, harder to correct,
> > >as I code
> > >my way along, without a previously completed design, as I can with
> > >anything.

That is exactly true

> > >If anything, Assembly Language is easier to fix, precisely because the
> > >procedures
> > >are more amenable to "redesign" and "reuse" than a single hirearchy.
> > >

I am not sure about that. I dusted out some of the games I wrote in
1982. I can't seem to easily grasp them, maybe because I completely
forgot Z80 assembly language, or maybe I don't have a Z80 machine or a
decent emulator to run. Even with an emulator, I would have had to
rewrite direct screen manipulation modules, keyboard modules and sound
modules. 

> > >>Turning a blind eye on Today's problems will not get us anywhere. First
> > >>of all, we should admit that we have a problem, then find a solution to
> > >>it. We ALL contribute to lost billions by ignoring what's happening
> > >>around us. 
> > >
> > >What problems? The lack of good software is due to the lack of good
> > >education,
> > >high levels of intelligence distributed all around in the people doing
> > >the work, and
> > >so on.  People do programming.  OO CAN be easier, in something like
> > >Smalltalk,
> > >because there is so much framework for grunt stuff like the GUI.
> > >
> > >So I greatly differ with your take on things here.

The problems I am mentioning about are collapses of big projects with a
typical 100 million waste per big project. These companies DO have very
good people, because they can afford them. And yes, there are usually
100s of people of which at least 10s are good. 

In the very beginning of the thread, I had four areas as the source of
the problem. Other three are vanished, and I have to defend only one,
namely OO approach. However, in my previous postings I stated people,
organizational structure, techniques and tools as the sources of the
problem. 

I do not think that we differ greatly, from what you see it looks like I
point procedure orientation as the only cause, which is not correct.

> > >>> Why is it that when anyone comes along with new techniques that represent
> > >>> a useful incremental advance in our knowledge in this area (e.g.
> > >>> functional programming, proof of correctness, your-favorite-fad-here)
> > >>> they feel compelled to hype them like this with the approach
> > >>
> > >>OO is not an incremental advance. It has started and continued that way,
> > >>because SIMULA was an extension to Algol, and some of the most dominant
> > >>languages are extensions of procedure oriented languages. This does more
> > >>harm than good to OO. Many professionals I have talked to told me that
> > >>until they made a switch ( or some of them call it a "click") they
> > >>weren't able to benefit from OO a lot. It is more difficult to have that
> > >>"click" if we have to work in an environment and a language which is
> > >>basically an OO extension to a procedural background. 
> > >>It is true that every newcomer announces that it is a significant
> > >>advancement over procedure orientation. This is because people are
> > >>worried about the current paradigm, and they in search for a better one. 
> > >
> > >Smalltalk and other OO paradigms are an unmitigated disaster at certain
> > >kinds
> > >of problems.  Ask me about Modified Midpoint integration or, say,
> > >adaptive Runge-
> > >Kutta under Smalltalk.  We give up as much as two orders of magnitude in
> > >computational efficiency.  The more a tool does for you, the more it
> > >also does
> > >to you.

The numerical number crunching problems are perfect problems that a von
Neumann machine is designed for, so can be handled quite elegantly with
procedural languages. They are well defined algorithms that take up a
very reasonable number of lines of code. However we need Runge-Kutta in
our real life even less than we need our calculator. I use Smalltalk
extensively, but revert back to C or even assembler when I need
procedural number crunching, and offer these as DLLs. On the other hand,
a simple ORB is reasonably trivial in Smalltalk, but if you want to
develop in any procedure oriented system, even in C++, it takes a lot of
time and effort.

I think people tend to see black and white. When I sent my first replies
to this thread, I made my postion clear by first defining the von
Neumann machine and what it was initially designed for. Anything that is
suitable to this initial design purpose should be handled by the
procedural approach, which IME&O is just about 10% of all our problems.
Anything beyond that is an abuse of the initial design purpose, and
requires much greater effort to get the same work done in a procedural
environment.

> > >
> > >What is being complained about here is that you treat OO as though a
> > >pure OO
> > >language "gives" all this good stuff without a price.  And, in reality,
> > >the price is
> > >quite high.

If you are talking about 20MB image Smalltalk systems, or 80MB Borland
compilers, I tend to agree with you there. They could have been done
simpler, and less complex. There is also another price that I will
mention later.

> > >>> The trouble with such hype is that inevitably it does not deliver, and then
> > >>> there is a danger of throwing out the baby with the bathwater and
> > >>> discarding what is useful along with the hype.
> > >>
> > >>OO as is now, is a struggling, and not much appreciated figure around.
> > >>It has its troubles, but they are slowly being ironed out. Yes, there
> > >>may be a short term backlash against OO, it may even go back a couple of
> > >>years. This is not important. It will come back, and will eventually
> > >>dominate.  
> > >
> > >I don't find anything "struggling" about using VisualWorks or IBM's
> > >VisualAge on
> > >Windows, OS/2 or OSF/Motif platforms -- they are basically just
> > >extentions of
> > >GUI paradigms built on top of Smalltalk/80 to begin with, so they are
> > >quite
> > >natural and straightforward to use -- ONCE ONE HAS CRACKED INTO THE
> > >HIREARCHY.
> > >
> > >The chief complaint I have about OO is that one has to learn a
> > >hirearchy, and one
> > >which is in the general case sloppily and amateurishly documented,
> > >instead of the
> > >better understood and generally much better documented procedural
> > >library.

It parallels my observations that the most difficult part of learning
OOP environments is their class hierarchy. Our company is working
towards visualizing these class hierarchies that in our experience
increase the learning curve no matter what other people say about
visualization. 

> > >This inferior documentation is, in my view, the reason for OO's lack of
> > >popular
> > >success.  It is, much as you are displaying here, more of a religion for
> > >its 
> > >adherents than it is regarded as what it should be -- a convenience
> > >tool.

I think it is a misunderstanding that I take OO as a religion. However,
in my position after observing how much better a decent OO approach is,
I see current defenders of the "existing system" much more religious
than I can ever be. In our company, we do not only practice OO, we also
experiment heavily with neural computing, genetic programming and fuzzy
logic, and use them in projects. OO has its shortcomings, but only one
of these shortcomings namely number crunching can be remedied by a pure
procedural approach.   

There are certain very serious problems though. First of all, people
don't even know why do we program the way we program, and think that
must be the right way to do it. I first wanted to indicate that by
pointing to the birth of procedure oriented programming, and I raised
the voice of its inventor to the dangers of using it at wide scale. 

> > >There is nothing OO can do that pure object code can't do.
                                          ^^^^^^
Was that ment to be procedural? If so, it is true. In fact it is being
done everywhere, everyday. However, there is a price that we all pay.
Again I'll explain in my posting later.

> > >All we're doing is adding the hirearchy to raise the level of
> > >abstraction, so one
> > >doesn't have to spend as much time fussing with daily details.
> > >

I will explain one very important difference between PO and OO approach
after the new year. I'll prepare and send a post when I have time. 

> > >>> The fact of the matter is that there is NO giant shift of paradigm involved
> > >>> here, despite what anyone says. Just look at the OO programs that people
> > >>> produce. They are not radically different from conventional procedural
> > >>> programs, and one would not expect them to be.
> > >>
> > >>Unfortunately, many OO programs that people produce are produced by
> > >>people who are learning. They will be better and better, the gap will be
> > >>larger and larger, and differences will be more and more obvious.
> > >
> > >Duh! This is arrogant nonsense, sir. OO cannot and will not make a case
> > >for itself
> > >until it can demonstrate to the average working programmer something in
> > >the way
> > >of return for the struggle to learn the hirearchy.

I could not possibly agree with the "arrogant nonsense" bit but the rest
is true. If you can see that learning the class hierarchy quicker can
accelerate the results, it is very positive. In fact this will be an
important area, but there are more, again I will explain in my upcoming
post. 

> > >>People have short memories. A very similar sort of discussion with
> > >>similar tones was done when first high level languages were introduced.
> > >>Proponents of machine code and assembly languages said, this new
> > >>paradigm was nothing new, just a bigger, bulkier way of doing the same
> > >>thing with speed penalties, it was not practical, people would never
> > >>program with them in masses, etc, etc. Now we see everything has settled
> > >>down, there are still people write code in assembly and nothing else,
> > >>however they are the minority.
> > >
> > >Yes, Assembler is the minority.  And as a result Microsoft Word wants
> > >120 megs on
> > >a disk, where WordStar lived comfortably in 64k, code and data both. 
> > >Word does
> > >very little more.
> > >
> > >Seems we were told the truth to begin with, eh?
> > >
> > >Word barely runs in 8 megs of RAM.
> > >
> > >You started out talking about waste.  Why 8 megs instead of 64k?

This is one of the kind of waste I am mentioning. I hope that you are
not claiming Microsoft uses OO to create Word. No way! The entire
Microsoft suite is a good example of how procedure oriented systems can
get out of control. 

If they had used a true OO approach from their operating system on, they
would have a much leaner system with a component architecture, and very
high degrees of reuse.

> > >We have some differences of opinion here.

And it is very healthy, we can learn from each other, and enlarge our
horizons. Without differences of opinion, the world would be such a
boring place. 

> > >
> > >Regards,
> > >
> > >Frank


> Yes, why? The most important reason is that most programmers don't know
> assembler or bother to learn it well enough to write decent code in it.

I don't really think that you need to know assembler to develop good
compact systems. In fact, we recently developed one of the most useful
visual development tools in existence. It is written in Smalltalk, and
developed in record time. The SLL of our VSE version is under 300KB
before compression. In fact, there was a debate in our company that if
we distributed our product in one floppy, nobody would take it
seriously, there were serious suggestions to bump it up to offer in
several floppies or offering a CD-ROM version only.

There are two types of waste we are mentioning here: 
1) The time and resources required to develop and maintain that system
2) The hardware demands of that system

By far the first item has the biggest impact. If the trends go like they
have been going in the past ten years, we will have about half of the
world's economy chewed by our blown computer costs of which about 75% or
more will be software development and maintenance costs around 2030
(down from 5% of the world economy in late 80s). Any savings we start
making now will have a huge impact on our future. 

The hardware demands of the systems also add to the waste, through to a
lesser degree. I will write about these when I prepare my post about the
subject of this thread.

Please hold on to your questions and objections till I have time to
prepare my posting, so that you have a whole perspective of what I am
talking about, then I will gladly accept any flames, as well as positive
comments. Taking out one statement I say and flaming it out of context
doesn't do much justice.

Kind Regards
Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: What is wrong with OO ?

[Tansel Ersavas]

Tansel Ersavas wrote:
 
> DeRose, S. J., Durand, D. G., Mylonas, E., and Renear A. H. (1995),
This line should read:
Durand, D. G., Mylonas, E., and Renear A. H. (1995),

Tansel
-----------------------------------------------------------------------
RASE Inc.                                                  Clark NJ USA
Voice: (908) 396 7145                            mailto:tansel@rase.com
Fax:   (908) 382 1383                              http://www.rase.com/
----Sufficiently advanced technology is indistinguishable from magic---
-------------------------------A.C. Clarke-----------------------------

Re: What is wrong with OO ?

[Tore Lund]

clovis@wartech.com wrote:
> 
> In <32C3E34F.5DC5@sn.no>, Tore Lund <tl001@sn.no> writes:
> 
>>Finally a voice of reason (etc.)
> 
> Why, Thanks, Tore!  I've been around the block a few times, and it 
> sounds as though you have been as well.

Just for the record: I am one of those lone developers who would like to
use OO or functional languages but cannot do so because they never
really get off the ground. Small-time customers want standards, and you
cannot sell them Eiffel or Miranda as a standard when 4GLs do all they
ever want to do in a cheaper and more portable way.

I hope that Java will change this. But if so happens, it will be due to
popular demand and a great user base rather than to any intrinsic
properties of Java itself. One problem with OO and other paradigms is
that they are never exposed to the merciless criticism of a demanding
marketplace and the consequent effort to satisfy customers.

Still, I make my living from programs that remedy the shortcomings of
4GLs, so maybe I should not complain. But it makes me feel more like a
scavenger than like the craftsman I would like to be.


Tore
-- 
Tore Lund <tl001@sn.no>

Re: What is wrong with OO ?

[Tore Lund]

Tansel Ersavas wrote:
> 
> 
>> Yes, why? The most important reason is that most programmers don't know
>> assembler or bother to learn it well enough to write decent code in it.
> 
> I don't really think that you need to know assembler to develop good
> compact systems.

You are quite right, but my comment was an answer to the question of why
it's hard to write and maintain programs in assembler. 

> In fact, we recently developed one of the most useful
> visual development tools in existence. It is written in Smalltalk, and
> developed in record time. The SLL of our VSE version is under 300KB
> before compression. In fact, there was a debate in our company that if
> we distributed our product in one floppy, nobody would take it
> seriously, there were serious suggestions to bump it up to offer in
> several floppies or offering a CD-ROM version only.

Fascinating. And thanks for telling us. If you have the time, please add
a comment about the execution speed of this Smalltalk system.


Regards,
Tore
-- 
Tore Lund <tl001@sn.no>

Re: What is wrong with OO ?

[Stephen Pendleton]

> 
> Yes, Assembler is the minority.  And as a result Microsoft Word wants 120
megs on
> a disk, where WordStar lived comfortably in 64k, code and data both. 
Word does
> very little more.
> 

To say that Word does little more than WordStar is comical. 

You people who complain about bloated code need to make the transition to
the 
modern age. Granted WordStar may have only have used 64k, but those were
the days
when 64k was a lot of memory.
	Worry less about efficiency and more about functionality and
maintainability
and you will make better software.

Steve

Re: What is wrong with OO ?

[clovis]

In <32C43AC8.24E2@sn.no>, Tore Lund <tl001@sn.no> writes:

>Yes, why? The most important reason is that most programmers don't know
>assembler or bother to learn it well enough to write decent code in it.

Most "programmers" don't bother to learn ANYTHING well enough to write well in
it.  With 20 years of C under my belt, I'm still asked to write snippets when I go
see a consulting client, because most of those who have been doing it for a while
write really atrocious C.  The same is true of assembly language -- people will
ask to see a snippet to see if one has just done it, or really knows what is going
on.

>You don't agree, of course, but the point here is is that the 64k
>program written in assembler will still be < 100k when written in C.
>There is no need for "code bloat" on the scale of 8 megs for
>maintainability purposes.

Well, not under 100k.  I typically find that, because of the need for "generality" in
C, 64k of assembler -- by someone who is really hot -- turns into about 256k of
C.  About 4 to 1 -- simply because the C code has to be so generalized, and the
assembler can really tune-down by being highly algorithm specific.

The more general the assembler, the less the difference, of course, until the sizes
become truly equivalent.  The real deal with Assembly Language is tuning that
code so that one exploits the instruction set, executes many fewer instructions etc,
which is mostly a matter of concern in realtime, or OS kernels, or diagnostics, where
one has to sort of do it all oneself.

Paradoxically -- and this really is a paradox -- Smalltalk seems to be smaller and
faster both when dealing with a GUI.  Minimum size on my VA applications, the really
small little demo things, is about 1.8 megs.  But it doesn't grow much unless one is
throwing the whole kitchen sink at things.  And the debugger etc etc and the whole
runtime development environment only occupies about 15 megs on disk including
a de facto text processing system, all sorts of graphical widgets, and some very
complex connection and self-maintainance code.

Compare this to, say, the Watcom C++ compiler which, to support all environments
and stuff, occupies 380 megs on a secondary drive.  I get Windows 3.1, Windows
95, Windows NT and OS/2 for about 35 megs under VisualAge -- and more and
better Windows and OS/2 than I'd get under any other system.

And, generally, I seem not to have any performance hit (perhaps because I'm clever
enough not to execute smalltalk code every time a variable changes).

OO can be wonderfully effective.

I can't figure out what they're doing in Word that takes 8 megs.

And herein is the danger of the Ultimate Procedural Model (getting back to OO
paradigms).

In Procedural, one builds a procedure for each action. Each procedure is separate,
and shares nothing with everything else.  Voila, an 8 meg "word processor" which
could probably be done in half that with OO, and probably run more quickly besides.

This is why code re-use is so important in a design.  Generality saves space, and
very often, a good deal of time as well.

Re: What is wrong with OO ?

[Rosimildo da Silva]

John (Max) Skaller wrote:
> 
> On 28 Dec 1996 04:58:39 GMT, clovis@wartech.com wrote:
> 
> >Would someone PLEASE and QUICKLY hang those who insist that code is
> >"self-documenting?"
> 
> The code I write _IS_ self-documenting.
> But then, I do write using a literate-programming system :-)

I believe that code MUST be self-documented, even though the tools
currently available does not help much.

my $02 cents.

Rosimildo.

Re: What is wrong with OO ?

[John (Max) Skaller]

On 28 Dec 1996 04:58:39 GMT, clovis@wartech.com wrote:

>Would someone PLEASE and QUICKLY hang those who insist that code is
>"self-documenting?"  

The code I write _IS_ self-documenting. 
But then, I do write using a literate-programming system :-)

Re: What is wrong with OO ?

[Tansel Ersavas]

clovis@wartech.com wrote:
> 
> In <5aa0eo$thd@krusty.irvine.com>, adam@irvine.com (Adam Beneschan) writes:
> >In article <32C557F6.532C@rase.com> tansel@rase.com writes:
> 
> You're quite right.  Tansel is acting like quite a pretender on this one, and he
> obviously doesn't know what either a Von Neumann machine is, or what a Turing
> machine is.  A Von Neumann "machine" is really a recommended architecture,
> and really, there aren't many of them.  They feature regular instruction sets,
> with zero duplication of function, and all operations being orthogonal.  The basic
> feature of the Von Neumann machine is all classes of basic arithmetic operation,
> and all classes of comparisions within the two basic numeric types.  The "ideal"
> Von Neumann machine supports natural numbers, integers, reals (actually, length
> limited rational numbers), in which any operation -- add, subtract, multiply, divide
> and compare -- are entirely separate.

I am preparing a Web page with references about the history of computing
that includes pointers to von Neumann architecture and his devised
machine, and the Turing machine, I'll make it available to everybody
when it is ready. On the subject of von Neumann architectures and Turing
machines, I wouldn't recommend that you to jump to conclusions before
seeing the material that I said I would post. 

> The Von Neumann model, while not strictly followed in terms of orthogonality, is
> inherent in every general purpose digital computing machine ever made, even
> the Intel 80x86 family (which does it all, but which is not symmetrical or wholly
> orthogonal; and the same is largely true of RISC, whose primary function is to
> reduce transistor count).

This is precisely my point.

...
 
> In short, all digital computers are essentially just variances on Von Neumann and
> Turing, both of whom were mathematicians interested in computing technology as
> the notion of a code-based computation became available, that is, a computing
> machine which was capable of responding to codes which could control execution
> based on previous results.

Can you point me to one popular CPU that uses a Turing machine as a main
means of computation? Turing machines are conceptually very significant,
especially for showing us that a regular grammar can be used to solve
all practically solvable problems, however their architectural influence
in modern computers is not comparable to the von Neumann architecture.
Some people think or even inacurately quote that von Neumann
architecture is a kind of a Turing machine. Although a Turing machine
can be used to parse and interpret any von Neumann style stored program,
the level of the grammars these two types of machines deal with are
essentially different. A Turing machine deals with a regular grammar,
whereas a von Neumann style stored program uses a context free grammar. 

To anybody interested in Alan Mathison Turing's Turing machines I
recommend this excellent source:
R. Herken, Berlin, FRG (Ed.) "The Universal Turing Machine, A
Half-Century Survey" Springer-Verlag Vienna New York 1995.

...

> None of this is really rocket science.  And it's never ceased to amaze me how many
> of the "hip" guys can't even define the basic terms.

Nobody says it is. Again, I would urge you to wait till I say what I
have to say about these subjects.
 
...

Happy new year to all
Tansel

Re: What is wrong with OO ?

[Jon S Anthony]

In article <5aa0eo$thd@krusty.irvine.com> adam@irvine.com (Adam Beneschan) writes:

> machines is that they execute one statement at a time, in order.  Most
> of the high-level languages I've seen do the same thing, whether or
> not they're OO languages.

Right.

> It seems to me that if (as implied by earlier posts in this thread)
> the "von Neumann" paradigm is the problem, then the solution is
> something like Backus' FP or Prolog or Haskell or dataflow--not OO,

Right.


> which seems to me to have nothing to do with whether the von Neumann
> model is being followed or not.  Am I missing something?

No, I think you have it surrounded.  Procedural/"Von Neumann" is
orthogonal to OO.  As is declaritive (which is the correct
counterpoint to procedural).

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Jon S Anthony]

In article <5aa73v$p14@news3.digex.net> ell@access5.digex.net (Ell) writes:

> Ian Joyner (i.joyner@acm.org) wrote:
> : Ell wrote:
> : > 
> : > Ian Joyner (i.joyner@acm.org) wrote:
> : > 
> : > : What made me think of this was that Bill Gates stated in his book that
> : > : Boeng designed the entire 777 aircraft using one gigantic electronic
> : > : document! Physical engineering disciplines have made good use of
> : > : computing technology, it's about time software engineers followed
> : > : the same path... better and more productive languages and environments,
> : > : and stop defending archaic 25 year old languages from another era.
>  
> : > I find some 25 year languages like C++ very useful even today.  A lot of
> : > following a good OO paradigm is in how tools are used and approached.
>  
> : And people can still drive model T Fords, and fly WWI planes. 
> 
> I find the key aspects of C++ to be within the parameters of the
> _progressive_ OO paradigm and practice.  In many ways C++ has led and
> still leads in the expression and implementation of many significantly
> useful OO concepts.

With respect to this "led/leads" claim: Such as?????  I can't think of
_any_ where this is true.  Though I can think of at least one
important _implementation_ aspect where this seems to be true.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Neville Black]

This is all mythology. The fundamental aspect of a von Neumann machine
is to
store program and data in the same memory. This was thought to be hot
stuff for
"self modifying programs", and also very clever way of fully utilizing
memory (precious beyond
imagining). The  "opposite" of a von Neumann machine is the "Harvard
Architecture" in which program
and data memory are distinct. Example: the IBM 610 which used magnetic
drum for data storage and
paper tape for code (yes, the tape was automatically replicated for each
iteration..).

Given the large drop in memory costs, it is surprising that Harvard
Archirectures have not
seen a revival.....



clovis@wartech.com wrote:
> 
> In <5aa0eo$thd@krusty.irvine.com>, adam@irvine.com (Adam Beneschan) writes:
> >In article <32C557F6.532C@rase.com> tansel@rase.com writes:
> 
> You're quite right.  Tansel is acting like quite a pretender on this one, and he
> obviously doesn't know what either a Von Neumann machine is, or what a Turing
> machine is.  A Von Neumann "machine" is really a recommended architecture,
> and really, there aren't many of them.  They feature regular instruction sets,
> with zero duplication of function, and all operations being orthogonal.  The basic
> feature of the Von Neumann machine is all classes of basic arithmetic operation,
> and all classes of comparisions within the two basic numeric types.  The "ideal"
> Von Neumann machine supports natural numbers, integers, reals (actually, length
> limited rational numbers), in which any operation -- add, subtract, multiply, divide
> and compare -- are entirely separate.
> 
> That is ALL we mean by a Von Neumann machine.  If you delete ANY aspect of a
> Von Neumann machine, you can't do basic computation.  One is either missing
> discrete whole numbers, or the ability to compute rational numbers and their
> real number simulation, or the ability to tell if one number is the same size as,
> or larger, than another number.
  ....<snip>.....

Re: What is wrong with OO ?

[clovis]

In <edward-3112960259160001@server.magicmouse.com>, edward@magicmouse.com (Edward de Jong) writes:

Excellent analysis.  Thanks for sharing it.

And it is true -- without a LOT of sideline documentation, pure object code
IS the most difficult to comprehend and maintain.

>There is nothing comical at all in the comparison between WordStar and
>Microsoft Word.  WordStar was the creation of one genius, Rob Barnaby,
>whom I met when Micropro bought my clone of WordStar, written in C, which
>became WordStar 2000.  It took 12 programmers, myself included, one entire
>year, and about 100,000 lines of code to surpass the work of just one man,
>working in macro assembler.  But let me tell you, macro assemblers are
>very clever tools; they can do amazing things; you can have multiple
>levels of macros, which are effectively miniature compilers, which output
>executable code, with the lowest possible overhead.  
>
>In the hands of a genius, assembler can do amazing things in tiny spaces;
>that is why Barnaby could do so much in so little room.  To implement a
>word processor that could run (with overlays), in a total space of 64kb,
>that had mail merge, all the printer drivers embedded in it, as well as
>controlling the screen in an optimal way, should be acknowledged for the
>amazing feat that it was.
>
>The reason macro assembler can be MORE POWERFUL than so-called higher
>level languages is that by using multiple levels of macros, you are
>creating a multi-level programming language, while most high level
>languages actually operate on a single or double level of abstraction.
>
>The real practical reasons for not using assembler are:
>   1) geniuses are rather rare
>   2) the resulting product has a lot of lines of code (4 to 10 times more
>than high level languges), which makes it harder to understand
>   3) the resulting product is almost impossible for another person to
>understand, because of the multi-level programming involved.
>
>-- 
>edward@magicmouse.com
>author of Flying Colors for Macintosh, Pippin, and Windows platforms

Re: What is wrong with OO ?

[Ian Joyner]

John (Max) Skaller wrote:
> 
> On 28 Dec 1996 04:58:39 GMT, clovis@wartech.com wrote:
> 
> >Would someone PLEASE and QUICKLY hang those who insist that code is
> >"self-documenting?"
> 
> The code I write _IS_ self-documenting.
> But then, I do write using a literate-programming system :-)

I think code should be written to be self-documenting, but certainly
it is not self-documenting in itself, unless you have a conscientious
programmer like John. But yes it can and should be self-documenting.

Since we are talking about documentation, how many documents should
you produce on a project?

Many people I suspect would start to enumerate 'requirements spec',
'functional design doc,' 'detailed design', etc.

However, the answer, I think is one! Only one document should be
produced for any project no matter how large. This will link
requirements and functions with bits of program, etc. With facilities
like OpenDoc and to a lesser extent OLE becoming available, such
documents will be possible. But they will require better programming
languages.

What made me think of this was that Bill Gates stated in his book that
Boeng designed the entire 777 aircraft using one gigantic electronic
document! Physical engineering disciplines have made good use of
computing technology, it's about time software engineers followed
the same path... better and more productive languages and environments,
and stop defending archaic 25 year old languages from another era.

And this gets back to a point Robert Martin made quite a while ago
in this thread, that analysis and design is programming, and that
these should not be done by different groups.

For more thoughts:

http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html 
------------------------------------------------------------------------
Ian Joyner       | "for when lenity and cruelty play | All opinions are
Internet email:  |  for a kingdom, the gentler       | personal and are
i.joyner@acm.org |  gamester is the soonest winner"  | not Unisys
                 |       William Shakespeare Henry V | official comment
------------------------------------------------------------------------

Re: What is wrong with OO ?

[Ell]

Ian Joyner (i.joyner@acm.org) wrote:

: What made me think of this was that Bill Gates stated in his book that
: Boeng designed the entire 777 aircraft using one gigantic electronic
: document! Physical engineering disciplines have made good use of
: computing technology, it's about time software engineers followed
: the same path... better and more productive languages and environments,
: and stop defending archaic 25 year old languages from another era.

I find some 25 year languages like C++ very useful even today.  A lot of
following a good OO paradigm is in how tools are used and approached.
 
: And this gets back to a point ...  made quite a while ago
: in this thread, that analysis and design is programming, and that
: these should not be done by different groups.

Because Boeing had a super diagram doesn't mean it's highest level was
predicated on a single, or even specific set of, technology, i.e. on one
or more specific languages, or distribution technologies in our case.

For more along these lines one should read Constantine's end column in
the latest Object magazine.  He advocates _delaying_ implementation as
much as possible.

Elliott

Re: What is wrong with OO ?

[Adam Beneschan]

In article <32C557F6.532C@rase.com> tansel@rase.com writes:
 
 >The numerical number crunching problems are perfect problems that a von
 >Neumann machine is designed for, so can be handled quite elegantly with
 >procedural languages. They are well defined algorithms that take up a
 >very reasonable number of lines of code. However we need Runge-Kutta in
 >our real life even less than we need our calculator. I use Smalltalk
 >extensively, but revert back to C or even assembler when I need
 >procedural number crunching, and offer these as DLLs. On the other hand,
 >a simple ORB is reasonably trivial in Smalltalk, but if you want to
 >develop in any procedure oriented system, even in C++, it takes a lot of
 >time and effort.

A number of times in this thread, OO has been compared to "von Neumann
machines" as if they are opposing paradigms.  This is confusing to
me--could someone explain it?  My understanding of von Neumann
machines is that they execute one statement at a time, in order.  Most
of the high-level languages I've seen do the same thing, whether or
not they're OO languages.  It seems to me that if (as implied by
earlier posts in this thread) the "von Neumann" paradigm is the
problem, then the solution is something like Backus' FP or Prolog or
Haskell or dataflow--not OO, which seems to me to have nothing to do
with whether the von Neumann model is being followed or not.  Am I
missing something?

                                -- Adam

Re: What is wrong with OO ?

[Tom Bushell]

On 29 Dec 1996 22:09:28 GMT, clovis@wartech.com wrote:

>Paradoxically -- and this really is a paradox -- Smalltalk seems to be smaller and
>faster both when dealing with a GUI.  Minimum size on my VA applications, the really
>small little demo things, is about 1.8 megs.  But it doesn't grow much unless one is
>throwing the whole kitchen sink at things.  And the debugger etc etc and the whole
>runtime development environment only occupies about 15 megs on disk including
>a de facto text processing system, all sorts of graphical widgets, and some very
>complex connection and self-maintainance code.

I have noticed this also applies to Visual BASIC and Forth.  These
languages all use a technique that is often poo pooed by C/C++ junkies
obsessed with wringing every cycle out of the CPU - they compile to a
virtual machine, which is then interpreted.  These runtimes tend to be
very compact compared to the native code produced by conventional
compilers.  Of course, the execution time is slower, but this normally
is only an issue for about 10% or less of the code in a typical
program.  This 10% can be written in C or assembler, but this is
rarely necessary.

I also suspect that the bloated executables often execute more slowly
than they would if interpreted, because they spend so much time being
swapped in an out of virtual memory.

-Tom
 


----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Ian Joyner]

Ell wrote:
> 
> Ian Joyner (i.joyner@acm.org) wrote:
> 
> : What made me think of this was that Bill Gates stated in his book that
> : Boeng designed the entire 777 aircraft using one gigantic electronic
> : document! Physical engineering disciplines have made good use of
> : computing technology, it's about time software engineers followed
> : the same path... better and more productive languages and environments,
> : and stop defending archaic 25 year old languages from another era.
> 
> I find some 25 year languages like C++ very useful even today.  A lot of
> following a good OO paradigm is in how tools are used and approached.

And people can still drive model T Fords, and fly WWI planes. 

The most important tool is the compiler. The problem with C and C++
tools is that many of them are to make up for language deficiencies.
With a better designed language, which takes into account what modern
computers can do, the need for many of these tools simply disappears.
Also as I wrote in another thread, the need for most style rules
that programmers are encumbered with also disappears.

> : And this gets back to a point ...  made quite a while ago
> : in this thread, that analysis and design is programming, and that
> : these should not be done by different groups.
> 
> Because Boeing had a super diagram doesn't mean it's highest level was
> predicated on a single, or even specific set of, technology, i.e. on one
> or more specific languages, or distribution technologies in our case.

Correct. It would be using the compound document paradigm.

> For more along these lines one should read Constantine's end column in
> the latest Object magazine.  He advocates _delaying_ implementation as
> much as possible.

Exactly, the point! In fact the implementation should be left up to
the compiler. But too much with C++ you are forced to think of how
to implement things early. It is rather like flying the WWI plane,
where you must think to go left, I must adjust the tail to do so.

My paper at:

http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html

explains how C++ burdens the programmer with 'early implementation'
problems, and explains how good OO languages should remove this
burden from the programmer.
------------------------------------------------------------------------
Ian Joyner       | "for when lenity and cruelty play | All opinions are
Internet email:  |  for a kingdom, the gentler       | personal and are
i.joyner@acm.org |  gamester is the soonest winner"  | not Unisys
                 |       William Shakespeare Henry V | official comment
------------------------------------------------------------------------

Re: What is wrong with OO ?

[Ell]

Ian Joyner (i.joyner@acm.org) wrote:
: Ell wrote:
: > 
: > Ian Joyner (i.joyner@acm.org) wrote:
: > 
: > : What made me think of this was that Bill Gates stated in his book that
: > : Boeng designed the entire 777 aircraft using one gigantic electronic
: > : document! Physical engineering disciplines have made good use of
: > : computing technology, it's about time software engineers followed
: > : the same path... better and more productive languages and environments,
: > : and stop defending archaic 25 year old languages from another era.
 
: > I find some 25 year languages like C++ very useful even today.  A lot of
: > following a good OO paradigm is in how tools are used and approached.
 
: And people can still drive model T Fords, and fly WWI planes. 

I find the key aspects of C++ to be within the parameters of the
_progressive_ OO paradigm and practice.  In many ways C++ has led and
still leads in the expression and implementation of many significantly
useful OO concepts.

Elliott

Re: What is wrong with OO ?

[clovis]

In <5aa0eo$thd@krusty.irvine.com>, adam@irvine.com (Adam Beneschan) writes:
>In article <32C557F6.532C@rase.com> tansel@rase.com writes:

You're quite right.  Tansel is acting like quite a pretender on this one, and he 
obviously doesn't know what either a Von Neumann machine is, or what a Turing
machine is.  A Von Neumann "machine" is really a recommended architecture,
and really, there aren't many of them.  They feature regular instruction sets,
with zero duplication of function, and all operations being orthogonal.  The basic
feature of the Von Neumann machine is all classes of basic arithmetic operation,
and all classes of comparisions within the two basic numeric types.  The "ideal"
Von Neumann machine supports natural numbers, integers, reals (actually, length
limited rational numbers), in which any operation -- add, subtract, multiply, divide
and compare -- are entirely separate.

That is ALL we mean by a Von Neumann machine.  If you delete ANY aspect of a
Von Neumann machine, you can't do basic computation.  One is either missing
discrete whole numbers, or the ability to compute rational numbers and their
real number simulation, or the ability to tell if one number is the same size as,
or larger, than another number.

The Von Neumann model, while not strictly followed in terms of orthogonality, is
inherent in every general purpose digital computing machine ever made, even
the Intel 80x86 family (which does it all, but which is not symmetrical or wholly
orthogonal; and the same is largely true of RISC, whose primary function is to
reduce transistor count).

If you are using a discrete representation, noise-resistant at speed (e.g. this mandates
binary encoding at the hardware level), Von Neumann is the Ideal Model.

The Turing Machine is the minimal machine -- generally thought of, but not 
necessarily, a pure Von Neumann, architecture.  Anything computable is computable
on a Turing Machine with sufficient memory.

In short, all digital computers are essentially just variances on Von Neumann and
Turing, both of whom were mathematicians interested in computing technology as
the notion of a code-based computation became available, that is, a computing
machine which was capable of responding to codes which could control execution
based on previous results.

Similarly, compilers are merely translators which first parse an artificial language,
translate (generally) to P-Code, and then finally translate to native object code
in the code generator.

None of this is really rocket science.  And it's never ceased to amaze me how many
of the "hip" guys can't even define the basic terms.

The most "Von Neumann" architecture seen on a microprocessor was the National
Semi 16032 family in its original incarnation.  It was entirely symmetrical and
entirely orthogonal as nearly as I could tell.  The Motorola 68k family was mostly
DEC PDP like and borrowed a bit from the VAX as well.  The Intel 80x86 family was,
and is, quite a mess in its lack of symmetry, and is also not at all fully orthogonal;
sometimes it takes two instructions to do one function (memory-memory move from
a single register), and sometimes, "special" instructions perform the functoin of
several available, simpler instructions.

The only "real" operations the hardware CAN perform at this point in time are
the four arithmetic operations (+,-,*,/) and compares, and jumps/branches based
on flag settings.  The most advanced math co-processing units are just larger
blocks of these operations.

Assembler will ALWAYS be the most efficient language.  The more you abstract the
problem, the more you "generalize" the solution to a given problem, the more you
necessarily give up in efficiency.  C takes a minimal 3x hit on integer arithmetic,
10x on more complex stuff; and OO, because of the overhead interpreting where
to send things, is 10x on top of that.

Whether one can AFFORD to spend the time hand-tweaking a fullbore assembler
application is another matter.  Obviously, we have to have enough talent to write
3x over C, and 30x over OO.

The optimal solution is a tradeoff -- a genuine cost/benefit relationship.

My notion of the ideal and genuine Systems Analyst is someone who has the
intellect to break a problem to its component parts, and localize which tools and
components meet the cost/benefit analysis which gives maximum bang for the
buck at each component level.

Assembly language has its place.  No systems programmer would discard it for a
heartbeat -- and it is universally used in realtime since only hand-carved assembler
allows on to rigorously control latency and pathlength.  Procedural is much easier
to maintain, and is typically the language of choice for people doing numerical
analysis.  Equations are more readily written/debugged/maintained in them; the
prototype was FORTRAN, which was the FIRST procedural language and was
intended to support primarily this kind of operation.  OO is, in my view, strictly
a Smalltalk proposition until something slicker comes along.

I personally use all three in Smalltalk applications which involve a variety of
disciplines.  Smalltalk handles the GUI, but engines in C and ASM are also required
in some cases.  Any realtime requirements point to ASM, and any number crunching
points to C most of the time (Assembler if the computation must be made in
realtime, and be interruptable in mid-stream).

Smalltalk itself is not entirely Smalltalk.  It contains both procedural (often C), and
frequently ASM routines at the kernel since no general purpose machine ever
built comprehends objects -- all the underlying hardware knows about is basic
arithmetic, compares, and jumps/branches based on flags settings.

ASM is REALITY.

C is an abstraction of that reality.

Smalltalk is an abstraction of reality at a higher level than C.

And that's all that is REALLY happening here.

We're building in convenience features to avoid having to write 200 lines of
Assembler to handle a single Smalltalk message.  And we get "safety features"
to go along with it (where Assembler has no safety features at all).

Where Smalltalk simply "does not understand message XXX" Asm returns garbage,
or plain crashes.

This is why, although I'm as good as they come at basic Von Neumann coding,
I don't sneer at Smalltalk.  One instance of a Smalltalk debugger coming up with
"YYY doesn't understand XXX" could be worth 8 hours of assembler debugging.

It's a tradeoff, and if we want to represent ourselves as real computer scientists,
and real computing professionals, it behooves us to be able to explain in clear
terms why one paradigm is better, where it is better, and the details of why it is
better AT A GIVEN TASK.

I'd never code for a GUI with assembler, nor use Smalltalk for solving systems of
differential equations.

We can get by without smalltalk if we must.  If we try to do without Von Neumann,
there isn't such a thing as a working computer.  If we try to do without Turing
Theory and practice, we are again without a working computer.  If we try to do
without object code, the machine will never understand us, and that means, 
basically, the Assembler, and we can't write working programs even if we have
a working computer if we don't use that object code.  We CAN live without C, or 
C++, or Smalltalk.  I wouldn't like it a lot to do without them.  The whole point is
that I'm so far advanced on all levels that I can use any of them interchangably.

Let's get it right, people.

Object code (the assembler's output) is reality.  Von Neumann is reality.  Turing is 
reality.

Procedural and OO are only TOOLS built on these basics.  Machines work just
fine without them.  They don't work AT ALL without object code, assemblers,
Von Neumann basics and Turing Basics.

The rest is extremely convenient and extremely productive.  But they're just the
decorations on the icing on the cake.  And if they disappeared tomorrow, we'd
all live, and still get our work done -- just more slowly and with more frustration
than before.

 
> >The numerical number crunching problems are perfect problems that a von
> >Neumann machine is designed for, so can be handled quite elegantly with
> >procedural languages. They are well defined algorithms that take up a
> >very reasonable number of lines of code. However we need Runge-Kutta in
> >our real life even less than we need our calculator. I use Smalltalk
> >extensively, but revert back to C or even assembler when I need
> >procedural number crunching, and offer these as DLLs. On the other hand,
> >a simple ORB is reasonably trivial in Smalltalk, but if you want to
> >develop in any procedure oriented system, even in C++, it takes a lot of
> >time and effort.
>
>A number of times in this thread, OO has been compared to "von Neumann
>machines" as if they are opposing paradigms.  This is confusing to
>me--could someone explain it?  My understanding of von Neumann
>machines is that they execute one statement at a time, in order.  Most
>of the high-level languages I've seen do the same thing, whether or
>not they're OO languages.  It seems to me that if (as implied by
>earlier posts in this thread) the "von Neumann" paradigm is the
>problem, then the solution is something like Backus' FP or Prolog or
>Haskell or dataflow--not OO, which seems to me to have nothing to do
>with whether the von Neumann model is being followed or not.  Am I
>missing something?
>
>                                -- Adam

Re: What is wrong with OO ?

[clovis]

In <32c72272.204443082@news.nstn.ca>, tbushell@fox.nstn.ns.ca (Tom Bushell) writes:
>On 29 Dec 1996 22:09:28 GMT, clovis@wartech.com wrote:
>
>>Paradoxically -- and this really is a paradox -- Smalltalk seems to be smaller and
>>faster both when dealing with a GUI.  Minimum size on my VA applications, the really
>>small little demo things, is about 1.8 megs.  But it doesn't grow much unless one is
>>throwing the whole kitchen sink at things.  And the debugger etc etc and the whole
>>runtime development environment only occupies about 15 megs on disk including
>>a de facto text processing system, all sorts of graphical widgets, and some very
>>complex connection and self-maintainance code.
>
>I have noticed this also applies to Visual BASIC and Forth.  These
>languages all use a technique that is often poo pooed by C/C++ junkies
>obsessed with wringing every cycle out of the CPU - they compile to a
>virtual machine, which is then interpreted.  These runtimes tend to be
>very compact compared to the native code produced by conventional
>compilers.  Of course, the execution time is slower, but this normally
>is only an issue for about 10% or less of the code in a typical
>program.  This 10% can be written in C or assembler, but this is
>rarely necessary.

It depends on the application.  A proper architect breaks the problems into rational
pieces, and uses the appropriate paradigm on each.  An example may help.

I am presently writing a simulator which models the flight of ballistic objects in
4 space, where the 4-space computations are second order differential equations.
The simulator is not written all in Smalltalk.  Chunks which are bad for Smalltalk
are done in C or Assembler.  If I had to do realtime, there would be an Assembler
dispatcher controlling the system which would itself be hardware-driven.

>I also suspect that the bloated executables often execute more slowly
>than they would if interpreted, because they spend so much time being
>swapped in an out of virtual memory.

I entirely concur with this sentiment.  If you gots to swap, a VM works better and
faster.  Disk access is one of the major IO dogs of the system.  Fairly cheap chips
are running 10,000x faster than a disk.  If any significant swapping occurs, one
can kiss performance goodbye.

Re: What is wrong with OO ?

[clovis]

In <5aa73v$p14@news3.digex.net>, ell@access5.digex.net (Ell) writes:

>I find the key aspects of C++ to be within the parameters of the
>_progressive_ OO paradigm and practice.  In many ways C++ has led and
>still leads in the expression and implementation of many significantly
>useful OO concepts.

I concur with this, but think it does not go far enough.

ANY language, up to and including direct object code, is just fine.

The real problem is personal discipline -- designing completely before coding.

Wirth's paradigm is STILL at the basis of all good design and coding practice.

Data Structures + Algorithms = Programs.

This whole thread somehow ignors that basic reality.  The most aggressive 
paradigm still respects Wirth's basic rule.  One MUST have structured data (otherwise
exact access is impossible, and all algorithms produce garbage).  One MUST have
algorithms -- otherwise, the data is nothing more than an electronic, fixed book
which one can't even access reliably.

Any language which provides both these features is sufficient.

All we're really discussing is HOW to provide data structures and algorithms.

There isn't a real paradigm shift until the basic model itself changes.  All we're
really talking about is how to represent the data structures and algorithms, that is,
how to go about implementing them.

Re: What is wrong with OO ?

[Edward de Jong]

There is nothing comical at all in the comparison between WordStar and
Microsoft Word.  WordStar was the creation of one genius, Rob Barnaby,
whom I met when Micropro bought my clone of WordStar, written in C, which
became WordStar 2000.  It took 12 programmers, myself included, one entire
year, and about 100,000 lines of code to surpass the work of just one man,
working in macro assembler.  But let me tell you, macro assemblers are
very clever tools; they can do amazing things; you can have multiple
levels of macros, which are effectively miniature compilers, which output
executable code, with the lowest possible overhead.  

In the hands of a genius, assembler can do amazing things in tiny spaces;
that is why Barnaby could do so much in so little room.  To implement a
word processor that could run (with overlays), in a total space of 64kb,
that had mail merge, all the printer drivers embedded in it, as well as
controlling the screen in an optimal way, should be acknowledged for the
amazing feat that it was.

The reason macro assembler can be MORE POWERFUL than so-called higher
level languages is that by using multiple levels of macros, you are
creating a multi-level programming language, while most high level
languages actually operate on a single or double level of abstraction.

The real practical reasons for not using assembler are:
   1) geniuses are rather rare
   2) the resulting product has a lot of lines of code (4 to 10 times more
than high level languges), which makes it harder to understand
   3) the resulting product is almost impossible for another person to
understand, because of the multi-level programming involved.

-- 
edward@magicmouse.com
author of Flying Colors for Macintosh, Pippin, and Windows platforms

Re: What is wrong with OO ?

[Nick Leaton]

> The real practical reasons for not using assembler are:
>    1) geniuses are rather rare
>    2) the resulting product has a lot of lines of code (4 to 10 times more
> than high level languges), which makes it harder to understand
>    3) the resulting product is almost impossible for another person to
> understand, because of the multi-level programming involved.
> 

Oh, and it is hard to port to machines that don't have that instruction
set.

Ah he say's retorically, you can get the macros to do it, but then again
is that what a compiler does?
-- 

Nick

Re: What is wrong with OO ?

[Robert C. Martin]

In article <5aa0eo$thd@krusty.irvine.com>, adam@irvine.com (Adam
Beneschan) wrote:

> A number of times in this thread, OO has been compared to "von Neumann
> machines" as if they are opposing paradigms.  This is confusing to
> me--could someone explain it?  My understanding of von Neumann
> machines is that they execute one statement at a time, in order.  Most
> of the high-level languages I've seen do the same thing, whether or
> not they're OO languages.  It seems to me that if (as implied by
> earlier posts in this thread) the "von Neumann" paradigm is the
> problem, then the solution is something like Backus' FP or Prolog or
> Haskell or dataflow--not OO, which seems to me to have nothing to do
> with whether the von Neumann model is being followed or not.  Am I
> missing something?

Von Neumann invented the notion that the computer program could be
stored in the memory of the computer (rather than wired in through a 
patch panel).  At least that is my recollection.

A "Von Neumann Machine" is something different altogether.  It is a 
machine that knows how to make copies of itself.  Humans are Von Neumann
machines.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Robert C. Martin]

In article <32C88BE0.7F2B@acm.org>, i.joyner@acm.org wrote:

> The most important tool is the compiler. The problem with C and C++
> tools is that many of them are to make up for language deficiencies.
> With a better designed language, which takes into account what modern
> computers can do, the need for many of these tools simply disappears.
> Also as I wrote in another thread, the need for most style rules
> that programmers are encumbered with also disappears.

This is undoubtedly true.  As engineers we need a CAE system that combines
the CASE tool, editor, compiler, documentation tool, debugger, test plan
generator, simulator, etc into a single seamless facility.  We should be 
able to browse through our design diagrams, focusing into certain points,
double clicking on an adornment or icon to bring up a stretch of "source code"
which we could edit.  Then build and debug in the same environment.

Such a system maintain traceability between requirements, use cases, design
artifacts and modules.  It would maintain lists of programmer and analysts
notes that were germane to each other.  It would facilitate communcations
between engineers working on the project regardless of their location.  It would
facilitate configuration management and version control.  It would facilitat
project management.

No such tool exists today.  I think it will be a long time before such
a tool does exist.  But I can dream.

> Exactly, the point! In fact the implementation should be left up to
> the compiler. But too much with C++ you are forced to think of how
> to implement things early. It is rather like flying the WWI plane,
> where you must think to go left, I must adjust the tail to do so.

Of course, after a little practice, the notion of turning right immediately
translates into the corresponding pressures and velocity profiles for the
stick and the pedals.  No thought is required.  The appropriate responses become
wired into the brain.  

So it is with any computer language.  Once you have mastered it, its use
becomes wired in, and the struggle with the layer between design and 
implementation disappears.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Robert C. Martin]

In article <5aae85$ad8@masters0.InterNex.Net>, clovis@wartech.com wrote:

> In <5aa73v$p14@news3.digex.net>, ell@access5.digex.net (Ell) writes:
> 
> >I find the key aspects of C++ to be within the parameters of the
> >_progressive_ OO paradigm and practice.  In many ways C++ has led and
> >still leads in the expression and implementation of many significantly
> >useful OO concepts.
> 
> I concur with this, but think it does not go far enough.
> 
> ANY language, up to and including direct object code, is just fine.
> 
> The real problem is personal discipline -- designing completely before coding.
> 
> Wirth's paradigm is STILL at the basis of all good design and coding practice.
> 
> Data Structures + Algorithms = Programs.
> 
> This whole thread somehow ignors that basic reality.  The most aggressive 
> paradigm still respects Wirth's basic rule.  One MUST have structured
data (otherwise
> exact access is impossible, and all algorithms produce garbage).  One
MUST have
> algorithms -- otherwise, the data is nothing more than an electronic,
fixed book
> which one can't even access reliably.
> 
> Any language which provides both these features is sufficient.
> 
> All we're really discussing is HOW to provide data structures and algorithms.
> 
> There isn't a real paradigm shift until the basic model itself changes. 
All we're
> really talking about is how to represent the data structures and
algorithms, that is,
> how to go about implementing them.

The paradigm shift in OO comes about because of some very different
separation strategies.  Prior to OO, data was accessed from data structures.
Any algorithm that needed that data had knowledge of the data structures.
In OO, this changes.  Some algorithms are closely associated with 
a data structure and have intimate knowledge of it.  However, other algorithms,
that use the data within the data structure have no knowledge of the data
structure.  They are isolated from the data through abstract interfaces. 
When
the data structure changes, these algorithms do not change.  Moreover, these
algorithms can make use of many different kinds of data structures without
knowing it.

Thus there is a fundemental change.  We still create data structures, and
we still create algorithms.  But in OO we also create interfaces that
separate some algorithms from some data structures.  Then we must decide which
algorithms know about which data structures, and which should be kept separate.
It is that decision that is called OOD.

If you don't believe that this is a fundemental paradigm shift, then consider
that this simple trick of separating algorithms and data structures creates
an equation that is quite different from Wirth's:

program = Interfaces(algorithms,data_structures)

Where the algorithms and data_structures are independent variables that
have no knowledge of each other, and the interfaces are the mapping functions
that bind the two together to create certain programs.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Nigel Tzeng]

In article <5a9r1k$e74@news4.digex.net>, Ell <ell@access1.digex.net> wrote:

[snip]

>Because Boeing had a super diagram doesn't mean it's highest level was
>predicated on a single, or even specific set of, technology, i.e. on one
>or more specific languages, or distribution technologies in our case.

Actually I think that one can make the case that the highest level was
predicated on a specific set of technology.  I'm going to speculate a
little here since I know virtually nothing about the actual 777 design
but here goes:

Say they started with a specific weight goal for the airframe or they
couldn't get the performance they wanted out of the aircraft.  They
thought they could meet this goal through the use of composites.  The
choice of composites then bounds the high level airframe architecture
because of what you can and cannot do with composites (compare to say
conventional airframes made of metal).

Likewise they may have started with the assumption that they would use
a computer controlled fly-by-wire system.  This technology also
constrains the overall architecture of the aircraft.

I don't believe that you can completely separate the architecture from
the underlying technology as cleanly as you imply.

For a software example if you decide that your key technology is Java
then your overall structure better not be based on having access to
multiple inheritance.

>Elliott

Nigel

Re: What is wrong with OO ?

[Ell]

Jon S Anthony (jsa@alexandria) wrote:
: ell@access5.digex.net (Ell) writes:
: 
: > Ian Joyner (i.joyner@acm.org) wrote:
: > : Ell wrote:
: > : > 
: > : > Ian Joyner (i.joyner@acm.org) wrote:
: > : > 
: >: > : What made me think of this was that Bill Gates stated in his book that
: >: > : Boeng designed the entire 777 aircraft using one gigantic electronic
: >: > : document! Physical engineering disciplines have made good use of
: >: > : computing technology, it's about time software engineers followed
: >: > : the same path... better and more productive languages and environments,
: >: > : and stop defending archaic 25 year old languages from another era.
  
: > : > I find some 25 year languages like C++ very useful even today.  A lot of
: > : > following a good OO paradigm is in how tools are used and approached.
  
: > : And people can still drive model T Fords, and fly WWI planes. 
 
: > I find the key aspects of C++ to be within the parameters of the
: > _progressive_ OO paradigm and practice.  In many ways C++ has led and
: > still leads in the expression and implementation of many significantly
: > useful OO concepts.
 
: With respect to this "led/leads" claim: Such as?????  I can't think of
: _any_ where this is true.  Though I can think of at least one
: important _implementation_ aspect where this seems to be true.

Led (first or second) wrt the OO paradigm: Private data members, static
resolution of overloaded functions, protected members, and multiple
inheritance. Correct me if I'm wrong.  Remember this is wrt the early
'80's.

Elliott

Re: What is wrong with OO ?

[Jon S Anthony]

In article <5acjtn$5uj@news3.digex.net> ell@access1.digex.net (Ell) writes:

> Jon S Anthony (jsa@alexandria) wrote:
> : With respect to this "led/leads" claim: Such as?????  I can't think of
> : _any_ where this is true.  Though I can think of at least one
> : important _implementation_ aspect where this seems to be true.
> 
> Led (first or second) wrt the OO paradigm: Private data members, static
> resolution of overloaded functions, protected members, and multiple
> inheritance. Correct me if I'm wrong.  Remember this is wrt the early
> '80's.


Recheck your facts.  Led/lead means "first" to me and certainly
carries that connotation around with it even if you want to pull a
Humpty Dumpty.  Private data member stuff was in various languages
before "C with classes" was even conceived (e.g., CLU, Ada83).  It
certainly existed in Eiffel before C++ was christened.  Protected
capability was certainly in Eiffel-1 which predates C++.  Same with
overload resolution (e.g., Algol68 had this as did Ada 83 compilers
that were in the field before CWC or C++).  MI was in Eiffel from the
start and that predates its appearance in C++ for sure.

Next I suppose you will be trying to tell me it was the first to have
generics (templates) or namespaces or assignment attempt or RTTI or...

C++ was and is a _follower_.  That is not necessarily a bad thing, but
it is anything _but_ innovative.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Tore Lund]

Edward de Jong wrote:
>
> (snip)
> It took 12 programmers, myself included, one entire year, and about 
> 100,000 lines of code to surpass the work of just one man,
> working in macro assembler.  But let me tell you, macro assemblers are
> very clever tools; they can do amazing things; you can have multiple
> levels of macros, which are effectively miniature compilers, which 
> output executable code, with the lowest possible overhead.  
>
> In the hands of a genius, assembler can do amazing things in tiny 
> spaces;
> (snip)

This is very interesting. But tell us, Edward, is this is a mode of
programming that is confined to geniuses only? I get the impression that
you are saying something along those lines. Just about everything
technical or scientific that has been invented by geniuses can be
emulated by the normally talented engineer once it has been properly
understood. What makes macro programming so special?

I have been doing assembly for 12 years and have often heard about the
wonders of macro programming, but I have never actually *seen* those
wonders at work. Are you able to illustrate this mode of programming
somehow?

I realize that you are not trying to sell us macro programming as a
style to be emulated. But you have actually seen a very successful
system of this sort, so you might know pointers to examples or
literature or whatever.

I hope I don't sound skeptical or sarcastic. We know for sure that some
programmers are far better designers than others, and it would be of
considerable interest to get to know their modus operandi. It may turn
out to be as futile as trying to map the mental processes of great
composers or poets, but we could still make a try.

If it took 12 years to surpass the work of just one man, then what you
call multi-level programming has got to be something more tangible than
sheer, formless "genius".


Tore
-- 
Tore Lund <tl001@sn.no>

Re: What is wrong with OO ?

[Tore Lund]

Tore Lund wrote:
> 
> If it took 12 years to surpass the work of just one man, etc.

I'm sorry. Please read 12 programmers, not 12 years.
Too much fireworks outside for concentration. Happy New Year!
-- 
Tore Lund <tl001@sn.no>

Re: What is wrong with OO ?

[Ell]

Nigel Tzeng (nigel@access4.digex.net) wrote:
: In article <5a9r1k$e74@news4.digex.net>, Ell <ell@access1.digex.net> wrote:
: 
: [snip]
: 
: >Because Boeing had a super diagram doesn't mean it's highest level was
: >predicated on a single, or even specific set of, technology, i.e. on one
: >or more specific languages, or distribution technologies in our case.
 
: Actually I think that one can make the case that the highest level was
: predicated on a specific set of technology.  I'm going to speculate a
: little here since I know virtually nothing about the actual 777 design
: but here goes:
: 
: Say they started with a specific weight goal for the airframe or they
: couldn't get the performance they wanted out of the aircraft.  They
: thought they could meet this goal through the use of composites.  The
: choice of composites then bounds the high level airframe architecture
: because of what you can and cannot do with composites (compare to say
: conventional airframes made of metal).

I think we see the top level design in different ways.  I see it as a
logical thing with no commitment to a technology.  In the above you are
positing the use of "composites" up front.  My top level design would only
incorporate the desire to meet a specific weight goal without commiting to
one technology or the other.  I would leave it to lower levels to figure
out how to meet the weight goal.  If the lower levels found the goal
impossible they would give feedback to the top level and we would make the
requisite changes to the top level.  

So my approach, rather than squeezing out or constraining the
implementors, in fact gives them greater lattitude.  If we had determined
at the top level what the technology was to be, we would have restricted
options both at the top and at lower levels.  If you haven't already you
might check out Constantine's end column in this or last month's Object
magazine.  He talks about the goodness of "delaying" implementation
decisions as long as possible. 

Elliott

Re: What is wrong with OO ?

[Ell]

clovis@wartech.com wrote:
: In <5aa73v$p14@news3.digex.net>, ell@access5.digex.net (Ell) writes:
: 
: >I find the key aspects of C++ to be within the parameters of the
: >_progressive_ OO paradigm and practice.  In many ways C++ has led and
: >still leads in the expression and implementation of many significantly
: >useful OO concepts.
: 
: I concur with this, but think it does not go far enough.
: 
: ANY language, up to and including direct object code, is just fine.
: 
: The real problem is personal discipline -- designing completely before coding.
: 
: Wirth's paradigm is STILL at the basis of all good design and coding practice.
: 
: Data Structures + Algorithms = Programs.
: 
: This whole thread somehow ignors that basic reality.  The most aggressive 
: paradigm still respects Wirth's basic rule.  One MUST have structured data (otherwise
: exact access is impossible, and all algorithms produce garbage).  One MUST have
: algorithms -- otherwise, the data is nothing more than an electronic, fixed book
: which one can't even access reliably.
: 
: Any language which provides both these features is sufficient.
: 
: All we're really discussing is HOW to provide data structures and algorithms.
: 
: There isn't a real paradigm shift until the basic model itself changes.  All we're
: really talking about is how to represent the data structures and algorithms, that is,
: how to go about implementing them.

I think the proper essence of OO is about programming the collaboration of
classes/objects.  Far different from being focused on algorithms. 

Elliott

Re: What is wrong with OO ?

[Ell]

In this thread someone said assembler was "real" and higher level
languages were abstractions above that.  I always thought voltage
states/levels were real and that assembler was an abstraction of voltage
states/levels. 

Elliott

Re: What is wrong with OO ?

[Nick Thurn]

Robert C. Martin wrote:
> 
> In article <5aae85$ad8@masters0.InterNex.Net>, clovis@wartech.com wrote:
> 
> > All we're really discussing is HOW to provide data structures and algorithms.
> >
> > There isn't a real paradigm shift until the basic model itself changes.
> > All we're really talking about is how to represent the data structures and
> > algorithms, that is, how to go about implementing them.
> 
> The paradigm shift in OO comes about because of some very different
> separation strategies.  Prior to OO, data was accessed from data structures.
> Any algorithm that needed that data had knowledge of the data structures.
> In OO, this changes.  Some algorithms are closely associated with
> a data structure and have intimate knowledge of it.  However, other algorithms,
> that use the data within the data structure have no knowledge of the data
> structure.  They are isolated from the data through abstract interfaces.
> When the data structure changes, these algorithms do not change.  Moreover, these
> algorithms can make use of many different kinds of data structures without
> knowing it.
> 
> Thus there is a fundemental change.  We still create data structures, and
> we still create algorithms.  But in OO we also create interfaces that
> separate some algorithms from some data structures.  Then we must decide which
> algorithms know about which data structures, and which should be kept separate.
> It is that decision that is called OOD.
> 
> If you don't believe that this is a fundemental paradigm shift, then consider
> that this simple trick of separating algorithms and data structures creates
> an equation that is quite different from Wirth's:
> 
> program = Interfaces(algorithms,data_structures)
> 
> Where the algorithms and data_structures are independent variables that
> have no knowledge of each other, and the interfaces are the mapping functions
> that bind the two together to create certain programs.
> 

This may be true in generic programming but I think Frank is right 
in general. Encapsulation removes the unknown usage problem from a 
data structure, you can do this in many languages via opaque types. 
So you can control access and hence algorithms outside of OOP. The 
fact that this was not done more often is more an indication of 
sloppyness than a paradigm problem.

Most classes I encounter *don't* separate algorithm from data 
structure. Currently OOP tends to look like:

program = (algorithm1+data_struct1) + (algoithm2+data_struct2) + ...
data_structX = algorithm+data_struct 
	     | data_struct

So OOP adds a level of organisation over and above the fundamental
activity. I don't think the fundamental activity has changed. Now 
the fact that 98% of *time* is spent in the organisation stage is
another issue :-)

Happy New Year,
Nick (my opinions only)

Re: What is wrong with OO ?

[Ell]

Bob Jarvis (nospam@thankyou.net) wrote:
: As I recall it, the Von Neumann architecture's principal differentiating
: point from
: others was that in the VN scheme there is only a single memory space; both
: instructions and data were/are resident in the same memory, and instructions
: could be manipulated using the same instructions that are used to manipulate
: data.  In the principle alternative architecture (i.e. the only one I can 
: remember :),
: known as the Harvard architecture, two completely separate memory spaces
: are maintained - one for instructions and another for data.

These are my understanding of the concepts also.  The correct definition
of Von Neuman architecture here is related to but different from how most
others in this thread are defining it. 

Elliott

Re: What is wrong with OO ?

[Tom Bushell]

On Tue, 31 Dec 1996 09:28:08 -0600, rmartin@oma.com (Robert C. Martin)
wrote:

>This is undoubtedly true.  As engineers we need a CAE system that combines
>the CASE tool, editor, compiler, documentation tool, debugger, test plan
>generator, simulator, etc into a single seamless facility.  We should be 
>able to browse through our design diagrams, focusing into certain points,
>double clicking on an adornment or icon to bring up a stretch of "source code"
>which we could edit.  Then build and debug in the same environment.

Exactly.  And since we're dreaming, let's take it a bit further.  You
should be able to edit the system at whatever level of abstraction you
are viewing it.  For example, adding a new argument to a method call
would propagate through the whole system automatically, or create a
map of errors where more detailed fixing was required.

If the system was runnable before the high level change, and nothing
was broken by the change, it should still run - immediately!


>Of course, after a little practice, the notion of turning right immediately
>translates into the corresponding pressures and velocity profiles for the
>stick and the pedals.  No thought is required.  The appropriate responses become
>wired into the brain.  

Seems to me this kind of eye/body type of learning comes much more
naturally to humans than textual "book learning" does.  Presumably the
parts of our brain that deal with written language evolved much more
recently, and are less advanced.


>So it is with any computer language.  Once you have mastered it, its use
>becomes wired in, and the struggle with the layer between design and 
>implementation disappears.

Very true.  But my experience has been that "wiring in" to certain
languages is easier.  Smalltalk especially, Forth, and to a certain
extent Visual BASIC seem much more natural and comfortable than C/C++,
at least for me.  I believe this is because they were concieved as
_personal_ computer languages, so are highly interactive and open.
C/C++ are FORTRAN descendants, which evolved in a mainframe batch
environment.  Of course, the supporting development environment can
have a very large effect too - I'll take a GUI over a command line any
day.

It seems much easier to get into a state of flow when using these
languages - you just code and test, and everything seems to work.  I
can hardly ever achieve this happy state in C, even though it's one of
my most familiar languages - it's just too much like work.

Interestingly enough, this can often be done without a lot of up front
design, and rarely results in a mess.  

Many years ago, I read a very short article by a PC game developer.
He talked about programming as "jamming", using the term the same way
musicians do.  I thought it was a very good analogy - implies a very
smooth and natural process of creation.

IMO, the more "sensual" (ie see/hear/smell/touch/taste) we can make
our development tools, the more efficient and creative the development
process will become.  Visual programming is just a big step in this
direction.

-Tom


----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Tom Bushell]

On 31 Dec 1996 06:54:51 GMT, clovis@wartech.com wrote:

>You're quite right.  Tansel is acting like quite a pretender on this one, and he 
>obviously doesn't know what either a Von Neumann machine is, or what a Turing
>machine is.  

Let's wait until he gets his article together before slagging him, eh?
Although he may be guilty of a bit of hyperbole, I have a hunch he may
be on to something - time will tell.


>A Von Neumann "machine" is really a recommended architecture,
>and really, there aren't many of them.  They feature regular instruction sets,
>with zero duplication of function, and all operations being orthogonal.  

As other postings have said, my understanding was that shared program
and data memory is the defining characteristic.


>None of this is really rocket science.  And it's never ceased to amaze me how many
>of the "hip" guys can't even define the basic terms.

Seems to be a problem with the field in general, not just a few hip
guys.  Terminology and concepts havn't stabilized.  Witness your own
statement about the "true" meaning of von Neumann architecture,
extended discussions about what OO "really" means, and so on.


>Assembler will ALWAYS be the most efficient language.  The more you abstract the
>problem, the more you "generalize" the solution to a given problem, the more you
>necessarily give up in efficiency.

Agreed, if you define "efficency" as "doing the most computation with
the fewest instructions".

>C takes a minimal 3x hit on integer arithmetic,
>10x on more complex stuff; and OO, because of the overhead interpreting where
>to send things, is 10x on top of that.

Saying that there is a 10x hit for using OO is a pretty sweeping
statement.  May be correct for a Smalltalk message send, which is late
bound.  But an early bound C++ call just requires one more indirect
jump through the vtable, so the performance hit is more like 3
_percent_ according to what I've read, which is trivial.


>I personally use all three in Smalltalk applications which involve a variety of
>disciplines.  Smalltalk handles the GUI, but engines in C and ASM are also required
>in some cases.  Any realtime requirements point to ASM, and any number crunching
>points to C most of the time (Assembler if the computation must be made in
>realtime, and be interruptable in mid-stream).

I agree 100%.  The huge reduction in development time for the 90% of
the system that doesn't need speed more than repays the extra effort
and complexity of a multi language solution.


>Smalltalk itself is not entirely Smalltalk.  It contains both procedural (often C), and
>frequently ASM routines at the kernel since no general purpose machine ever
>built comprehends objects -- all the underlying hardware knows about is basic
>arithmetic, compares, and jumps/branches based on flags settings.

As an aside, many Forth compilers are written in Forth.  The Forth
stack based virtual machine is coded using the Forth postfix assembler
for the target machine.  The result is a programming system that is
completely able to regenerate itself (wasn't that one of the
definitions of a von Neumann machine?)


>ASM is REALITY.
>
>>In this thread someone said assembler was "real" and higher level
>>languages were abstractions above that.  I always thought voltage
>>states/levels were real and that assembler was an abstraction of voltage
>>states/levels. 
>
>Elliott

Have to agree with Elliot on this one - assembler is just a textual
abstraction for the binary numbers that are computer instructions.
And the binary numbers are abstractions for voltages, and the voltages
are...it's elephants all the way down.

If you are saying assembler is the lowest abstraction we can program
in under normal circumstances, I agree.  (Although I wrote a Forth in
hex on a KIM-1, back in the bad old days.)


>It's a tradeoff, and if we want to represent ourselves as real computer scientists,
>and real computing professionals, it behooves us to be able to explain in clear
>terms why one paradigm is better, where it is better, and the details of why it is
>better AT A GIVEN TASK.

I agree, but IMO the field has a lot more maturing to do before this
will happen.


>We can get by without smalltalk if we must.  If we try to do without Von Neumann,
>there isn't such a thing as a working computer.

True for current computers, and one of the reasons I'm a little
skeptical about what I _think_ Tansel is saying  - the implication
that we need a whole new hardware architecture before we can benefit
from OO.

But he claims von Neumann himself was dissatisfied, and if there is a
much better architecture for CPUs, we can assume it will be built and
commercialized - eventually.

-Tom


----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: What is wrong with OO ?

[Jon S Anthony]

In article <rmartin-3112960919160001@pool11-019.wwa.com> rmartin@oma.com (Robert C. Martin) writes:

> In article <5aa0eo$thd@krusty.irvine.com>, adam@irvine.com (Adam
> Beneschan) wrote:
> 
> > A number of times in this thread, OO has been compared to "von Neumann
> > machines" as if they are opposing paradigms.  This is confusing to
> > me--could someone explain it?  My understanding of von Neumann
> > machines is that they execute one statement at a time, in order.  Most
> > of the high-level languages I've seen do the same thing, whether or
> > not they're OO languages.  It seems to me that if (as implied by
> > earlier posts in this thread) the "von Neumann" paradigm is the
> > problem, then the solution is something like Backus' FP or Prolog or
> > Haskell or dataflow--not OO, which seems to me to have nothing to do
> > with whether the von Neumann model is being followed or not.  Am I
> > missing something?
> 
> Von Neumann invented the notion that the computer program could be
> stored in the memory of the computer (rather than wired in through a 
> patch panel).  At least that is my recollection.

I agree.  But for some reason, in this thread at least, people seem to
be using it as some sort of synonym for "procedural".

> A "Von Neumann Machine" is something different altogether.  It is a
> machine that knows how to make copies of itself.  Humans are Von
> Neumann machines.

This too seems to be the most appropriate use of the term in various
bits of the literature...

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Tim Ottinger]

Ell wrote:
> 
> I think we see the top level design in different ways.  I see it as a
> logical thing with no commitment to a technology.  In the above you are
> positing the use of "composites" up front.  My top level design would only
> incorporate the desire to meet a specific weight goal without commiting to
> one technology or the other.  I would leave it to lower levels to figure
> out how to meet the weight goal.  If the lower levels found the goal
> impossible they would give feedback to the top level and we would make the
> requisite changes to the top level.

In an ideal world (for developers, not buyers), where no requirements 
were in the contract until after all details were worked out, this would
be great. 

It's not to say that this can never work, but imagine what happens when
the "top level" guys commit to a given weight, but don't understand that
no existing materials will allow the goal to be met.  They can really 
set up a no-win situation for both the lower-level guys and the
customer.

I guess that's my problem with waterfall, rather than "what's wrong with
OO": that the contracts sometimes specify un-buildable systems, and
they're
signed into law before any engineers have worked out that it is or is
not
possible in the cost and time constraints given.

Now, this has gone horribly off-charter, and wandered back into the 
well-swam waters of whether, during OO, one should steer the
architecture
during implementation.  It's a topic worthy of discussion, and we've
already done that.

-- 
Tim
******************************************************************** 
 In some sense, all of life is design.  The way we pick our friends, 
 the way we plant a garden, and the way we choose software is all 
 design. Sometimes we do things by habit, other times by carefully 
 weighing the pros and cons, and sometimes we make experiments.  
                                            -- Ralph Johnson --

Re: What is wrong with OO ?

[Robert C. Martin]

In article <JSA.97Jan1181506@alexandria>, jsa@alexandria (Jon S Anthony) wrote:

> 
> C++ was and is a _follower_.  That is not necessarily a bad thing, but
> it is anything _but_ innovative.
> 

WRT technology I agree with you.  But C++ *does* show innovation in a
completely different vein.  C++ is one of the first of the industrial OO
languages that was created for the engineer instead of for the paradigm.  
C++ was not created to be "pure" or "right" or "correct".  It was created
to be *used*.  And in that regard it represents an innovation wrt industrial
OO languages.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[David L. Shang]

In article <32CAF83E.323A@acm.org> Ian Joyner <i.joyner@acm.org> writes:

> 1) C++ has added nothing new that has not been pioneered elsewhere.
> (Classes from Simula, multiple inheritance, genericty were all
> around before C++ adopted them)
> 

There is nothing wrong to borrow good things from others. But it is
wrong to borrow things good to others but bad to self.

> 2) Most things that are different in C++ to other languages are to
> patch up the earlier deficiencies of C and C++. For example
> type casts, etc.

When things are added, patches must be made also. The things added
is not good to self.

A language should not continue to add things with patches.

David Shang

Re: What is wrong with OO ?

[Bill Hunter]

"Fields are the dreams stuff is made of ..."

>Quantum probabilities and wave functions are real.
>
>Reality is a perceptual convenience.
>

Re: What is wrong with OO ?

[Ian Joyner]

Ell wrote:
> 
> Ian Joyner (i.joyner@acm.org) wrote:

> : And people can still drive model T Fords, and fly WWI planes.
> 
> I find the key aspects of C++ to be within the parameters of the
> _progressive_ OO paradigm and practice.  In many ways C++ has led and
> still leads in the expression and implementation of many significantly
> useful OO concepts.

1) C++ has added nothing new that has not been pioneered elsewhere.
(Classes from Simula, multiple inheritance, genericty were all
around before C++ adopted them)

2) Most things that are different in C++ to other languages are to
patch up the earlier deficiencies of C and C++. For example
type casts, etc.

This is hardly progressive or leading, and I don't think most C++
proponents would claim otherwise!
------------------------------------------------------------------------
Ian Joyner       | "for when lenity and cruelty play | All opinions are
Internet email:  |  for a kingdom, the gentler       | personal and are
i.joyner@acm.org |  gamester is the soonest winner"  | not Unisys
                 |       William Shakespeare Henry V | official comment
------------------------------------------------------------------------

Re: What is wrong with OO ?

[Thaddeus L. Olczyk]

rmartin@oma.com (Robert C. Martin) wrote:

>In article <32C88BE0.7F2B@acm.org>, i.joyner@acm.org wrote:

>This is undoubtedly true.  As engineers we need a CAE system that combines
>the CASE tool, editor, compiler, documentation tool, debugger, test plan
>generator, simulator, etc into a single seamless facility.  We should be 
>able to browse through our design diagrams, focusing into certain points,
>double clicking on an adornment or icon to bring up a stretch of "source code"
>which we could edit.  Then build and debug in the same environment.

>Such a system maintain traceability between requirements, use cases, design
>artifacts and modules.  It would maintain lists of programmer and analysts
>notes that were germane to each other.  It would facilitate communcations
>between engineers working on the project regardless of their location.  It would
>facilitate configuration management and version control.  It would facilitat
>project management.

>No such tool exists today.  I think it will be a long time before such
>a tool does exist.  But I can dream.

What? You mean emacs can't handle all this ? :)
---------------------------------------------
Thaddeus L. Olczyk

Net boy, net girl
Send your impulse 'round the world
Put your message in a modem
And throw it in the Cyber Sea

Re: What is wrong with OO ?

[Robert C. Martin]

In article <JSA.96Dec31135018@alexandria>, jsa@alexandria (Jon S Anthony) wrote:

> In article <5aa73v$p14@news3.digex.net> ell@access5.digex.net (Ell) writes:
> 
> > Ian Joyner (i.joyner@acm.org) wrote:
> > : Ell wrote:
> > : > 
> > : > Ian Joyner (i.joyner@acm.org) wrote:
> > : > 
> > : > : What made me think of this was that Bill Gates stated in his book that
> > : > : Boeng designed the entire 777 aircraft using one gigantic electronic
> > : > : document! Physical engineering disciplines have made good use of
> > : > : computing technology, it's about time software engineers followed
> > : > : the same path... better and more productive languages and
environments,
> > : > : and stop defending archaic 25 year old languages from another era.
> >  
> > : > I find some 25 year languages like C++ very useful even today.  A lot of
> > : > following a good OO paradigm is in how tools are used and approached.
> >  
> > : And people can still drive model T Fords, and fly WWI planes. 
> > 
> > I find the key aspects of C++ to be within the parameters of the
> > _progressive_ OO paradigm and practice.  In many ways C++ has led and
> > still leads in the expression and implementation of many significantly
> > useful OO concepts.
> 
> With respect to this "led/leads" claim: Such as?????  I can't think of
> _any_ where this is true.  Though I can think of at least one
> important _implementation_ aspect where this seems to be true.
> 
C++ is not a leader from the standpoint of theory.  C++ does not present
an embodiment of any new technical theory.  I can't think of anything
within C++ that was not tried in some other language first.

What C++ *does* do is combine these features into a language that is
palatable to and usable by a very large cohort of engineers.  C++ leads
in terms of acceptability.  It presents the OO concepts in a way that is
acceptable the the majority of users.

It would appear that Java is following suit, and is acceptable to a large
majority of users.  Indeed it may be that Java will supplant C++ in several
industrial domains.  I think however, that there are several domains (e.g.
hard real time systems) in which C++ will remain predominant.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Dale Pontius]

In article <32CBC8FC.7079@ix.netcom.com>,
        Mike Anderson <verx@ix.netcom.com> writes:
> Ell wrote:
>>
>> In this thread someone said assembler was "real" and higher level
>> languages were abstractions above that.  I always thought voltage
>> states/levels were real and that assembler was an abstraction of voltage
>> states/levels.
>>
>> Elliott
>
> I've never heard this one before.  It's great!
> ....Mike

Nah!

Quantum probabilities and wave functions are real.

Reality is a perceptual convenience.

Dale Pontius
(NOT speaking for IBM)

Re: What is wrong with OO ?

[Mike Anderson]

Ell wrote:
> 
> In this thread someone said assembler was "real" and higher level
> languages were abstractions above that.  I always thought voltage
> states/levels were real and that assembler was an abstraction of voltage
> states/levels.
> 
> Elliott

I've never heard this one before.  It's great!
....Mike

Re: What is wrong with OO ?

[Eirik Mangseth]

Robert C. Martin wrote:
> 
> In article <JSA.97Jan1181506@alexandria>, jsa@alexandria (Jon S Anthony) wrote:
> 
> >
> > C++ was and is a _follower_.  That is not necessarily a bad thing, but
> > it is anything _but_ innovative.
> >
> 
> WRT technology I agree with you.  But C++ *does* show innovation in a
> completely different vein.  C++ is one of the first of the industrial OO
> languages that was created for the engineer instead of for the paradigm.
> C++ was not created to be "pure" or "right" or "correct".  It was created
> to be *used*.  And in that regard it represents an innovation wrt industrial
> OO languages.
> 
> --
> Robert C. Martin    | Design Consulting   | Training courses offered:
> Object Mentor       | rmartin@oma.com     |   Object Oriented Design
> 14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
> Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
> 
> "One of the great commandments of science is:
>     'Mistrust arguments from authority.'" -- Carl Sagan

Sorry, but you are wrong. This is one of the many myths that surrounds
C++. No engineer I know would use any tool pertaining to his or her
profession that was as badly designed and implemented as C++. "Pure"
pragmatism is not an option with respect to language design, something
even Mr. Stroustrup himself acknowledges.

If any language was designed for engineers (software engineers that is),
it must be Eiffel.

/Eirik Mangseth/emangset@online.no/United Consultants, Oslo Office,
Norway/

-All opinions expressed are my own and does not necessarily reflect the
views of my employer.

Re: What is wrong with OO O X g

[Greg Comeau]

In article <32CCE4ED.6A21@online.no> emangset@online.no writes:
>Robert C. Martin wrote:
>> 
>> In article <JSA.97Jan1181506@alexandria>, jsa@alexandria (Jon S Anthony) wrote:
>> 
>> >
>> > C++ was and is a _follower_.  That is not necessarily a bad thing, but
>> > it is anything _but_ innovative.
>> >
>> 
>> WRT technology I agree with you.  But C++ *does* show innovation in a
>> completely different vein.  C++ is one of the first of the industrial OO
>> languages that was created for the engineer instead of for the paradigm.
>> C++ was not created to be "pure" or "right" or "correct".  It was created
>> to be *used*.  And in that regard it represents an innovation wrt industrial
>> OO languages.
>> 
>> --
>> Robert C. Martin    | Design Consulting   | Training courses offered:
>> Object Mentor       | rmartin@oma.com     |   Object Oriented Design
>> 14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
>> Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
>> 
>> "One of the great commandments of science is:
>>     'Mistrust arguments from authority.'" -- Carl Sagan
>
>Sorry, but you are wrong. This is one of the many myths that surrounds
>C++. No engineer I know would use any tool pertaining to his or her
>profession that was as badly designed and implemented as C++. "Pure"
>pragmatism is not an option with respect to language design, something
>even Mr. Stroustrup himself acknowledges.

I have not a clue what you are talking about.  Indeed, the beauty
of C++ is that it is a hybrid and that it does not lock you into one
particular thing.  Robert is indeed correct about its flexibility
and avoidance of so-called political correctness.  Since when are
pragmatics not important in design, decisions, engineering?

You mention myths but only defend it by claiming something closing
into the notion of outrageous that you know of no engineer who
programs in C++.  You say he is wrong -- then counter his 1/2 dozen or
so claims.  Re Stroustrup, I'm not clear what you claim he acknowledges,
so it would also be nice to provide the source for any such information.

- Greg
-- 
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421

Re: What is wrong with OO ?

[Jon S Anthony]

In article <rmartin-0201971129150001@pool11-018.wwa.com> rmartin@oma.com (Robert C. Martin) writes:

> In article <JSA.97Jan1181506@alexandria>, jsa@alexandria (Jon S Anthony) wrote:
> 
> > 
> > C++ was and is a _follower_.  That is not necessarily a bad thing, but
> > it is anything _but_ innovative.
> > 
> 
> WRT technology I agree with you.  But C++ *does* show innovation in a
> completely different vein.  C++ is one of the first of the industrial OO
> languages that was created for the engineer instead of for the paradigm.  
> C++ was not created to be "pure" or "right" or "correct".  It was created
> to be *used*.  And in that regard it represents an innovation wrt industrial
> OO languages.

Oh, I don't know.  I think C++ was created simply because BS was
saddled with C (at ATT) and wanted _something_ that had a least _some_
abstraction capabilities in it.  Voila.  C++.  Whether it is any more
"usable" than several other options is highly open to question.  And
in fact, in general I would say the answer is "no".

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Matt Austern]

jsa@alexandria (Jon S Anthony) writes:

> Oh, I don't know.  I think C++ was created simply because BS was
> saddled with C (at ATT) and wanted _something_ that had a least _some_
> abstraction capabilities in it.  Voila.  C++.  Whether it is any more
> "usable" than several other options is highly open to question.  And
> in fact, in general I would say the answer is "no".

It's not necessary to speculate on why Bjarne Stroustrup made the
design decisions that he did: he discusses them, in a fair amount
of detail, in _The Design and Evolution of C++_.

I probably shouldn't try to summarize an entire book in a single
sentence.  One thing he makes very clear in his book, though, is that
he was trying to create a language that, like C, made it possible to
write low-level programs, but that also, like Simula, included
high-level abstraction facilities.  

This combination is, if not unique to C++, at least rare.  It's also
quite clear that it was a design goal from the very beginning.

Re: What is wrong with OO ?

[markj]

In <5a29dv$hb2@masters0.InterNex.Net>, clovis@wartech.com writes:
>In <5a0niaINNlda@topdog.cs.umbc.edu>, jur@cs.umbc.edu (Jacqueline U. Robertson) writes:
>
>>Well, I was with you to some extent until you got here.  Code bloat is a 
>>simple trade-off for increased maintainability and extensibility.  Quite
>>simply, it's easier to maintain and extend a decently written application
>>in high level code than it is to maintain and extend a decently written
>>application in assembler. 

I agree.

>>The trade-off is that the assembly level application was more compact (both in disk space and in memory usage) - but harder to extend
>>and modify.  There's a reason that assembly level development is limited
>>to small areas (such as in the limited resource milieu of deep space probes) -
>>the trade off in favor of high level languages has generally been worth it,
>>as increased disk space and increased amounts of RAM are economically cheaper
>>than the 'more efficient' assembler writing. 

>This is also wrong. The reason that "paradigms" proliferate is obvious; people, and
>managers in particular, are trying to get something for nothing.  Compared to
>procedural languages, it takes 3 lines of assembler to equal one line of, say,
>PASCAL stuff.  And it generally takes 5 lines of PASCAL to equal a line of Smalltalk
>in a properly constructed hirearchy.  Any operation one needs to do should not
>be a series of lines, but a single method, and a single message sent to the instance.
>There are exceptions, but with the compactness come other problems.

I think you people are forgetting about the portability issue. I would always
write in C rather than assembler because I can run the same code on many
different CPU's.

Also I'm lazy. Why should I bother to learn N assembly languages when I only
need to learn 1 high level language, that is, C.

Cheers,

+------------------------------------+---------------------------------------+
| EMBEDDED SYSTEMS SOFTWARE ENGINEER | Specialist In:                        |
| Mark Jordan    TC, NZCE, BE, MIEEE |   - DSP Applications                  |
| Top Quality Work, Reasonable Rates |   - Microprocessor Applications       |
|      markj@netaccess.co.nz         |   - Reusable Software Libraries       |
+------------------------------------+---------------------------------------+

Re: What is wrong with OO ?

[Ell]

Ian Joyner (i.joyner@acm.org) wrote:
: Ell wrote:
: > 
: > Ian Joyner (i.joyner@acm.org) wrote:
: > : And people can still drive model T Fords, and fly WWI planes.
 
Ell
: > I find the key aspects of C++ to be within the parameters of the
: > _progressive_ OO paradigm and practice.  In many ways C++ has led and
: > still leads in the expression and implementation of many significantly
: > useful OO concepts.
 
Ell
<<< Led (first or second) wrt the OO paradigm: Private data members,
static resolution of overloaded functions, protected members, and multiple
inheritance. Correct me if I'm wrong.  Remember this is wrt the early
'80's.>>>

: 1) C++ has added nothing new that has not been pioneered elsewhere.
: (Classes from Simula, multiple inheritance, genericty were all
: around before C++ adopted them)

You only addressed one of my points (MI) and would you please tell me
which OOPLs had MI before C++.

Elliott

Re: What is wrong with OO ?

[Jon S Anthony]

In article <rmartin-0201971102070001@pool11-018.wwa.com> rmartin@oma.com (Robert C. Martin) writes:

> In article <JSA.96Dec31135018@alexandria>, jsa@alexandria (Jon S Anthony) wrote:
>...
> > With respect to this "led/leads" claim: Such as?????  I can't think of
> > _any_ where this is true.  Though I can think of at least one
> > important _implementation_ aspect where this seems to be true.
> > 
> C++ is not a leader from the standpoint of theory.  C++ does not present
> an embodiment of any new technical theory.  I can't think of anything
> within C++ that was not tried in some other language first.

Right.


> What C++ *does* do is combine these features into a language that is
> palatable to and usable by a very large cohort of engineers.  C++ leads
> in terms of acceptability.  It presents the OO concepts in a way that is
> acceptable the the majority of users.

I can buy this too.


> It would appear that Java is following suit, and is acceptable to a large
> majority of users.  Indeed it may be that Java will supplant C++ in several

Most things are in this position.  However, I would cast my self with
those that see Java as having done this rather better than C++.


> industrial domains.  I think however, that there are several domains (e.g.
> hard real time systems) in which C++ will remain predominant.

Is there any truth to this????  I didn't think C++ was even much of a
player in this particular arena.  Certainly it is not as "dominant"
here as say C (or probably Ada for that matter).

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Jean-Marc Jezequel]

In article <5ahqo6$gk6@news4.digex.net>, ell@access2.digex.net (Ell) writes:

><<< Led (first or second) wrt the OO paradigm: Private data members,
>static resolution of overloaded functions, protected members, and multiple
>inheritance. Correct me if I'm wrong.  Remember this is wrt the early
>'80's.>>>
>
>: 1) C++ has added nothing new that has not been pioneered elsewhere.
>: (Classes from Simula, multiple inheritance, genericty, were all
>: around before C++ adopted them)
>
>You only addressed one of my points (MI) and would you please tell me
>which OOPLs had MI before C++.

Eiffel has multiple inheritance, genericity, exception handling, GC etc. since 1986.

For the record:
Smalltalk has "Private data members", GC and all OO mechanisms at least since 1980 (in facts well before).

Ada has static typing, information hiding, genericity, exception handling and 
"static resolution of overloaded functions" officialy since 1983, but these 
were there in the proposals long before.


But as someone else has said, there is nothing wrong in using other's good ideas,
as long as they are credited.

-- 
Jean-Marc Jezequel               Tel : +33 2 99847192         
IRISA/CNRS                       Fax : +33 2 99847171         
Campus de Beaulieu               e-mail : jezequel@irisa.fr 
F-35042 RENNES (FRANCE)          http://www.irisa.fr/pampa/PROF/jmj.html

Re: What is wrong with OO ?

[Eirik Mangseth]

Jean-Marc Jezequel wrote:
> 
> In article <5ahqo6$gk6@news4.digex.net>, ell@access2.digex.net (Ell) writes:
> 
> ><<< Led (first or second) wrt the OO paradigm: Private data members,
> >static resolution of overloaded functions, protected members, and multiple
> >inheritance. Correct me if I'm wrong.  Remember this is wrt the early
> >'80's.>>>
> >
> >: 1) C++ has added nothing new that has not been pioneered elsewhere.
> >: (Classes from Simula, multiple inheritance, genericty, were all
> >: around before C++ adopted them)
> >
> >You only addressed one of my points (MI) and would you please tell me
> >which OOPLs had MI before C++.
> 
> Eiffel has multiple inheritance, genericity, exception handling, GC etc. since 1986.
> 
> For the record:
> Smalltalk has "Private data members", GC and all OO mechanisms at least since 1980 (in facts well before).
> 
> Ada has static typing, information hiding, genericity, exception handling and
> "static resolution of overloaded functions" officialy since 1983, but these
> were there in the proposals long before.
> 
> But as someone else has said, there is nothing wrong in using other's good ideas,
> as long as they are credited.
> 
> --
> Jean-Marc Jezequel               Tel : +33 2 99847192
> IRISA/CNRS                       Fax : +33 2 99847171
> Campus de Beaulieu               e-mail : jezequel@irisa.fr
> F-35042 RENNES (FRANCE)          http://www.irisa.fr/pampa/PROF/jmj.html

And as Tom Peters once said:

"There's nothing wrong with copying as long as the copy is an
improvement on the original". 

Now, is C++ an improvement of the original ideas of OO?

Re: What is wrong with OO ?

[Robert C. Martin]

In article <JSA.97Jan2200948@alexandria>, jsa@alexandria (Jon S Anthony) wrote:

> In article <rmartin-0201971102070001@pool11-018.wwa.com> rmartin@oma.com
(Robert C. Martin) writes:
> 
> > I think however, that there are several domains (e.g.
> > hard real time systems) in which C++ will remain predominant.
> 
> Is there any truth to this????  I didn't think C++ was even much of a
> player in this particular arena.  Certainly it is not as "dominant"
> here as say C (or probably Ada for that matter).

Actually, I have several very large (i.e. Fortune 100) customers that are
making 
use of C++ in hard real time embedded systems for major projects.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Natan]

Mark Jordan wrote:
> Also I'm lazy. Why should I bother to learn N assembly languages when I only
> need to learn 1 high level language, that is, C.

Since when is C a high level language? It is very easy to convert C-code
to assembler. That's why some call C portable assembler.

BTW I don't think discussions about assembler should be posted to
OO-newsgroups (okay I'm guilty too).

Re: OO, C++, and something much better!

[Pieter Schoenmakers]

In article <32ce7009.280817694@news.zip.com.au> skaller@maxtal.com.au (John (Max) Skaller) writes:

   Is C++ innovative? Of course it is. It was one of the FIRST mainsteam
   language to provide ...

Shouldn't that be `first MAINSTREAM'?  --Tiggr

Re: What is wrong with OO ?

[Valerie Torres]

Jon S Anthony (jsa@alexandria) writes:

 > In article <5acjtn$5uj@news3.digex.net> ell@access1.digex.net (Ell) writes:
 > 
 > > Jon S Anthony (jsa@alexandria) wrote:
 > > : With respect to this "led/leads" claim: Such as?????  I can't think of
 > > : _any_ where this is true.  Though I can think of at least one
 > > : important _implementation_ aspect where this seems to be true.
 > > 
 > > Led (first or second) wrt the OO paradigm: Private data members, static
 > > resolution of overloaded functions, protected members, and multiple
 > > inheritance. Correct me if I'm wrong.  Remember this is wrt the early
 > > '80's.
 > 
 > Recheck your facts.  Led/lead means "first" to me and certainly
 > carries that connotation around with it even if you want to pull a
 > Humpty Dumpty.

It is very important getting the fact straight on a topic like this where
many seem keen on confusing the question "is C++ innovative and if so
compared to what and in which ways?" with "is C++ my favorite programming
language?"  or or even "is C++ perfect?" (my opinion: it is in some ways,
it is for many things, it is not).

The origins of C++ and the reasoning behind the various design decisions
are well documented:

	Bjarne Stroustrup: A History of C++: 1979-1991.
	Proc ACM History of Programming Languages conference (HOPL-2).
	ACM Sigplan Notices. Vol 28 No 3, pp 271-298. March 1993.
	Also in History of Programming languages
	(editors T.J.Begin and R.G.Gibson)
	Addison-Wesley, ISBN 1-201-89502-1. 1996.

	Bjarne Stroustrup: The Design and Evolution of C++.
	Addison-Wesley. 1994. ISBN 0-201-54330-3.

Note that the paper went through HOPL2's strict peer review process so
that the likelyhood that what is claimed to be a fact really is a fact
is much higher than in a net posting, in an unrefereed paper, or in a
paper from a commercial journal.

To the best of my abilities, the D&E book agrees with the HOPL paper on
issues covered in both but provides much more information and context.

It would have been nice if comparable information existed on the origins
of most major languages. That would have made it easier to understand
the different languages in context and see how ideas moved through the
programming communities. The HOPL papers is a good start, but they differ
too much in what kind of information they supply and tend not to be
sufficiently detailed for my taste. Also, HOPL covers only a few languages.


 > Private data member stuff was in various languages
 > before "C with classes" was even conceived (e.g., CLU, Ada83).  It
 > certainly existed in Eiffel before C++ was christened.  Protected
 > capability was certainly in Eiffel-1 which predates C++.  Same with
 > overload resolution (e.g., Algol68 had this as did Ada 83 compilers
 > that were in the field before CWC or C++).  MI was in Eiffel from the
 > start and that predates its appearance in C++ for sure.

First of all, we must be careful about dates. C with classes had "private"
in 1979 and protected around 1981. Data abstraction language (such as Ada83)
tends to have private only (you need inheritance for the private/protected
distinction to be meaningful) whereas OO language (such as Smalltalk) tends
to have protected only (whatever it may be called).

I don't know if any language having both before C++ and I don't know of
any earlier language expressing the dinction between implementation
inheritance (private base) and interface inheritance (public base,
subtyping). This pre-dates Liskov's formulation of her substitution
principle by about 8 years. It is of course possible that some language
had equivalent facilities at the time I designed those features for
CwithClasses/C++ or that someone somewhere wrote a paper discussing
the issues, but I didn't know of one so the protection facilities
of C++ are independently developed. In addition to private, protected,
and public, C++ offers the mechanism for selectively including names
from a base in the interface of a derived class. That too may have been
an innovation, but I don't really know.

C++ introduced constructors with the possibility of having several as
well as destructors (around 1980). All languages that support information
hiding provides some form of initialization (and certainly Simula did),
but I think the C++ mechanism provides a degree of flexibility that was
novel.

It is hard to really pin down what is innovative and what is not. For
example, I credited Algol68 with C++'s ability to have declarations
in conditions so that you can declare, initialize, and test in one
place. However, I was (later) told by one of the people involved in the
Algol68 design that although Algol68 logically ought to have had that feature,
they didn't think of that in the right way at the right time, so Algol68
doesn't allow declarations in conditions. In other words. I had deduced
that feature from the structure of Algol68 and failed to verify.

There are literally hundreds of details that one could examine to try
to determine their exact antecedence and give credit where credit is
due. I do some of that in the history paper and in D&E, but here I'd
like to point to a couple of bigger issues.

C++ was designed to allow design and programming techniques from Simula
to be used in the context of systems programming and other applications
where run-time and space were critical. On way of looking at the task
I set myself was to make data abstraction and object-oriented techniques
affordable and accepted in a community that mostly didn't know of them
and to the extent it did couldn't afford to apply those techniques
given the languages available.

To the extent that C++ succeeded at that, C++ was ahead of the wave,
``a leader'' borrowing the phrase from the original posting. It has
always been my opinion that making something comprehensible and affordable
is a worthwhile, innovative, and socially useful activity. I think producing
14 million volkswagen's or Ford Ts is at least as innovative as building
a few thousands Rolls Royces or a few hundred formula-1 cars - even though
the vast majority of the individual features first appear in the luxury
and speciality cars. I think that the majority of areas where C++ has
contributed have to do with economy and scale.

C++ was designed to be useful rather than to be innovative. Wherever
possible, I tried to follow a well-tested precedence. Thus, you can
find ideas from Algol68, ML, Ada, Clu, and even BCPL in C++. The main
ideas came from C and Simula, of course. Only where I couldn't find a
solution that fitted in C++'s general framework and met my criteria for
run-time efficiency, ease of implementation, ease of teaching, etc.
(see D&E Chapter 4), did I feel compelled to try to invent something. 

Much of C++'s success has to do with fitting into existing environments
and being compact and fast (yes, I know that these are not the aspects
of C++ that are currently emphasized in the MS Windows world). The speed
and compactness of code generated from C++ depends on a few fundamental
design decisions that I think were novel at the time:

	The ability to easily link to existing languages and have C++
	code used from other languages. (This is done through the linkage
	model and it is directly supported in the C++ grammar).

	The ability to use user-defined types and built-in types in the
	same way. In Simula - as in most data abstraction and OO language -
	every object of a user-defined type must be on the heap; this
	leads to overheads compared to stack-allocated objects. Similarly,
	C++ pointers work uniformly for both user-defined and built-in
	types.

	C++ offers objects of user-defined types with zero space overhead
	compared to C structs.

	C++ offers calls of member functions with zero time overhead
	compared to C functions.

	C++ offers inline member and non-member functions with zero
	overhead compared to macros.

	C++ offers its form of dynamic (run-time) resolution, virtual
	functions, with low and fixed overhead compared to ordinary
	function calls (20% to 100% dependent of implementation).

	C++ can be used without a significant run-time-support system
	and without significant libraries.

These features were introduced in the 1979 to 1983 timeframe (virtual
functions last!) and described in journals and at conferences from
about 1981.

This combination of feature was - and to some extent still is - unique
and important to many. This efficiency is a large part of the reason
why C++ was able to blaze a trail into areas where data abstraction
and object-oriented languages had made essentially no headway.

By demonstrating applicability and efficiency in new application areas
and in new communities C++ opened opportunities to other languages
with a different balance of tradeoffs. Both where C++ was successfully
used and where problems were found, it opened a door to alternatives.

People who didn't try to use OO and abstraction languages in the early
days (say 1967 to 1989) typically seriously underestimate the obstacles
to getting these languages and programming techniques into non-research
use. Most would also be shocked at the state of their favorite language
- as compared to its current state - in its early years. When comparing
languages in a historical context we must consider not only if a language
has a feature, but also when it had it, when it was published, when it
was implemented, and whether those implementations were good enough for
production use.


 > Next I suppose you will be trying to tell me it was the first to have
 > generics (templates) or namespaces or assignment attempt or RTTI or...

Please refrain from making conjectures about what someone in a debate
might claim. It adds no facts and can fuel flamewars.


 > C++ was and is a _follower_.  That is not necessarily a bad thing, but
 > it is anything _but_ innovative.
 > 
 > /Jon
 > -- 
 > Jon Anthony
 > Organon Motives, Inc.
 > Belmont, MA 02178
 > 617.484.3383
 > jsa@organon.com

Over the years, C++ has evolved within a framework that was reasonably
well understood early on. During this evolution, C++ has borrowed from
several languages (always with acknowledgements), but it has never been
in the position of slavishly following fashion or systematically borrowing
from a perceived competitor. C++ evolved within its own framework to
meet the needs of its users. I don't think that can be fairly labelled
"being a follower."

As far as I know, Simula was the first language with structured RTTI
(INSPECT and QUA). Some studies I made of Simula programs convinced me
that the less RTTI was used the better the structure of an average program
(INSPECT was commonly used in ways that precluded modularity). The C++
RTTI (primarily dynamic_cast) was introduced to handle the few cases
where it is necessary and in a form that hopefully minimizes problems.

Multiple inheritance is sometimes mentioned as innovative in C++.
It existed in different - more powerful, but slower - forms in
several Lisp dialects. I considered it for C++ from about 1981 and
introduced it into C++ in a more static and type-safe form in 1987
after a couple of years of experimentation (a brief mention of C++ MI
can be found in my "What is Object-oriented programming?" paper from
1985). The form of multiple inheritance in C++ may be innovative, the
fundamental idea is quite old. I now consider MI essential for a
language relying on static type checking. You can do without it of
course (just like you can do without single inheritance and without
classes), but the resulting code is contorted.

In the area of exceptions, C++ may have added something important:
C++ exceptions can be of arbitrary type and inheritance is taken
into account when catching an exception. This provides important
possibilities for grouping exceptions that I don't know precedence
for (though the need for grouping has been known for decades).

Templates are an interesting case. Naturally, many languages have provided
macros, generics, type inference, etc. for decades. However, templates
grew out of the needs of C++ programmers and seem to have a combination
of features that provide a surprising expressive power. The (relatively
new) C++ standard library of containers and algorithms seems to me to
provide a unique combination of generality and efficiency. Naturally,
the algorithms are not new (most can be found in Knuth), most languages
provide containers which roughly correspond to what the STL offers,
and many of the programming techniques used are borrowed (with thanks
and acknowledgement) from the functional programming community.

Should something like this be considered innovative? Would it be fair
to say that it leads hundreds of thousands of programmers into areas
of programming where they haven't been and would have been unlikely
to reach for many more years? I think so.

	- Bjarne

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

OO, C++, and something much better!

[John (Max) Skaller]

On 3 Jan 1997 14:56:25 -0500, comeau@panix.com (Greg Comeau) wrote:

>In article <32CCE4ED.6A21@online.no> emangset@online.no writes:
>>Robert C. Martin wrote:
>>> > C++ was and is a _follower_.  That is not necessarily a bad thing, but
>> > it is anything _but_ innovative.
>>> 
>>> WRT technology I agree with you.  But C++ *does* show innovation in a
>>> completely different vein.  C++ is one of the first of the industrial OO
>>> languages that was created for the engineer instead of for the paradigm.
>>> C++ was not created to be "pure" or "right" or "correct".  It was created
>>> to be *used*.  And in that regard it represents an innovation wrt industrial
>>> OO languages.

>>> Robert C. Martin    
>>
>>Sorry, but you are wrong. This is one of the many myths that surrounds
>>C++. No engineer I know would use any tool pertaining to his or her
>>profession that was as badly designed and implemented as C++. "Pure"
>>pragmatism is not an option with respect to language design, something
>>even Mr. Stroustrup himself acknowledges.
>
>I have not a clue what you are talking about.  Indeed, the beauty
>of C++ is that it is a hybrid and that it does not lock you into one
>particular thing.  Robert is indeed correct about its flexibility
>and avoidance of so-called political correctness.  Since when are
>pragmatics not important in design, decisions, engineering?

Here' my opinion. Stroustrup is to be applauded for making a powerful
"non-religious" language available to everyone. C++ is not a clean
language. It's quite messy and hard to use. But it is available.
No one knows how to design a quality system -- and _also_ make
is widely available. Bjarne decided "having better than what we have"
was better than some intangible thing no one had.

Is C++ innovative? Too right it is. 
It has the most powerful support for genericity available
in any widely used commercial language. (Sorry, Ada doesn't count,
Eiffel is borderline, current Java is a backward step. If there
is any competition it is from Smalltalk [which uses 
dynamism instead]).

Is it "pure OO"? No. Thank goodness. It has something
much better -- a vague and not very good appoximation
to a new methodology which provides vastly superior
reusability, categorical progamming. The evidence
is in Standard (Template) Library which is one of the 
most reusable commercial libraries available for any system.

There is hardly any inheritance at all in the C++ Standard Library.
It is not an "Object Oriented" library. 80 or so members of the C++
committee, however, thought it was the best choice for C++.

Is C++ innovative? Of course it is. It was one of the FIRST mainsteam
language to provide class based object orientation and go on 
to something much better before standardisation has been completed.

Modern C++ has made TWO paradigm shifts. Most people
haven't made the first (to OO) yet it is already being
replaced.

Re: OO, C++, and something much better!

[vlad]

skaller@maxtal.com.au (John (Max) Skaller) wrote:
>Here' my opinion. Stroustrup is to be applauded for making a powerful
>"non-religious" language available to everyone. C++ is not a clean
>language. It's quite messy and hard to use. But it is available.
>No one knows how to design a quality system -- and _also_ make
>is widely available. Bjarne decided "having better than what we have"
>was better than some intangible thing no one had.

>Is C++ innovative? Too right it is. 
>It has the most powerful support for genericity available
>in any widely used commercial language. (Sorry, Ada doesn't count,
>Eiffel is borderline, current Java is a backward step. If there
>is any competition it is from Smalltalk [which uses 
>dynamism instead]).

>Is it "pure OO"? No. Thank goodness. It has something
>much better -- a vague and not very good appoximation
>to a new methodology which provides vastly superior
>reusability, categorical progamming. The evidence
>is in Standard (Template) Library which is one of the 
>most reusable commercial libraries available for any system.

>There is hardly any inheritance at all in the C++ Standard Library.
>It is not an "Object Oriented" library. 80 or so members of the C++
>committee, however, thought it was the best choice for C++.

>Is C++ innovative? Of course it is. It was one of the FIRST mainsteam
>language to provide class based object orientation and go on 
>to something much better before standardisation has been completed.

>Modern C++ has made TWO paradigm shifts. Most people
>haven't made the first (to OO) yet it is already being
>replaced.

Funny, I wanted to write almost the same think. I want to express my support to
your ideas, so you will be not alone when religious OO fanatics will be spitting
on you.

   

 Vlastimil Adamovsky
 ** C++ and Smalltalk consultant **
 * http://www.stepweb.com *

Re: OO, C++, and something much better!

[Mike Anderson]

I have some questions/comments about this (my words are preceeded by
"MA":)

John (Max) Skaller wrote:
> Stroustrup is to be applauded for making a powerful
> "non-religious" language available to everyone.

MA: What's "non-religious"?

> C++ is not a clean language. It's quite messy and hard to use. But it is available.

MA: So what?  There are plenty of available languages like that.

> No one knows how to design a quality system -- and _also_ make
> is widely available. Bjarne decided "having better than what we have"
> was better than some intangible thing no one had.

MA:  I don't understand that and won't comment on it.

> Is C++ innovative? Too right it is.
> It has the most powerful support for genericity available
> in any widely used commercial language. (Sorry, Ada doesn't count,
> Eiffel is borderline, current Java is a backward step. If there
> is any competition it is from Smalltalk [which uses
> dynamism instead]).

MA:  Why doesn't Ada count; why is Eiffel borderline, and why is current
Java a backword step?

> Is it "pure OO"? No. Thank goodness. It has something
> much better -- a vague and not very good appoximation
> to a new methodology which provides vastly superior
> reusability, categorical progamming. The evidence
> is in Standard (Template) Library which is one of the
> most reusable commercial libraries available for any system.

MA:  The above is utter nonsense (well, someone's got to say it).  I
don't usually rant but the sentences
	'Is it "pure OO"? No. Thank goodness.'
pisses me off because I firmly believe I in pure OO.  (Hey, I've got
some religion, but don't tell anybody.)  As far as "a vague and not very
good appoximation to a new methodology which provides vastly superior
reusability" ...are you being sarcastic or what?

....Mike

Re: OO, C++, and something much better!

[Stanley Allen]

John (Max) Skaller wrote:

> Is C++ innovative? Too right it is.
> It has the most powerful support for genericity available
> in any widely used commercial language. (Sorry, Ada doesn't count,
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You loaded the question, and therefore your dismissal of
Ada is the act of knocking down a strawman.

Let me engage in some debuking here, and point out that Ada
*is* widely used, just not in the PC/GUI world.  Ada is also
very much a "commercial" language; in fact, many of the
companies using Ada today for commercial projects consider
it to be a success factor in their software efforts.

To hear that C++'s template mechanism is "innovative" and
"powerful" comes as a surprise.  Parts of the C++ template
mechanism look like a borrowing of Ada's "generic" facility
(Stroustrup attributes this to Alex Stepanov, who had done
a great deal of work with Ada generics before designing the
C++ Standard Template Library).  Unfortunately, the type
system in C++ is too weak to support anything as powerful
as Ada's generic facility.  The C++ "template argument"
(which corresponds to Ada's "generic formal parameter") for
a type can only be of the form "class T".  In Ada terms,
this would be like having all generic formals be
"type T is private".

In C++, there is no way to 1) specify the kinds of types that
may be used to make an instance of the template (for example,
to specify that the template may only be instantiated with
integer types), or 2) to assume a particular set of operations
will be available within the template for the type argument
(for example, to assume that integer operations will be
availible for a variable of type T).

These two issues are the heart and soul of Ada generics
(derived as they are from Ada's type system), and provide
a powerful tool for specifying complete "contracts" between
the generic developer and user.  The C++ mechanism boils
down in practice to a "macro-expansion" tool.

--
Stanley Allen
mailto:sallen@hso.link.com

Re: OO, C++, and something much better!

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <32D0CA27.44C2@ghgcorp.com> Stanley Allen <sallen@ghgcorp.com> writes:


   John (Max) Skaller wrote:

   > Is C++ innovative? Too right it is.
   > It has the most powerful support for genericity available
   > in any widely used commercial language. (Sorry, Ada doesn't count,
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   You loaded the question, and therefore your dismissal of
   Ada is the act of knocking down a strawman.

   Let me engage in some debuking here, and point out that Ada
   *is* widely used, just not in the PC/GUI world.  Ada is also
   very much a "commercial" language; in fact, many of the
   companies using Ada today for commercial projects consider
   it to be a success factor in their software efforts.

   To hear that C++'s template mechanism is "innovative" and
   "powerful" comes as a surprise.  Parts of the C++ template
   mechanism look like a borrowing of Ada's "generic" facility
   (Stroustrup attributes this to Alex Stepanov, who had done
   a great deal of work with Ada generics before designing the
   C++ Standard Template Library).  Unfortunately, the type
   system in C++ is too weak to support anything as powerful
   as Ada's generic facility.  The C++ "template argument"
   (which corresponds to Ada's "generic formal parameter") for
   a type can only be of the form "class T".  In Ada terms,
   this would be like having all generic formals be
   "type T is private".

<stuff deleted>


   --
   Stanley Allen
   mailto:sallen@hso.link.com


I would tend to agree. Another point is that C++ templates tend to be
implemented differently in every compiler, so a program which uses
templates heavily is often less portable.

However, if I remember correctly, Alex Stepanov had earlier tried to
implement a library like the C++ STL in Ada, but was incapable of
doing it. This would indicate that the C++ template mechanism is more
flexible than the Ada generics.
Any comments?

Re: What is wrong with OO ?

[Bart Samwel]

Bjarne Stroustrup wrote:

> Only where I couldn't find a solution that fitted in C++'s general
> framework and met my criteria for run-time efficiency, ease of
> implementation, ease of teaching, etc. (see D&E Chapter 4), did I
> feel compelled to try to invent something.

When I read this, a lot of questions pop up in my head. I'll ask only
one: You've only included features that didn't compromise ease of
teaching (at least, that's my interpretation of what you wrote). Why is
it then, that C++ contains so many hidden 'features' (or rather,
non-explicit rules) that confuse people, at least at my university?

As far as I'm concerned, C++ is not a language for teaching. It has too
many of these implicit rules to be logical, and the fact that it
doesn't have garbage collection and does have pointers really makes it
error-prone; especially for beginning programmers, this is not a good
thing. They should be writing WHAT should be done, and ALL that should
be done; they shouldn't be bothered with the 'how' part of programming,
like (with alternatives): memory management (garbage collection),
pointers (references), virtual functions (can be detected by the
compiler). They should not be bothered with implicit rules (like the
multiple inheritance rules, for instance) that they have to know of,
before using multiple inheritance.

C++ is an excellent language as an extension to C, but C is altogether
obsolete and much too low-level, except for systems programming, and
other languages are now available for writing high-level software.
Many people make the (IMO huge) mistake of using C++ for high-level
software projects, leading to buggy results and, often, lots of core
dumps. Programmers are not perfect, and C++ expects them to be so by
providing too many ways of making mistakes.

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.

> Much of C++'s success has to do with fitting into existing
> environments and being compact and fast (yes, I know that these are
> not the aspects of C++ that are currently emphasized in the
> MS Windows world). The speed and compactness of code generated from
> C++ depends on a few fundamental design decisions that I think were
> novel at the time:

Speed and compactness is certainly a goal that C++ has achieved. But it
did not achieve one major goal: ease of use.

>         C++ offers inline member and non-member functions with zero
>         overhead compared to macros.

You shouldn't bother programmers with inlining. Inlining can be done
automatically by the compiler.

>         C++ offers its form of dynamic (run-time) resolution, virtual
>         functions, with low and fixed overhead compared to ordinary
>         function calls (20% to 100% dependent of implementation).

Virtual functions must be explicitly specified. This can be done by the
compiler. And, virtual functions must be specified in the ancestor
class; this means that when a class designer forgot to put that in
(and this happens often), I can't redefine the function correctly.

> Over the years, C++ has evolved within a framework that was reasonably
> well understood early on.

Well understood, yes. But the framework is now obsolete, and it has
some serious design flaws that also bother C++ users.


   Bart Samwel  (bsamwel@wi.leidenuniv.nl)

Re: OO, C++, and something much better!

[Chris Brand]

John (Max) Skaller wrote:
> 
[cut]
> 
> Is C++ innovative? Too right it is.
> It has the most powerful support for genericity available
> in any widely used commercial language. (Sorry, Ada doesn't count,
> Eiffel is borderline, current Java is a backward step. If there
> is any competition it is from Smalltalk [which uses
> dynamism instead]).
> 
[cut]

Great argument.

To paraphrase:
"Is C++ innovative? Yes. Its got something other languages had first but
it's more widely used."

Perhaps I've got the wrong definition of innovative...

-- 
Chris
Stating my own opinions, not those of my company.

Re: OO, C++, and something much better!

[Michael F Brenner]

Yes, there is some added flexibility in C++ templates over Ada generics,
and vice versa too. The added flexibility in C++ templates comes from the
ability to expand them at compile time without losing optimizations, unlike
Ada generics whose paradigm is to expand at run-time and remove staticness
from expressions. The added flexibility in Ada templates comes from the
added flexibility in Ada packages, which can have BOTH types and functions.
An ideal generic would have all of the Ada features plus the following:
(a) anything that was static in the package while you were testing it, that
is, before you made it generic, remains static after you genericized the
package; (b) there is a standard pragma that tells the compiler to 
expand the generic at compile time, (c) there is a formal generic
parameter type that works on EITHER modular or twos complement types,
and (d) generates the kind of code for each instantiation that keeps
track of the line numbers in generic source code, so unhandled exceptions
would generate a useful traceback of source code lines through generic
packages.

Re: OO, C++, and something much better!

[Tucker Taft]

Michael F Brenner (mfb@mbunix.mitre.org) wrote:

: Yes, there is some added flexibility in C++ templates over Ada generics,
: and vice versa too. The added flexibility in C++ templates comes from the
: ability to expand them at compile time without losing optimizations, unlike
: Ada generics whose paradigm is to expand at run-time and remove staticness
: from expressions. 

It is true that Ada considers some expressions inside a generic as
non-static, but that has no necessary effect on optimization.
Many non-static expressions are computed at compile-time.  There
are certain places where the language requires static expressions,
such as an expression in a case alternative, but compilers can and do
still evaluate expressions that are not "officially" static at
compile-time.

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: What is wrong with OO ?

[Steven Perryman]

In article <5aig7q$din@news.irisa.fr> jezequel@stormbringer.irisa.fr (Jean-Marc Jezequel) writes:

>> In article <5ahqo6$gk6@news4.digex.net>, ell@access2.digex.net (Ell) writes:

>> You only addressed one of my points (MI) and would you please tell me
>> which OOPLs had MI before C++.

> Eiffel has multiple inheritance, genericity, exception handling, GC etc.
> since 1986.

The OO Lisp variants had MI in 1986. LOOPS and Flavors come immediately to
mind. CLOS may have been defined by then, but certainly was around in 1987
(which means it had MI before C++ ) .


Regards,
Steven Perryman
perryman@cpd.ntc.nokia.com

Re: What is wrong with OO ?

[Bill Gooch]

Jean-Marc Jezequel wrote:
> 
> In article <5ahqo6$gk6@news4.digex.net>, ell@access2.digex.net (Ell) writes:
>
> >You only addressed one of my points (MI) and would you please tell me
> >which OOPLs had MI before C++.
> 
> Eiffel has multiple inheritance, genericity, exception handling, GC etc. since 1986.

Flavors (prime pregenitor of CLOS) has all of these, since 
the late 70s (widely available commercially since late 1982).
Also method combination and "just in time" method compiling.

> For the record:
> Smalltalk has "Private data members", GC and all OO mechanisms at least since 1980 (in facts well before).
> 
> Ada has static typing, information hiding, genericity, exception handling and
> "static resolution of overloaded functions" officialy since 1983, but these
> were there in the proposals long before.
> 
> But as someone else has said, there is nothing wrong in using other's good ideas,
> as long as they are credited.

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: What is wrong with OO ?

[John Walker]

 On Wed, 1 Jan 1997 02:35:34 GMT,
 Ell <ell@ACCESS1.DIGEX.NET> writes:

>In this thread someone said assembler was "real" and higher level
>languages were abstractions above that.  I always thought voltage
>states/levels were real and that assembler was an abstraction of voltage
>states/levels.
>
>Elliott

Well, almost... :)

Those who want to be "real" can avail themselves of the simple, easy,
intuitively obvious, always understandable option of machine language
(for PCs, for instance, direct hex).

The distinction is that hex is a *representation* of the voltage
levels, but not an "abstraction"; assembler is indeed an
*abstraction*.

To wit, the sig:

            ---------------------------------------------------
              John Walker, walkerj@sw-eng.falls-church.va.us
                 ---Assembler is a high-level language.---
        .GET DSCLAIMR.STD   ; Even though this *is* on *my* nickel!
            ---------------------------------------------------

Re: What is wrong with OO ?

[Jon S Anthony]

In article <fxtu3oysbzp.fsf@isolde.mti.sgi.com> Matt Austern <austern@isolde.mti.sgi.com> writes:

> jsa@alexandria (Jon S Anthony) writes:
> 
> > Oh, I don't know.  I think C++ was created simply because BS was
> > saddled with C (at ATT) and wanted _something_ that had a least _some_
> > abstraction capabilities in it.  Voila.  C++.  Whether it is any more
> > "usable" than several other options is highly open to question.  And
> > in fact, in general I would say the answer is "no".
> 
> It's not necessary to speculate on why Bjarne Stroustrup made the
> design decisions that he did: he discusses them, in a fair amount
> of detail, in _The Design and Evolution of C++_.

He also gave various descriptions of this process while it was
happening cira 87-89 and I happened to attend some of these.


> he was trying to create a language that, like C, made it possible to
> write low-level programs, but that also, like Simula, included
> high-level abstraction facilities.  

Exactly.  This came from his direct experience of having to recode a
Simula program for his thesis into BCPL.  The resulting nightmare was
not something he wished to have to go through again.  When getting to
ATT and seeing that it was C or nothing, he decided to "fix it" before
suffering the same experience.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Jon S Anthony]

In article <E3I8GL.AuH@research.att.com> bs@research.att.com (Valerie Torres) writes:

> Jon S Anthony (jsa@alexandria) writes:
>  > Private data member stuff was in various languages
>  > before "C with classes" was even conceived (e.g., CLU, Ada83).  It
>  > certainly existed in Eiffel before C++ was christened.  Protected
>  > capability was certainly in Eiffel-1 which predates C++.  Same with
>  > overload resolution (e.g., Algol68 had this as did Ada 83 compilers
>  > that were in the field before CWC or C++).  MI was in Eiffel from the
>  > start and that predates its appearance in C++ for sure.

> First of all, we must be careful about dates. C with classes had "private"
> in 1979 and protected around 1981. Data abstraction language (such as Ada83)
> tends to have private only (you need inheritance for the private/protected
> distinction to be meaningful) whereas OO language (such as Smalltalk) tends
> to have protected only (whatever it may be called).

Fair enough and I certainly can basically agree with this.  It is also
no big deal IMO if the features are _not_ "innovative" or new.  If
they are good and correct and well integrated - who cares (well some
do, but from many points of view, it just doesn't matter).  For
example, private stuff is basically captured in M2 by opaque types,
which according to Wirth was around '77-'78.  As you point out,
Smalltalk had the equivalent of protected and that was early '70s.
Shrug...


> I don't know if any language having both before C++ and I don't know of
> any earlier language expressing the dinction between implementation
> inheritance (private base) and interface inheritance (public base,
> subtyping).

You talking C++ or "C with Classes"?


> This pre-dates Liskov's formulation of her substitution
> principle by about 8 years. It is of course possible that some language
> had equivalent facilities at the time I designed those features for
> CwithClasses/C++ or that someone somewhere wrote a paper discussing

Well, what time frame are you really refering to here?  The
79-early-8x stuff of CwithClasses or the latter 80's C++?


[Various other stuff snipped on co/independent discovery etc.]

Well, sure, all this sounds perfectly sensible and believable.


> There are literally hundreds of details that one could examine to try
> to determine their exact antecedence and give credit where credit is
> due.

Absolutely.


> C++ was designed to allow design and programming techniques from Simula
> to be used in the context of systems programming and other applications
> where run-time and space were critical. On way of looking at the task
> I set myself was to make data abstraction and object-oriented techniques
> affordable and accepted in a community that mostly didn't know of them
> and to the extent it did couldn't afford to apply those techniques
> given the languages available.
> 
> To the extent that C++ succeeded at that, C++ was ahead of the wave,

Ah, this is the "_implementation_ innovation" aspect that I originally
refered to as something that I would acknowledge C++ "leading" in the
"OO world"...


> of C++ that are currently emphasized in the MS Windows world). The speed
> and compactness of code generated from C++ depends on a few fundamental
> design decisions that I think were novel at the time:

Some of these are novel (in a very narrow context - existing C) but
most are not.


> 	The ability to use user-defined types and built-in types in the
> 	same way. In Simula - as in most data abstraction and OO language -
> 	every object of a user-defined type must be on the heap; this
> 	leads to overheads compared to stack-allocated objects. Similarly,
> 	C++ pointers work uniformly for both user-defined and built-in
> 	types.

This certainly exists in Ada83 (sans virtual stuff).


> 	C++ offers objects of user-defined types with zero space overhead
> 	compared to C structs.

Same here.


> 	C++ offers calls of member functions with zero time overhead
> 	compared to C functions.

Same here.


> 	C++ offers inline member and non-member functions with zero
> 	overhead compared to macros.

Same here.


> 	C++ offers its form of dynamic (run-time) resolution, virtual
> 	functions, with low and fixed overhead compared to ordinary
> 	function calls (20% to 100% dependent of implementation).

This is a very good example - quite possibly the most important one.


> 	C++ can be used without a significant run-time-support system
            ^^^
> 	and without significant libraries.

Most statically compiled languages could and can be so used - it
"just" requires intelligent binders (not necessarily linkers...)


> This combination of feature was - and to some extent still is - unique
> and important to many.

This is not currently believable.  However, in the past, the efficient
runtime dispatch ability was at one point clearly a plus.


> This efficiency is a large part of the reason why C++ was able to
> blaze a trail into areas where data abstraction and object-oriented
> languages had made essentially no headway.

This is not particularly clear or believable.  It probably did have
something to do with it, but how much is not obvious.  The C heritage
(and its _presumed_ efficiency by association) is still the single
most likely reason for the demonstrated popularity.  Of course, in
those early days, there was no reason to believe that this would be a
real factor.  Sort of like having the insight/luck to buy into MS
before they were anything.


> By demonstrating applicability and efficiency in new application areas
> and in new communities C++ opened opportunities to other languages
> with a different balance of tradeoffs. Both where C++ was successfully
> used and where problems were found, it opened a door to alternatives.

Actually, I think a closer reading would be that people started out
thinking, "hey, we C folk can get on this <hated> OO/abstraction
bandwagon with our own C++!  It's basically just a better C which you
can sometimes use for OO stuff if you want.  Heck, you can even
compile most of your old C stuff with a C++ compiler."  What happened
next was that some of the more savvy realized that there really _was_
some good in this sort of approach after all - irrespective of any
language issue.  These folks no longer are wedded to the C++ language
and in fact many have moved on to, shall we say, more pleasent just as
capable/efficient alternatives.


> from a perceived competitor. C++ evolved within its own framework to
> meet the needs of its users. I don't think that can be fairly labelled
> "being a follower."

OK, but don't think it can be fairly labelled a "leader" either.  I
suppose we can say that it just "is"...


> language relying on static type checking. You can do without it of
> course (just like you can do without single inheritance and without
> classes), but the resulting code is contorted.

I don't want to go into this, suffice to say we can simply agree to
disagree.


> In the area of exceptions, C++ may have added something important:
> C++ exceptions can be of arbitrary type and inheritance is taken
> into account when catching an exception.

I see this as an approach or refinement to an already known and
(reasonably) understood facility.  I suppose that means I have a
somewhat more stringent notion of "innovation".


> Templates are an interesting case. Naturally, many languages have provided

Same here.  Note that in both of these cases you don't get something
for nothing.  Both exceptions and templates are IMO rather more
convoluted in C++ than the (more or less) equivalents in alternatives.

> Should something like this be considered innovative? Would it be fair

Depends on your point of view.  Some would probably say "yes" - for
example, you - I would tend to say "no".

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Stanley Allen]

Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:

> However, if I remember correctly, Alex Stepanov had earlier tried to
> implement a library like the C++ STL in Ada, but was incapable of
> doing it. This would indicate that the C++ template mechanism is more
> flexible than the Ada generics.
> Any comments?

My history may be a bit rusty, but I believe that
Alex Stepanov's work in Ada was successful, just not
widely used.  He had some published material about
the Ada work, which I have not seen directly.  It
is listed in the references of his on-line paper
"Algorithm-Oriented Generic Libraries":

    http://www.cs.rpi.edu/~kennyz/www/ADS/Algor/Algor.html

Stepanov's work was done using Ada83; it would
certainly be different if it were done today with
Ada95.

--
Stanley Allen
mailto:sallen@ghgcorp.com

Re: OO, C++, and something much better!

[Robert Dewar]

Tucker said

"It is true that Ada considers some expressions inside a generic as
non-static, but that has no necessary effect on optimization.
Many non-static expressions are computed at compile-time.  There
are certain places where the language requires static expressions,
such as an expression in a case alternative, but compilers can and do
still evaluate expressions that are not "officially" static at
compile-time."


One of the mistakes made in some Ada 83 compilers was to assume that the
concepts of "evaluable at compile time" and "static expression" could be
equated, but this was not true in Ada 83 and is not true in Ada 95. The
set of static expressions is a subset of the expressions that can be
evaluated at compile time, and compilers should treat them differently.

To see how GNAT handles this, look at the unit Sem_Eval, and note that
the section on "Compile-Time Known Values" addresses this issue.

Ada Generics (was Re: OO, C++, and something much better!)

[Bob Gilbert]

In article <5arhb0$d4e@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:
> Yes, there is some added flexibility in C++ templates over Ada generics,
> and vice versa too. The added flexibility in C++ templates comes from the
> ability to expand them at compile time without losing optimizations, unlike
> Ada generics whose paradigm is to expand at run-time and remove staticness
> from expressions. 

Most of the Ada comilers I've used do expand the generic instantiation at
compile time.  Could somebody offer up an example of where this would not
be possible?

-Bob

Re: OO, C++, and something much better!

[Robert Dewar]

Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:

> However, if I remember correctly, Alex Stepanov had earlier tried to
> implement a library like the C++ STL in Ada, but was incapable of
> doing it. This would indicate that the C++ template mechanism is more
> flexible than the Ada generics.
> Any comments?

Actually, when I talked to Alex, he indicated that there were critical
features in Ada 95 that were missing in C and C++ for this kind of
work. In particular, he noted that C lacks a general address comparison
operation, useful for hashing data structures, whereas Ada does have such
an operation (in System.Storage_Elements on type Integer_Address). It is
a bit ironic to identify this particular feature as crucial (since most
people mistakenly think that C has such a feature and Ada doesn't!)

He did also discuss problems in Ada 95, most notably the fact that generics
are less flexible than templates (that is to be expected, the flexibility
of templates comes of course at the expense of compile time checkability),
and also the lack of automatic instantiation in Ada.

Automatic instantiation is of course a dangerous tool, but in the hands
of those writing libraries of this type (Alex said to me that he thought
there were only about six people who should be writing such libraries and
he did not know who the other five were :-) :-) dangerous tools can be
put to good use, with the danger being insulated from the eventual client
at least in some cases.

There is a team at Rensaleer which has been working on duplicating STL
in Ada 95. The preliminary results looked very encouraging, I do not
know the status of this work.

Re: OO, C++, and something much better!

[Jay Martin]

ohk@ultra.tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB) writes:

>However, if I remember correctly, Alex Stepanov had earlier tried to
>implement a library like the C++ STL in Ada, but was incapable of
>doing it. This would indicate that the C++ template mechanism is more
>flexible than the Ada generics.
>Any comments?

I think this is with Ada83 (I actually have his unimpressive book "The
Ada(83) Generic Library").  It took literally minutes to smash into
braindead limitations of Ada83 which made elegant data structure
libraries infeasable.  Since the standard was locked, it took 12 years
before any of these problems were corrected.  To me this proved the
need for timely evolution of computer languages.

Jay

Re: Ada Generics (was Re: OO, C++, and something much better!)

[Robert Dewar]

Bob Gilbert asks

"Most of the Ada comilers I've used do expand the generic instantiation at
compile time.  Could somebody offer up an example of where this would not
be possible?"

No one can give you an example, because there are none. GNAT demonstrates
that it is possible to do all generic instantiation at compile time.

Note however that in a classical library model, as opposed to the source
model of GNAT, there are cases of circular instantiations which may require
some trickery to do at compile time, so one can imagine compilers with
restrictions on what can be done at compile time (by circular instantiations
here I do not mean truly circuluar, which is of course illegal), but just
mutually recursive references, e.g. two packages, each of which instantiates
from the other.

Re: OO, C++, and something much better!

[Bertrand Meyer]

In my opinion neither Ada (83 or 95) nor C++ has the combination
of mechanisms making it possible to have the full power of
generics in an object-oriented language, as present in Eiffel:

	- Unconstrained genericity, to declare a class
	  as e.g. LIST [G], where G represents an arbitrary
	  type, so that you can then use LIST [SOME_TYPE] regardless
	  of what SOME_TYPE is.

	- Constrained genericity, as in e.g. 
	  SORTED_LIST [G -> COMPARABLE], to require that
	  some operations be applicable to all actual
	  generic parameters. The rule is that
	  SORTED_LIST [SOME_TYPE] is permitted if and only
	  if SOME_TYPE inherits, directly or indirectly from
	  COMPARABLE. The -> symbol is evocative of the symbol
	  for inheritance used in class diagrams in e.g. B.O.N.
	  Within the class SORTED_LIST, any operation (feature, method)
	  of class COMPARABLE, such as infix "<" etc., is then applicable
	  to entities of type G.

	- A completely consistent type structure, in which 
	  even basic types such as INTEGER are classes,
	  present in the general inheritance structure.
	  (In C++ or Java, for example, the basic types
	  are completely separate from the class and inheritance
	  structure.)

	- True static typing (with no cast a la C++).

So in the constrained genericity case SORTED_LIST [INTEGER]
will be permitted, since COMPARABLE is indeed an existing class,
describing order relations and part of the Eiffel Library
Kernel Standard, and INTEGER (also part of ELKS) does inherit
from COMPARABLE.

SORTED_LIST [TENNIS_PLAYER] will also be
valid, assuming the user-defined class TENNIS_PLAYER inherits
from COMPARABLE. But something like SORTED_LIST [COMPLEX]
will be rejected by the compiler, assuming COMPLEX is not
a descendant of COMPARABLE.

In the unconstrained case, a declaration such as LIST [G]
is understood as an abbreviation for LIST [G -> ANY], where
ANY is the ELKS class inherited by all classes. This makes
it possible to apply objects of type G a wide range of operations
applicable to all objects: equality comparison (redefinable
in any class as long as it satisfies the original assertions),
copying, cloning, even (in the latest version of ELKS) hash
coding.

Without going into the details, I should add that Eiffel's design
for generics avoids the grave problems that one reads about in
connection with C++ templates: the need in C++ to  generate code
separately
for each generic derivation (each new actual generic parameter), with
its
rather bad effect on compilation time ("template instantiation problem")
and, as a result, the advice regularly given in the C++ literature
to avoid using templates too much. In Eiffel, you can generate
code just once (with some specific optimizations for basic types),
without having to pay any performance overhead either at compile
time or at run time. So you can use genericity as much as you like.
The ISE Eiffel libraries, for example, are generic throughout.

 
In comparison with Eiffel, not even mentioning Java with its total lack
of genericity, the other attempts at generic mechanisms that I have seen
in an O-O context look to me rather half-hearted.

I think Eiffel's consistent and complete treatment of genericity and
inheritance is one of the reasons why some of the biggest successful
industrial O-O projects have been produced in Eiffel. When the goal is
not just to play around, but to build large, mission-critical systems,
one needs the right combination of mechanisms, not just a partial
attempt.

For details about the Eiffel mechanism see the Eiffel language tutorial
at
http://www.eiffel.com.


-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com (WITH FRAMES)
	or http://www.eiffel.com/noframes.html

Re: OO, C++, and something much better!

[Andrew Koenig]

In article <OHK.97Jan6132731@ultra.tfdt-o.nta.no> ohk@ultra.tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB) writes:

> However, if I remember correctly, Alex Stepanov had earlier tried to
> implement a library like the C++ STL in Ada, but was incapable of
> doing it. This would indicate that the C++ template mechanism is more
> flexible than the Ada generics.

What Alex told me about that effort was that he was unable to find
a single Ada compiler that implemented the standard accurately enough
to enable him to do what he wanted to do with his library.
-- 
				--Andrew Koenig
				  ark@research.att.com

Re: What is wrong with OO ?

[Jon S Anthony]

In article <rmartin-0301970909390001@vh1-018.wwa.com> rmartin@oma.com (Robert C. Martin) writes:

> In article <JSA.97Jan2200948@alexandria>, jsa@alexandria (Jon S Anthony) wrote:
> 
> > In article <rmartin-0201971102070001@pool11-018.wwa.com> rmartin@oma.com
> (Robert C. Martin) writes:
> > 
> > > I think however, that there are several domains (e.g.
> > > hard real time systems) in which C++ will remain predominant.
> > 
> > Is there any truth to this????  I didn't think C++ was even much of a
> > player in this particular arena.  Certainly it is not as "dominant"
> > here as say C (or probably Ada for that matter).
> 
> Actually, I have several very large (i.e. Fortune 100) customers that are
> making 
> use of C++ in hard real time embedded systems for major projects.

OK - but does that fact alone somehow make it "dominant"???????
Doesn't seem like it to me, unless this "several" really means
"several tens of thousands of applications".  Is this true????

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[drush]

As a first comment this thread is diverging just like most
of the problematic software systems where "OO has failed".

However, I am going to continue to propagate the insanity.

Tom Bushell wrote in <32ca9f2d.174894569@news.nstn.ca>:

>Very true.  But my experience has been that "wiring in" to certain
>languages is easier. [snip]

This is so true *and* it explains the popularity of C++ (spit). At
first C++ feels like everything you ever wanted fixed in C. So
people feel "wired in" very quickly. Of course, the more you follow
its paradigms and explore its semantic space, you notice that it
is really really really really weird in there. Lots of irregularities,
insanities, and inanities. OTOH, I've been told that the committe
has been fixing some of the craziness. 

Gripping hand is that a simple, regular semantic basis in a language
will take you much further than a complex one.

>It seems much easier to get into a state of flow when using these
>languages - you just code and test, and everything seems to work.  I
>can hardly ever achieve this happy state in C, even though it's one of
>my most familiar languages - it's just too much like work.

Absolutely. I love Smalltalk. I spend almost no time working around
the language/coding test programs to check implementation behavior.
I must admit that "straight" C flows for me very well, too. It's the
simple semantic structure of the language, again. I just don't get
a sense of the tool inflicting itself upon my design with these
tools. 

Software development is hard enough. I have to design and explain
my work in such a way to keep managers, customers, and users all
happy (and the above are all whiny breeds of people). I sure don't
like dealing with a whiny compiler on top of it all.

In the usenet flow...
	david rush
	mailto:kumo@Intercenter.net

	I bill $100/min for reading commercial email

Re: OO, C++, and something much better!

[Ken Garlington]

Jay Martin wrote:
> 
> Since the standard was locked, it took 12 years
> before any of these problems were corrected.

Actually, back with Ada was a MIL-STD, there was a requirement to review
it
every _five_ years for updates. As I recall, no one wanted to do an
update
on the first cycle, in order to give implementations a chance to mature.
The
second cycle ended with Ada 95.

What rule (if any) is there for ISO standard review cycles?

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Ken Garlington]

Bertrand Meyer wrote:
> 
> In my opinion neither Ada (83 or 95) nor C++ has the combination
> of mechanisms making it possible to have the full power of
> generics in an object-oriented language, as present in Eiffel:
> 
>         - Unconstrained genericity, to declare a class
>           as e.g. LIST [G], where G represents an arbitrary
>           type, so that you can then use LIST [SOME_TYPE] regardless
>           of what SOME_TYPE is.

I've seen Mr. Meyer mention this in various articles, but I've never
understood it.
What's the distinction between an Ada generic with a limited private
type as a
parameter, and an "unconstrained" generic?

>         - Constrained genericity, as in e.g.
>           SORTED_LIST [G -> COMPARABLE], to require that
>           some operations be applicable to all actual
>           generic parameters. The rule is that
>           SORTED_LIST [SOME_TYPE] is permitted if and only
>           if SOME_TYPE inherits, directly or indirectly from
>           COMPARABLE. The -> symbol is evocative of the symbol
>           for inheritance used in class diagrams in e.g. B.O.N.
>           Within the class SORTED_LIST, any operation (feature, method)
>           of class COMPARABLE, such as infix "<" etc., is then applicable
>           to entities of type G.

Isn't this also available in Ada? In particular, can't you require the
user to
provide the needed operations in the absence of visible defaults?

>         - A completely consistent type structure, in which
>           even basic types such as INTEGER are classes,
>           present in the general inheritance structure.
>           (In C++ or Java, for example, the basic types
>           are completely separate from the class and inheritance
>           structure.)

I also thought this was true of Ada. Isn't Integer actually considered
part of
the general inheritance structure of the root_integer class? [LRM
3.5.4:14?]

>         - True static typing (with no cast a la C++).


> 
> So in the constrained genericity case SORTED_LIST [INTEGER]
> will be permitted, since COMPARABLE is indeed an existing class,
> describing order relations and part of the Eiffel Library
> Kernel Standard, and INTEGER (also part of ELKS) does inherit
> from COMPARABLE.
> 
> SORTED_LIST [TENNIS_PLAYER] will also be
> valid, assuming the user-defined class TENNIS_PLAYER inherits
> from COMPARABLE. But something like SORTED_LIST [COMPLEX]
> will be rejected by the compiler, assuming COMPLEX is not
> a descendant of COMPARABLE.
> 
> In the unconstrained case, a declaration such as LIST [G]
> is understood as an abbreviation for LIST [G -> ANY], where
> ANY is the ELKS class inherited by all classes. This makes
> it possible to apply objects of type G a wide range of operations
> applicable to all objects: equality comparison (redefinable
> in any class as long as it satisfies the original assertions),
> copying, cloning, even (in the latest version of ELKS) hash
> coding.
> 
> Without going into the details, I should add that Eiffel's design
> for generics avoids the grave problems that one reads about in
> connection with C++ templates: the need in C++ to  generate code
> separately
> for each generic derivation (each new actual generic parameter), with
> its
> rather bad effect on compilation time ("template instantiation problem")
> and, as a result, the advice regularly given in the C++ literature
> to avoid using templates too much. In Eiffel, you can generate
> code just once (with some specific optimizations for basic types),
> without having to pay any performance overhead either at compile
> time or at run time. So you can use genericity as much as you like.
> The ISE Eiffel libraries, for example, are generic throughout.
> 
> 
> In comparison with Eiffel, not even mentioning Java with its total lack
> of genericity, the other attempts at generic mechanisms that I have seen
> in an O-O context look to me rather half-hearted.
> 
> I think Eiffel's consistent and complete treatment of genericity and
> inheritance is one of the reasons why some of the biggest successful
> industrial O-O projects have been produced in Eiffel. When the goal is
> not just to play around, but to build large, mission-critical systems,
> one needs the right combination of mechanisms, not just a partial
> attempt.
> 
> For details about the Eiffel mechanism see the Eiffel language tutorial
> at
> http://www.eiffel.com.
> 
> --
> Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
> 805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
> ftp://ftp.eiffel.com
> Visit our Web page: http://www.eiffel.com (WITH FRAMES)
>         or http://www.eiffel.com/noframes.html

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[David Emery]

>> 	- A completely consistent type structure, in which 
>> 	  even basic types such as INTEGER are classes,
>> 	  present in the general inheritance structure.
>> 	  (In C++ or Java, for example, the basic types
>> 	  are completely separate from the class and inheritance
>> 	  structure.)
>
>OK, here you have me.  But, Eiffel hedges a bit here as well with its
>"expanded types".

I think that there is not a clear consensus on this as A Good Thing.
From a practical perspective, there seems to be a significant price to
pay for 'full generality' (e.g. integers are classes just like
user-defined record types.)  Java, for instance, has primitive integer
types, and my understanding that the reason for this is performance,
pure and simple.  Making 'int' a class would result in unacceptable
performance, both compile-time and runtime, for simple things like
"a[i++] := b + c;" (for int a, b, c).

Language engineering design is a series of compromises between expressiveness
and efficiency (among other compromises).  Pure 'class-hood' for all
types in the system is one area where there are serious tradeoffs between
expressiveness and efficiency.

				dave
-- 
<.sig is away on vacation>

Re: OO, C++, and something much better!

[Mark A Biggar]

In article <JSA.97Jan8123334@alexandria> jsa@alexandria (Jon S Anthony) writes:
>In article <32D2E6C8.13728473@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:
>> So in the constrained genericity case SORTED_LIST [INTEGER]
>> will be permitted, since COMPARABLE is indeed an existing class,
>
>Good point.  Lost a Minbari Cruiser on this one...

Not really as you can always say:

generic
	type G is private;
	with function "<"(L,R: G) return Boolean is <>;
package SORTED_LIST is ...

This requires that either the Type G have a "<" defined or that you provide 
one at the time of instanitation.  Of course there is nothing that requires 
that the provided function realy be a less-than function (which is usefull
as providing a ">" instead reverses the order of the list) but Eiffel has the
same problem and there is no guarentee that a class derived from COMPARABLE
hasn't redefined "<" to do something else either.

--
Mark Biggar
mab@wdl.lmco.com

Re: What is wrong with OO ?

[Richard A. O'Keefe]

ell@access1.digex.net (Ell) writes:

>Led (first or second) wrt the OO paradigm: Private data members, static
>resolution of overloaded functions, protected members, and multiple
>inheritance.

Aren't the keywords 'private' and 'protected' copied from Simula?
(The old "Common Base Language" definition didn't have them, but
they were in Simula before they were in C++.)  As for multiple
inheritance, there was a multiple-inheritance version of Smalltalk
before C++ got it.

As for static resolution of overloaded *functions*, Algol 68 had _that_
long before C was dreamed of, let alone C++.

C++ deserves the credit for getting some of these things into the hands
of the programmer on the street.  

-- 
My tertiary education cost a quarter of a million in lost income
(assuming close-to-minimum wage); why make students pay even more?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: OO, C++, and something much better!

[Robert I. Eachus]

 
      Bertrand Meyer said:

   > In my opinion neither Ada (83 or 95) nor C++ has the combination
   > of mechanisms making it possible to have the full power of
   > generics in an object-oriented language, as present in Eiffel...

     And then listed four properties, all of which are in Ada 95!

     There are differences between Ada 95 and Eiffel, for example in
the way multiple inheritance is handled.  The biggest difference
though is that the type system is normally viewed as a forest rather
than a single tree.  These differences do affect the way in which
these things are usually implemented, but they do lead to major
differences in the way the features are normally used.  (To avoid
flames from both sides: see "normally viewed" and "usually
implemented" above.  I'm talking about how generics tend to be used,
not about limitations--in either language.)

     For example, in Ada you would not require a class to be derived
from COMPARABLE if you wanted to insure that comparisons work, you
would more likely require the comparison operations directly.  (See
below.) This is usually the "right" way to do it in Ada for technical
reasons, but the real reason is that the Ada mindset sees classes as
not strictly hierarchical but as a set of non-exclusive groupings.
i.e. Just as it is sensible to ask if type A is in class B, it is also
sensible in Ada to ask or specify if a type has discriminants or if a
subtype is definite.

    A good working definition of a class in Ada is the set of all
types that match a particular generic formal part:

           type Foo is range <>; -- integer class

           type Fubar(<>) is limited private; -- The class of all classes.

           type Bar is new Foob with private; -- Foob'CLASS (for
           -- non-Ada programmers, Foob, a tagged type, or any type
           -- derived directly or indirectly from it.)
   
           -- for completeness:
           type Barf is new Foobar; -- same as above, but Barf must
           -- be definite.
       
           type Element is private;
           with function "<" (L,R: Element) return Boolean is <>;
           -- Any ordered type with assignment and equality.

     And so on...
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: OO, C++, and something much better!

[Kohler Markus]

>>>>> "Bertrand" == Bertrand Meyer <bertrand@eiffel.com> writes:

    Bertrand> In my opinion neither Ada (83 or 95) nor C++ has the
    Bertrand> combination of mechanisms making it possible to have the
    Bertrand> full power of generics in an object-oriented language,
    Bertrand> as present in Eiffel:

In my opinion and not only in my opinion Eiffel has NOT the full power of generics. 

Let me cite David L. Shang :

     "Unlike Eiffel, Transframe does not require runtime type checks to eliminate
     holes (a hole is defined as a leak in the specification through which an argument
     can pass the check but the type of the argument is actually wrong) in the
     supertype's interface. Instead it requires a runtime type check merely for
     flexibility in heterogeneous programming, which is exactly the case forbidden by
     some other approaches. 

     Class parameters can be used to express type dependencies. And thanks to the
     type dependency check via type assurance, a compiled Transframe program will
     never report a runtime type error. 

     Eiffel allows fields/methods in subclasses to be redefined by subtypes, which is a
     more flexible type system than that of C++. Eiffel allows covariant changes to
     types of instance variables and, as a result, it is not statically type-safe. A
     system-level type check is required but only works with a closed-world
     assumption. It seems that Eiffel's newly proposed type checking rule is too
     conservative to include a useful usage of covariance. "

See http://www.sigs.com/publications/docs/oc/9608/oc9608.c.shang.html
for  more information. 

    Bertrand> 	- Unconstrained genericity, to declare a class as
    Bertrand> e.g. LIST [G], where G represents an arbitrary type, so
    Bertrand> that you can then use LIST [SOME_TYPE] regardless of
    Bertrand> what SOME_TYPE is.

    Bertrand> 	- Constrained genericity, as in e.g.  SORTED_LIST [G
    Bertrand> -> COMPARABLE], to require that some operations be
    Bertrand> applicable to all actual generic parameters. The rule is
    Bertrand> that SORTED_LIST [SOME_TYPE] is permitted if and only if
    Bertrand> SOME_TYPE inherits, directly or indirectly from
    Bertrand> COMPARABLE. The -> symbol is evocative of the symbol for
    Bertrand> inheritance used in class diagrams in e.g. B.O.N.
    Bertrand> Within the class SORTED_LIST, any operation (feature,
    Bertrand> method) of class COMPARABLE, such as infix "<" etc., is
    Bertrand> then applicable to entities of type G.

    Bertrand> 	- A completely consistent type structure, in which
    Bertrand> even basic types such as INTEGER are classes, present in
    Bertrand> the general inheritance structure.  (In C++ or Java, for
    Bertrand> example, the basic types are completely separate from
    Bertrand> the class and inheritance structure.)

    Bertrand> 	- True static typing (with no cast a la C++).

    Bertrand> So in the constrained genericity case SORTED_LIST
    Bertrand> [INTEGER] will be permitted, since COMPARABLE is indeed
    Bertrand> an existing class, describing order relations and part
    Bertrand> of the Eiffel Library Kernel Standard, and INTEGER (also
    Bertrand> part of ELKS) does inherit from COMPARABLE.

    Bertrand> SORTED_LIST [TENNIS_PLAYER] will also be valid, assuming
    Bertrand> the user-defined class TENNIS_PLAYER inherits from
    Bertrand> COMPARABLE. But something like SORTED_LIST [COMPLEX]
    Bertrand> will be rejected by the compiler, assuming COMPLEX is
    Bertrand> not a descendant of COMPARABLE.

    Bertrand> In the unconstrained case, a declaration such as LIST
    Bertrand> [G] is understood as an abbreviation for LIST [G ->
    Bertrand> ANY], where ANY is the ELKS class inherited by all
    Bertrand> classes. This makes it possible to apply objects of type
    Bertrand> G a wide range of operations applicable to all objects:
    Bertrand> equality comparison (redefinable in any class as long as
    Bertrand> it satisfies the original assertions), copying, cloning,
    Bertrand> even (in the latest version of ELKS) hash coding.

    Bertrand> Without going into the details, I should add that
    Bertrand> Eiffel's design for generics avoids the grave problems
    Bertrand> that one reads about in connection with C++ templates:

C++ templates are far from beeing perfect, that's true.  

    Bertrand> the need in C++ to generate code separately for each
    Bertrand> generic derivation (each new actual generic parameter),
    Bertrand> with its rather bad effect on compilation time
    Bertrand> ("template instantiation problem") and, as a result, the
    Bertrand> advice regularly given in the C++ literature to avoid
    Bertrand> using templates too much. In Eiffel, you can generate
    Bertrand> code just once (with some specific optimizations for
    Bertrand> basic types), without having to pay any performance
    Bertrand> overhead either at compile time or at run time. So you
    Bertrand> can use genericity as much as you like.  The ISE Eiffel
    Bertrand> libraries, for example, are generic throughout.

 
    Bertrand> In comparison with Eiffel, not even mentioning Java with
    Bertrand> its total lack of genericity, the other attempts at
    Bertrand> generic mechanisms that I have seen in an O-O context
    Bertrand> look to me rather half-hearted.

    Bertrand> I think Eiffel's consistent and complete treatment of
    Bertrand> genericity and inheritance is one of the reasons why
    Bertrand> some of the biggest successful industrial O-O projects
    Bertrand> have been produced in Eiffel. When the goal is not just
    Bertrand> to play around, but to build large, mission-critical
    Bertrand> systems, one needs the right combination of mechanisms,
    Bertrand> not just a partial attempt.

    Bertrand> For details about the Eiffel mechanism see the Eiffel
    Bertrand> language tutorial at http://www.eiffel.com.


    Bertrand> -- Bertrand Meyer, President, ISE Inc., Santa Barbara
    Bertrand> (California) 805-685-1006, fax 805-685-6869,
    Bertrand> <bertrand@eiffel.com> - ftp://ftp.eiffel.com Visit our
    Bertrand> Web page: http://www.eiffel.com (WITH FRAMES) or
    Bertrand> http://www.eiffel.com/noframes.html



Markus
-- 
+----------------------------------------------------------------------------+
| Markus Kohler                          Hewlett-Packard GmbH                |
| Software Engineer                      Network & System Management Division| 
|                                        IT/E Success Team                   |
+----------------------------------------------------------------------------+

Re: OO, C++, and something much better!

[Matthew Heaney]

In article <32D2E6C8.13728473@eiffel.com>, Bertrand Meyer
<bertrand@eiffel.com> wrote:

>In my opinion neither Ada (83 or 95) nor C++ has the combination
>of mechanisms making it possible to have the full power of
>generics in an object-oriented language, as present in Eiffel:
>
>        - Unconstrained genericity, to declare a class
>          as e.g. LIST [G], where G represents an arbitrary
>          type, so that you can then use LIST [SOME_TYPE] regardless
>          of what SOME_TYPE is.

Ada has had that ability since the original standard:

generic
   type List_Item is private;
package Lists is
   type List is private;
   procedure Add (Item : in List_Item; To : in out List);
...


>
>        - Constrained genericity, as in e.g. 
>          SORTED_LIST [G -> COMPARABLE], to require that
>          some operations be applicable to all actual
>          generic parameters. The rule is that
>          SORTED_LIST [SOME_TYPE] is permitted if and only
>          if SOME_TYPE inherits, directly or indirectly from
>          COMPARABLE. The -> symbol is evocative of the symbol
>          for inheritance used in class diagrams in e.g. B.O.N.
>          Within the class SORTED_LIST, any operation (feature, method)
>          of class COMPARABLE, such as infix "<" etc., is then applicable
>          to entities of type G.

There are 2 ways of doing that in Ada 95.

The first (what you could already do in Ada 83) is to require that the type
have a comparison operator:

generic
   type List_Item is private;
   with function "<" (Left, Right : List_Item) return Boolean is <>;
package Sorted_Lists is
   type List is private;
...

The second (new to Ada 95) is to require that the type inherit from another:

package P is
   type T is tagged private;
   function "<" (L, R : T) return Boolean;
...
end P;

with P;
generic
   type List_Item is new P.T;
package Sorted_Lists is
   type List is private;
...

>So in the constrained genericity case SORTED_LIST [INTEGER]
>will be permitted, since COMPARABLE is indeed an existing class,
>describing order relations and part of the Eiffel Library
>Kernel Standard, and INTEGER (also part of ELKS) does inherit
>from COMPARABLE.

I can instantiate my first sorted list package, because type Integer comes
predefined with a comparison operator.

with Sorted_Lists;
package Integer_Sorted_Lists is new Sorted_Lists (Integer);


>
>SORTED_LIST [TENNIS_PLAYER] will also be
>valid, assuming the user-defined class TENNIS_PLAYER inherits
>from COMPARABLE. But something like SORTED_LIST [COMPLEX]
>will be rejected by the compiler, assuming COMPLEX is not
>a descendant of COMPARABLE.

If tennis player has a comparison operator, then I can use sorted_list
version 1.

If tennis player derives from P.T, and I can use either sorted list version
1 or 2.

>In the unconstrained case, a declaration such as LIST [G]
>is understood as an abbreviation for LIST [G -> ANY], where
>ANY is the ELKS class inherited by all classes. This makes
>it possible to apply objects of type G a wide range of operations
>applicable to all objects: equality comparison (redefinable
>in any class as long as it satisfies the original assertions),
>copying, cloning, even (in the latest version of ELKS) hash
>coding.

Technically, I should modify the sorted list as follows:

generic
   type List_Item is private;
   with function "=" (L, R : List_Item) return Boolean is <>;
   with function "<" (L, R : List_Item) return Boolean is <>;
package Sorted_Lists is ...;

That way I can let the client pass in his "=" method that replaced the
predefined one for unlimited (private) types.


>In Eiffel, you can generate
>code just once (with some specific optimizations for basic types),
>without having to pay any performance overhead either at compile
>time or at run time. So you can use genericity as much as you like.

As you can in Ada.

>In comparison with Eiffel, not even mentioning Java with its total lack
>of genericity, the other attempts at generic mechanisms that I have seen
>in an O-O context look to me rather half-hearted.

P.J. Plauger once refered to C++ as having "ugly pragmatism."  I would say
about Ada 95 that it has "beautiful pragmatism."  We humans bandy about
terms like "purity," but there's no such thing in Nature; she only cares
about what works.  I think there's room for pragmatism, though C++ probably
pushes that argument a bit too far.  N'est-ce pas?

matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: OO, C++, and something much better!

[Robert Dewar]

Michael says

"ability to expand them at compile time without losing optimizations, unlike
Ada generics whose paradigm is to expand at run-time and remove staticness
from expressions."

incomprehensible confusion. there is no "run-time" expansion of generics'
in Ada, and there is no issue of losing optimizations ...

Re: OO, C++, and something much better!

[Robert Dewar]

iKen says

""Actually, back with Ada was a MIL-STD, there was a requirement to review
it
every _five_ years for updates."


Also it was an ANSI requirement, not a MIL-STD rqeuirement to initiate
review of the standard at a five year interval.

Re: What is wrong with OO ?

[Robert Dewar]

Bart said

"You shouldn't bother programmers with inlining. Inlining can be done
automatically by the compiler."

I don't see this is possible across modules without violating the integrity
of separation of specs and implementations.

Re: OO, C++, and something much better!

[Robert Dewar]

Ken writes

"Actually, back with Ada was a MIL-STD, there was a requirement to review
it
every _five_ years for updates. As I recall, no one wanted to do an
update
on the first cycle, in order to give implementations a chance to mature.
The
second cycle ended with Ada 95."

(Ken can you keep your lines from folding, makes it hard to read your posts)

This is rewriting history. Ada was standardized in 1983, and it is definitely
NOT the case that no one thought about a revision till 1993. On the contrary,
what happened is that people *did* start thinking about a revision in the
time period consistent with the five year rule -- this rule does not say
you need a standard every five years, just that you should start to think
about it. But the process from starting to think to standardizing Ada 95
was a very long process (6-7 years, I don't have the exact starting point).

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32D2E6C8.13728473@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

Wow.  The big folk are coming out.  Add in a couple others and the
whole thing might start looking like the Vorlons and Shadows! :-)

I'll play a Ranger (representing Ada, of course, ;-)


> In my opinion neither Ada (83 or 95) nor C++ has the combination
> of mechanisms making it possible to have the full power of
> generics in an object-oriented language, as present in Eiffel:

This is not surprising, ;-)

But,

> 	- Unconstrained genericity, to declare a class
> 	  as e.g. LIST [G], where G represents an arbitrary
> 	  type, so that you can then use LIST [SOME_TYPE] regardless
> 	  of what SOME_TYPE is.

This is in Ada95:
generic
    type G is private;
package List is...


> 	- Constrained genericity, as in e.g. 
> 	  SORTED_LIST [G -> COMPARABLE], to require that
> 	  some operations be applicable to all actual
> 	  generic parameters. The rule is that
> 	  SORTED_LIST [SOME_TYPE] is permitted if and only
> 	  if SOME_TYPE inherits, directly or indirectly from
> 	  COMPARABLE.

This too is in Ada95:

generic
    type G is new Comparable with private;
package Sorted_List is ...

Same instantiation constraints as in the Eiffel case...


> 	- True static typing (with no cast a la C++).

Yes, this is in Ada95 too.  In fact it is better in Ada95 since it
does not have system validity problems.


> 	- A completely consistent type structure, in which 
> 	  even basic types such as INTEGER are classes,
> 	  present in the general inheritance structure.
> 	  (In C++ or Java, for example, the basic types
> 	  are completely separate from the class and inheritance
> 	  structure.)

OK, here you have me.  But, Eiffel hedges a bit here as well with its
"expanded types".


> So in the constrained genericity case SORTED_LIST [INTEGER]
> will be permitted, since COMPARABLE is indeed an existing class,

Good point.  Lost a Minbari Cruiser on this one...


> In the unconstrained case, a declaration such as LIST [G]
> is understood as an abbreviation for LIST [G -> ANY], where
> ANY is the ELKS class inherited by all classes. This makes

Same as in Ada.


> it possible to apply objects of type G a wide range of operations
> applicable to all objects: equality comparison (redefinable
> in any class as long as it satisfies the original assertions),
> copying, cloning, even (in the latest version of ELKS) hash
> coding.

Here is where you actually get some more flexibility with Ada as you
can parameterize your generic (either the constrained or unconstrained
type) with more than just types.  You can specify complete signatures
including operations and/or packages as well.  What's more, these can
have constraints on them as well.  Of course, it doesn't have real
assertions, so I suppose this is kind of a wash...


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Paul Eric Menchen]

Ell wrote:
> 
> Nigel Tzeng (nigel@access4.digex.net) wrote:
> : In article <5a9r1k$e74@news4.digex.net>, Ell <ell@access1.digex.net> wrote:
...
> : Actually I think that one can make the case that the highest level was
> : predicated on a specific set of technology.  I'm going to speculate a
> : little here since I know virtually nothing about the actual 777 design
> : but here goes:
> :
> : Say they started with a specific weight goal for the airframe or they
> : couldn't get the performance they wanted out of the aircraft.  They
> : thought they could meet this goal through the use of composites.  The
> : choice of composites then bounds the high level airframe architecture
> : because of what you can and cannot do with composites (compare to say
> : conventional airframes made of metal).
> 
> I think we see the top level design in different ways.  I see it as a
> logical thing with no commitment to a technology.  In the above you are
> positing the use of "composites" up front.  My top level design would only
> incorporate the desire to meet a specific weight goal without commiting to

What is the top level? Why should the requirement be a weight goal?
You've already precluded solutions. If my design weighs twice as much
as your weight goal, but uses half as much fuel, shouldn't it be allowed
(presuming I've also handled other situations where weight might be an
issue)? In one way, the real requirement is one of operational cost.
Is the requirement to move people at a given cost? Then my Star Trek
transporter design shouldn't be precluded.

Reality is we have to start somewhere. Leave things too open, and you'll
discover requirements down the road you hadn't thought of; too closed
and you preclude solutions. Sometimes you may be wrong. Hopefully the
designer is smart and brave enough to point this out to you.

-Eric
-- 
    /-----------------------------------------
   /     /|  /| Paul Eric Menchen
  /---- / | / | emenchen@grci.com
 /     /  |/  | http://www.nicom.com/~zelkova <- soon!
/---------------------------------------------
The opinions expressed herein are strictly those of
the author and do not necessarily reflect those of GRCI.

Re: What is wrong with OO ?

[Russ McClelland]

> > Eiffel has multiple inheritance, genericity, exception handling, GC
etc.
> > since 1986.
> 
> The OO Lisp variants had MI in 1986. LOOPS and Flavors come immediately
to
> mind. CLOS may have been defined by then, but certainly was around in
1987
> (which means it had MI before C++ ) .
> 

Original versions of Smalltalk in the early 70's had MI.  Top that...

Re: What is wrong with OO ?

[Robert Dewar]

Jay, in typical fulminating mode says

 "It seems to me need for "pragma inline" and "inline" is/was social.
 It came from compiler writers continually slacking off since the 60's
 and not implementing inlining."

nonsense, all decent compilers implement inlining today, it is a more
vital optimization than ever because of icache considerations (particularly
in direct addressed caches).

The pragma inline in Ada is simply a permission to create a dependence
on the body, it has nothing to do with what you think of informally as
inlining.

In a large project it is essential not to accidentally create interunit
dependences so that a small change to one unit causes millions of lines
to need to be recompiled.

There is of course no problem in implementing automatic inlining within
a unit. As I said earlier, virtually all production compilers do this,
including of course GCC.

The problem is that you definitely do NOT want the compiler rushing off
and creating unlimited body dependencies (think interunit dependencies
if you don't want to think Ada specifically) by doing automatic interunit
inlining.

Still some interunit inlining is highly desirable especially with
heavy layering of abstractions. But you want to give the programmer
some control, to avoid the problem of inter-unit dependencies running
amok!

Re: What is wrong with OO ?

[Bjarne Stroustrup]

Bart Samwel <bsamwel@wi.leidenuniv.nl> writes:

 > 
 > Bjarne Stroustrup wrote:
 > 
 > > Only where I couldn't find a solution that fitted in C++'s general
 > > framework and met my criteria for run-time efficiency, ease of
 > > implementation, ease of teaching, etc. (see D&E Chapter 4), did I
 > > feel compelled to try to invent something.
 > 
 > When I read this, a lot of questions pop up in my head. I'll ask only
 > one: You've only included features that didn't compromise ease of
 > teaching (at least, that's my interpretation of what you wrote). Why is
 > it then, that C++ contains so many hidden 'features' (or rather,
 > non-explicit rules) that confuse people, at least at my university?

In addition to giving an answer to you ``only one'' question, I will
comment on some of the pretty strong statement you made afterwards -
lest silence should be taken for agreement, lack of counter arguments,
or arrogance.

I'm not sure which hidden_features/non-explicit_rules you are referring
to, but I do have some experience with the teaching, learning, and use
of C++ that might be relevant.


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

	This is a secondary rule for choosing between alternatives.
	It is tricky to apply because it can be an argument for logical
	beauty and also for sticking to the familiar. Writing tutorials
	and reference manual descriptions to see how easy they are for
	people to understand is a practical application of this rule.
	One intent is to ease the task for educators and support personnel.
	It is important to remember that programmers are not stupid;
	simplicity mustn't be achieved at the expense of important
	functionality.

It is one of about twenty such rules of thumb I rely on.


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

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.

That, together with the common mistake of chosing "all of C" as the
initial subset of C++ to learn have led many into trouble. These problems
are avoidable. In particular, only a relatively small part of the common
C and C++ subset needs to be understood before one can approach the
abstraction mechanisms that are the essential part of C++.

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.

C++ now has a nice standard library and most implementation now are shipped
with a reasonable approximation to it. However, the effects of its initial
absence (primarily my fault) still lingers in teaching methods and teaching
materials.

C++ caught on very fast. This led to people "joining the bandwagon"
without actually understanding what the important ideas were. Many times,
I have cringed seeing what riduculous statements were made about C++
and its proper use. For example, an early textbook proudly gave an
airplane derived from an engine as its first example of object-oriented
programming. Naturally, that author had never written a real C++ program
in his life or a real program in any other programming language supporting
object-oriented programming. Fortunately, he later jumped on another
bandwagon and is now pushing some other OO language.

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.

I provide more details about learning and teaching C++ in "The Design
and Evolution of C++" (D&E) and on my homepages. C++ can be - and often
is - taught effectively to people of a wide variety of backgrounds and
with widely varying needs.


 > As far as I'm concerned, C++ is not a language for teaching. It has too
 > many of these implicit rules to be logical, and the fact that it
 > doesn't have garbage collection and does have pointers really makes it
 > error-prone; especially for beginning programmers, this is not a good
 > thing. They should be writing WHAT should be done, and ALL that should
 > be done; they shouldn't be bothered with the 'how' part of programming,
 > like (with alternatives): memory management (garbage collection),
 > pointers (references), virtual functions (can be detected by the
 > compiler). They should not be bothered with implicit rules (like the
 > multiple inheritance rules, for instance) that they have to know of,
 > before using multiple inheritance.
 > 
 > C++ is an excellent language as an extension to C, but C is altogether
 > obsolete and much too low-level, except for systems programming, and
 > other languages are now available for writing high-level software.
 > Many people make the (IMO huge) mistake of using C++ for high-level
 > software projects, leading to buggy results and, often, lots of core
 > dumps. Programmers are not perfect, and C++ expects them to be so by
 > providing too many ways of making mistakes.

I'm not sure about what you call a "high-level software project" but
C++ has been applied successfully often enough for your description
of the results of using C++ to be a carricature. There has been failures
involving every programming language that has ever been used for
production code. Since there has been more use of C++ than for any
other comparable language, I would expect there to have been more
with C++. However, I use C++ software daily that doesn't dump. There
are many C++ programs out there that works correctly month in and month
out. Reliability and mainatainability can be eased by a programming
language (such as C++) but is the result of a more comprehensive
process.

C++ is a programming language, so it doesn't have expectations, but I
- as its designer - never suffered from the delution that programmers
were anywhere near perfect. Nor did I suffer from the delusion that
I knew enough to put restrictions in place to constrain every programmer
without exception or escape.


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


 > > Much of C++'s success has to do with fitting into existing
 > > environments and being compact and fast (yes, I know that these are
 > > not the aspects of C++ that are currently emphasized in the
 > > MS Windows world). The speed and compactness of code generated from
 > > C++ depends on a few fundamental design decisions that I think were
 > > novel at the time:
 > 
 > Speed and compactness is certainly a goal that C++ has achieved. But it
 > did not achieve one major goal: ease of use.

I wonder how you would measure ``ease of use'' objectively. For starters:
``ease of doing what kind of work?'' ``ease for whom?'' C++ isn't the
easiest programming language to learn and to use, but for a rather large
range of systems, a large range of applications, and a large range of
developer communities, it seems to be the easiest language out of those
that can actually help get the work done.

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.


 > >         C++ offers inline member and non-member functions with zero
 > >         overhead compared to macros.
 > 
 > You shouldn't bother programmers with inlining. Inlining can be done
 > automatically by the compiler.

Not really. Some compilers can do some inlining well, but for larger
programs the compiler is hampered by having incomplete information
and by not having a particularly good idea of what optimizations are
relevant in various part of the code. Explicit inlining is a pretty
good way of giving programmers some control for the common cases where
a compiler isn't smart enough without tying users up with proprietary
and non-standard control features. Used well, inlining can make a major
difference in speed and code compactness.


 > >         C++ offers its form of dynamic (run-time) resolution, virtual
 > >         functions, with low and fixed overhead compared to ordinary
 > >         function calls (20% to 100% dependent of implementation).
 > 
 > Virtual functions must be explicitly specified. This can be done by the
 > compiler. And, virtual functions must be specified in the ancestor
 > class; this means that when a class designer forgot to put that in
 > (and this happens often), I can't redefine the function correctly.

Deciding which member functions should be virtual is a design decision,
not an optimization. If a designer has provided a poor base class, you
will typically have problems beyond what can be fixed by overriding.


 > > Over the years, C++ has evolved within a framework that was reasonably
 > > well understood early on.
 > 
 > Well understood, yes. But the framework is now obsolete, and it has
 > some serious design flaws that also bother C++ users.

Certainly there are flaws - I don't know of a language that doesn't have
flaws, and I consider the idea of a widely-used flawless language nonsense.

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 do not consider C++ or its basic conceptual framework obsolete nor
do I know an alternative that could replace it in the next few years.
Like it or not, programming languages have lifecycles that span decades,
and "obsolete" often means little more than "not in accordance with the
latest fad." For most builders of real-world software a ten-year-old
language is a newborn. ``OO'' itself is more than 25 years old and we
are still learning about it - even those of us who have been part of the
process through most of those years.

The world is a whole lot messier than we would like it to be, and some of
that messiness is reflected in every successful programming language.

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
	
 
 >    Bart Samwel  (bsamwel@wi.leidenuniv.nl)
 > 
 > 

Re: OO, C++, and something much better!

[Don Harrison]

Jon S Anthony writes:

:In article <32D2E6C8.13728473@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:
:
:Wow.  The big folk are coming out. 

:)

:> 	- Unconstrained genericity, to declare a class
:> 	  as e.g. LIST [G], where G represents an arbitrary
:> 	  type, so that you can then use LIST [SOME_TYPE] regardless
:> 	  of what SOME_TYPE is.
:
:This is in Ada95:
:generic
:    type G is private;
:package List is...

Yes.

:> 	- Constrained genericity, as in e.g. 
:> 	  SORTED_LIST [G -> COMPARABLE], to require that
:> 	  some operations be applicable to all actual
:> 	  generic parameters. The rule is that
:> 	  SORTED_LIST [SOME_TYPE] is permitted if and only
:> 	  if SOME_TYPE inherits, directly or indirectly from
:> 	  COMPARABLE.
:
:This too is in Ada95:
:
:generic
:    type G is new Comparable with private;
:package Sorted_List is ...
:
:Same instantiation constraints as in the Eiffel case...

Yes. However, I'm not sure whether you lose some of the power of combining 
genericity with inheritance through Ada's module-type distinction. Since 
genericity in Ada is essentially module-based and inheritance is type-based,
I suspect you may lose something here.

:> 	- True static typing (with no cast a la C++).
:
:Yes, this is in Ada95 too.  

No. Ada offers type casting in a couple of ways:

  1) UNCHECKED_CONVERSION and
  2) Address representation clauses (overlays).

Eiffel, by contrast, has no such thing in the standard language. That isn't 
to say it isn't needed for some things (and is why some vendors do provide 
type conversion between basic types and bits, for example). 

I have been trying to think of a safe way of doing this sort of thing but
thus far haven't thought of any. :) 

:In fact it is better in Ada95 since it
:does not have system validity problems.

Perhaps not the same kind of problems. But it's dead easy to write 'system
invalid' Ada which will result in runtime errors. For example, by using the 
value of a parent type where a subrange value is required.

[...]

:> it possible to apply objects of type G a wide range of operations
:> applicable to all objects: equality comparison (redefinable
:> in any class as long as it satisfies the original assertions),
:> copying, cloning, even (in the latest version of ELKS) hash
:> coding.
:
:Here is where you actually get some more flexibility with Ada as you
:can parameterize your generic (either the constrained or unconstrained
:type) with more than just types.  You can specify complete signatures
:including operations and/or packages as well.  What's more, these can
:have constraints on them as well.  

Yes. However, these kinds of formal parameters are only needed in Ada because
it distinguishes between module and type. Eiffel's unification of module and
type obviates the need for them. :)  Eiffel's genericity mechanism is also
simpler because it is a *pure* OOPL compared to hybrid Ada.

:Of course, it doesn't have real
:assertions, so I suppose this is kind of a wash...


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Bart said
>
>"You shouldn't bother programmers with inlining. Inlining can be done
>automatically by the compiler."
>
>I don't see this is possible across modules without violating the integrity
>of separation of specs and implementations.

So?  Why is it so important to preserve the "integrity of separation"?

I prefer compilers that provides a full range of trade-offs between
(re)compilation speed and the efficiency of the generated code.  In
most circumstances, programmers are best served by a compiler that
compiles fast during development (when you want to avoid cross-module
inlining, to avoid unnecessary recompilation) but that can pull out all
stops for the optimized version.

There are times when you want optimizations yet you want to avoid
cross-module optimizations, but those should be exceptions;
automatic cross-module inlining ought to be the norm.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Richie Bielak]

Fergus Henderson wrote:

[...]
 
> I prefer compilers that provides a full range of trade-offs between
> (re)compilation speed and the efficiency of the generated code.  In
> most circumstances, programmers are best served by a compiler that
> compiles fast during development (when you want to avoid cross-module
> inlining, to avoid unnecessary recompilation) but that can pull out all
> stops for the optimized version.
> 
> There are times when you want optimizations yet you want to avoid
> cross-module optimizations, but those should be exceptions;
> automatic cross-module inlining ought to be the norm.
> 

Optimizations that require global analysis of all the classes
of a program at compile time do not work if we need dynamic loading
of classes at runtime, because adding a new class to a running system
may invalidate optimizer's assumptions.

...richie

-- 
* richieb@netlabs.net       - at home |  Richie Bielak             *
* richieb@calfp.com         - at work |                            *
*          Home page:   http://www.netlabs.net/hp/richieb          *
*        "Fight software piracy, use free software!" (me)          *

Re: What is wrong with OO ?

[William Clodius]

Robert Dewar wrote:
> 
> Bart said
> 
> "You shouldn't bother programmers with inlining. Inlining can be done
> automatically by the compiler."
> 
> I don't see this is possible across modules without violating the integrity
> of separation of specs and implementations.

There are two aspects of the concept of integrity logical and physical.
Inlining disobeys physical integrity, but obeys logical integrity if the
final result of the computation does not ("significantly") affect the
final result of a computation. Under the "as if" rules of most
standards, the compiler writer should primarilly concerned with logical
consistency. However, as the inlining can result in intermodule
dependencies that, on modification of the module containing the inlined
code, can result in a chain of recompilations, I would probably not
recomend that such inlining be the default for the compiler, but it is
certainly allowable (perhaps advisable) as an optional switch in the
compilation process.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: What is wrong with OO ?

[Simon Willcocks]

In article <dewar.852772995@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) says:
>
>Bart said
>
>"You shouldn't bother programmers with inlining. Inlining can be done
>automatically by the compiler."
>
>I don't see this is possible across modules without violating the integrity
>of separation of specs and implementations.
>
I take it you're coming from an Ada perspective, where each package can
be separately compiled without any information from other packages'
implementations?

I think that even in this case inlining could be done by a suitable linker,
provided the compiler could mark parts of object code as suitable for inlining.
The linker could insert the relevant code in place of the call statement,
rather than just setting the location to be called.

Simon Willcocks

Re: OO, C++, and something much better!

[Ted Dennison]

Robert Dewar wrote:
> 
> Ken writes
> 
> "Actually, back with Ada was a MIL-STD, there was a requirement to review
> it
> every _five_ years for updates. As I recall, no one wanted to do an
> update
> on the first cycle, in order to give implementations a chance to mature.
> The
> second cycle ended with Ada 95."
> 
> (Ken can you keep your lines from folding, makes it hard to read your posts)

In particular, when your newsposter automaticly wraps text for you, you
really have no choice but to let it. Trying to terminate lines manually
will just lead to tough to read text. But its a damn tough habit to get
out of, once you are used to hitting that return key at the end of the
line.

> This is rewriting history. Ada was standardized in 1983, and it is
> definitely NOT the case that no one thought about a revision till
> 1993. On the contrary, what happened is that people *did* start 
> thinking about a revision in the time period consistent with the five

Does that mean that they ALSO started thinking about the revision again
in 1993, even though the Ada 95 effort was well underway?  ;-)




-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: What is wrong with OO ?

[Bertrand Meyer]

Robert Dewar wrote:
> 
> Bart said
> 
> "You shouldn't bother programmers with inlining. Inlining can be done
> automatically by the compiler."
> 
> I don't see this is possible across modules without violating the integrity
> of separation of specs and implementations.


The ISE Eiffel compiler performs inlining completely automatically.
There is no "pragma inline" or comparable programmer intervention,
since it is not the programmer's job to worry about whether a routine
is inlinable or not. This is a job for a compiler.

(In addition, for an object-oriented language, inlining is only
possible for a routine that is never subject to dynamic binding.
This requires extensive analysis of the software. If the programmer
requests
inlining but it is semantically wrong, the compiler should ignore
the request. But then if the compiler is capable of doing this analysis
it should take care of the inlining too, without bothering the
programmer!)

ISE Eiffel does give the user a degree of parameterization:
a compilation option specifies the size threshold beyond which
a routine will not be inlined. This is measured in internal units
(number of bytecode words), but easy to relate to number of
instructions. This option provides a way to control space-time
tradeoffs. In practice, however, most users are happy with the
default, which inlines small, frequently called routines.

This automatic optimization is crucial because the object-oriented
style of development, with its emphasis on  abstraction, naturally
tends to yield many small routines. With ISE Eiffel, you can write the
software as it should be, not asking yourself all the time "should
I violate abstraction here and avoid writing a small routine because
of the effect on performance?". You just leave this kind of concern
to the compiler. ("Inline" pragmas would be almost worse here, because
you would have to perform yourself the analysis of what is inlinable
and what is not. The incrementality problem is particularly nasty:
change a single line somewhere in a large system, and a routine that was
inlinable,
far away in the software text, now becomes  non-inlinable! This
kind of systematic, exhaustive  work, error-prone when done
by humans, is what computers are for.)

I also think that the Eiffel view of "separation of specs and
implementations"
is more sophisticated than Ada's one (which I assume is the one Robert
Dewar has in mind), but that will be the topic for another debate...



-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com  or
http://www.eiffel.com/noframes.html
	(includes instructions for downloading ISE Eiffel 4 for Windows)

Re: OO, C++, and something much better!

[Bertrand Meyer]

Robert I. Eachus wrote:
> 
> 
>       Bertrand Meyer said:
> 
>    > In my opinion neither Ada (83 or 95) nor C++ has the combination
>    > of mechanisms making it possible to have the full power of
>    > generics in an object-oriented language, as present in Eiffel...
> 
>      And then listed four properties, all of which are in Ada 95!

I disagree. What Mr. Eachus showed in his message is ways to achieve
in Ada 95 the effect of the object-oriented mechanisms I described,
as implemented in Eiffel. And he is correct that one can use Ada 95
to obtain many of the same goals. (This would not be true, for example,
of C++ and even less of Java.) But this does not mean the "four
properties" that I listed are in Ada 95. Anyone who checks my
message and the Ada 95 language definition will see that.


To the four properties listed in my original I should also add two
just as essential requirements: true multiple inheritance, for combining
different abstractions (and with the right mechanisms to avoid any
ambiguity or conflict); and, most importantly, Design by Contract
and the rules on how assertions combine with inheritance. As someone
remarked, it is really impossible to understand inheritance without
understanding Design by Contract.


At some point, of course, one runs into matters of taste. I will
again contend, however, that a rational, systematic analysis of
O-O principles and how they combine with genericity, information hiding
and other software engineering concerns almost inevitably lead to the
Eiffel mechanisms.

-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: What is wrong with OO ?

[Ken Garlington]

Robert Dewar wrote:
> 
> Bart said
> 
> "You shouldn't bother programmers with inlining. Inlining can be done
> automatically by the compiler."
> 
> I don't see this is possible across modules without violating the integrity
> of separation of specs and implementations.

Actually, with some Ada compilers, you _can_ do inlining automatically,
by
setting the optimization level high enough.
--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: What is wrong with OO ?

[Robert Dewar]

Simon said

'I take it you're coming from an Ada perspective, where each package can
be separately compiled without any information from other packages'
implementations?

I think that even in this case inlining could be done by a suitable linker,
provided the compiler could mark parts of object code as suitable for inlining.
The linker could insert the relevant code in place of the call statement,
rather than just setting the location to be called."


Right (Ada persepective, and indeed C is the same, where you see the headers
and not bodies of other units).

Inlining is MUCH more than just sticking in the code at the point of call
and cannot be done at all by a stupid linker. The whole point of inlining
is that you optimize the code that is inserted, minimally by increasing
scheduling opportunities, but in the presence of global optimization, knowing
what the body of a procedure does and does not do can buy a great deal. The
elimination of the call itself is small stuff compared to the other gains.

Re: OO, C++, and something much better!

[Don Harrison]

David Emery writes:

:>> 	- A completely consistent type structure, in which 
:>> 	  even basic types such as INTEGER are classes,
:>> 	  present in the general inheritance structure.
:>> 	  (In C++ or Java, for example, the basic types
:>> 	  are completely separate from the class and inheritance
:>> 	  structure.)
:>
:>OK, here you have me.  But, Eiffel hedges a bit here as well with its
:>"expanded types".
:
:I think that there is not a clear consensus on this as A Good Thing.
:From a practical perspective, there seems to be a significant price to
:pay for 'full generality' (e.g. integers are classes just like
:user-defined record types.)  Java, for instance, has primitive integer
:types, and my understanding that the reason for this is performance,
:pure and simple.  Making 'int' a class would result in unacceptable
:performance, both compile-time and runtime, for simple things like
:"a[i++] := b + c;" (for int a, b, c).

Eiffel expanded types (one of which is class INTEGER) are not accessed via
references so do not carry that overhead. Hence, they can be implemented as 
efficiently as Ada/C++ integers.

However, if you *do* need to define a more specific integer type, you can
inherit from the parent (reference) type, INTEGER_REF.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Jay Martin]

Bertrand Meyer <bertrand@eiffel.com> writes:

>Robert Dewar wrote:
>> 
>> Bart said
>> 
>> "You shouldn't bother programmers with inlining. Inlining can be done
>> automatically by the compiler."
>> 
>> I don't see this is possible across modules without violating the integrity
>> of separation of specs and implementations.


>The ISE Eiffel compiler performs inlining completely automatically.
>There is no "pragma inline" or comparable programmer intervention,
...

It seems to me need for "pragma inline" and "inline" is/was social.
It came from compiler writers continually slacking off since the 60's
and not implementing inlining.  Its hard to blame them as it didn't
seem a market priority due a totally irresponsible and incompetent
Computer Science Academia which produced a generation of programmers
who think "C" is Computer Science and had the attitude that it was the
job of programmers not compilers to do optimizations and said such
things as "I do low level pointer arithmetic so that my COMPILER runs
faster (a top UC Berkeley Graduate).  Pragma inline gave us a hammer
to which to pound the compiler writers into submission.

Jay

Re: What is wrong with OO ?

[Robert Dewar]

"So?  Why is it so important to preserve the "integrity of separation"?"

  No comment, let's just say that there are those of us who think the
  separation at an abstract level between specification and implementation
  is important. I am quite aware that there lots of C programmers who not
  only don't agree, they don't even understand what I am talking about!!

There are times when you want optimizations yet you want to avoid
cross-module optimizations, but those should be exceptions;
automatic cross-module inlining ought to be the norm.

  I think not. You can only do cross-module inlining if every compilation
  potentially recompiles code for the entire application. This seems out
  of the question in large applications.

  It seems to me here that the Ada approach is just right. Fergus, if you
  are aware of the Ada approach, what would you change?

Re: OO, C++, and something much better!

[Robert Dewar]

Don Harrison says

"No. Ada offers type casting in a couple of ways:

  1) UNCHECKED_CONVERSION and
  2) Address representation clauses (overlays).

Eiffel, by contrast, has no such thing in the standard language. That isn't
to say it isn't needed for some things (and is why some vendors do provide
type conversion between basic types and bits, for example).

I have been trying to think of a safe way of doing this sort of thing but
thus far haven't thought of any. :)"


Well there obviously is no safe way of doing something whose entire purpose
is to allow unsafe operations!

Still I would not characterize these as "type casting" in Ada. Rather I 
would think of them as loopholes, equivalent to calling a C or assembly
routine. Any formal analysis or discussion of the type system of Ada
has to ignore these features, and of course any real language to be used
for low level systems programming needs such features, but I don't think
it is a useful excercise to include these features in the type analysis.

If you like, consider Ada *minus* these two features as the interesting
language to be analyzed. Then understand that in real life programs can
break the bounds of this analysis to the extent they need to.

Note that it is not actually the unchecked conversion that is nasty, since
the fundamental conversion can be modeled as simply a random mapping between
values of one type to values of another type. It is that these operations
can generate abnormal values. 

This may still not be a problem, given that uninitialized values can also
be abnormal, thus:

  a := nasty_unchecked_conversion (b);

is no worse that not assigning to a at all if a is uninitialized.

Re: What is wrong with OO ?

[Robert Dewar]

Bertrand says

"This automatic optimization is crucial because the object-oriented
style of development, with its emphasis on  abstraction, naturally
tends to yield many small routines. With ISE Eiffel, you can write the
software as it should be, not asking yourself all the time "should
I violate abstraction here and avoid writing a small routine because
of the effect on performance?". You just leave this kind of concern
to the compiler. ("Inline" pragmas would be almost worse here, because
you would have to perform yourself the analysis of what is inlinable
and what is not. The incrementality problem is particularly nasty:
change a single line somewhere in a large system, and a routine that was
inlinable,
far away in the software text, now becomes  non-inlinable! This
kind of systematic, exhaustive  work, error-prone when done
by humans, is what computers are for.)"


This misunderstands the function of pragma Inline in Ada. This is NOT
a directive that the compiler should inline the function, not at all,
it is simply a permission to establish a compilation dependency on the
body, an obvious prerequisite for permitting the inlining.

If you want to let the compiler do unlimited automatic inlining, then 
you simply label every visible function as being pragma Inlined. Then
the compiler has complete freedom to inline anything. Of course it will
still only inline things if it makes sense to do so, which is something
that requires a lot of low level input (just measuring the number of
bytes of code is far too crude).

If it was consdered useful to allow unlimited inlining in Ada, it would
be trivial, and very much within the spirit of the language to add a
configuration pragma Inline_All (implementations of Ada are allowed to
add such configuration pragmas, or it could simply be a compiler switch).

To implement such a switch would be about thirty minutes work in GNAT, but
I doubt it would be found to be of much use in practice, certainly no one
has indicated an interest in such a switch. On the contrary, in large 
programs, people are VERY concerned about compilation dependencies. If
any change to any unit requires recompiling ten million lines of code,
then even with a fast compiler, the impact on development productivity
is worrisome.

Re: OO, C++, and something much better!

[Don Harrison]

Mark A Biggar writes:

:Of course there is nothing that requires 
:that the provided function realy be a less-than function (which is usefull
:as providing a ">" instead reverses the order of the list) but Eiffel has the
:same problem and there is no guarentee that a class derived from COMPARABLE
:hasn't redefined "<" to do something else either.

While it wouldn't be possible in this case, a level of confidence can be 
provided in other situations using Eiffel postconditions.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Ken Garlington]

Bertrand Meyer wrote:
> 
> ISE Eiffel does give the user a degree of parameterization:
> a compilation option specifies the size threshold beyond which
> a routine will not be inlined. This is measured in internal units
> (number of bytecode words), but easy to relate to number of
> instructions. This option provides a way to control space-time
> tradeoffs. In practice, however, most users are happy with the
> default, which inlines small, frequently called routines.

This is the way the Ada compilers we use work as well. Here is an
excerpt from one of the compiler manuals:

Optimize=<argument>, where <argument> is:

minimum  - pragma Inlines are not obeyed.
low      - pragma Inlines are not obeyed.
standard - some inline expansion
time     - aggressive inline expansion
space    - inline expansion only if smaller code results

This is, of course, compiler specific (outside the language standard).
I assume this is the case for Eiffel as well, since you called out a
specific compiler implementation?

> This automatic optimization is crucial because the object-oriented
> style of development, with its emphasis on  abstraction, naturally
> tends to yield many small routines. With ISE Eiffel, you can write the
> software as it should be, not asking yourself all the time "should
> I violate abstraction here and avoid writing a small routine because
> of the effect on performance?". You just leave this kind of concern
> to the compiler. ("Inline" pragmas would be almost worse here, because
> you would have to perform yourself the analysis of what is inlinable
> and what is not. The incrementality problem is particularly nasty:
> change a single line somewhere in a large system, and a routine that was
> inlinable,
> far away in the software text, now becomes  non-inlinable! This
> kind of systematic, exhaustive  work, error-prone when done
> by humans, is what computers are for.)

This is the way we approach our Ada software, as well. We generally use
pragma
Inline for extreme cases, where we know that our choice is smarter than
the
compiler's...

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <E3nFFy.C17@research.att.com> ark@research.att.com (Andrew Koenig) writes:

> > However, if I remember correctly, Alex Stepanov had earlier tried to
> > implement a library like the C++ STL in Ada, but was incapable of
> > doing it. This would indicate that the C++ template mechanism is more
> > flexible than the Ada generics.
> 
> What Alex told me about that effort was that he was unable to find
> a single Ada compiler that implemented the standard accurately enough
> to enable him to do what he wanted to do with his library.

 10+ years ago...  I wonder how well then he would have been able to
get a C++ compiler to do anything with any kind template ...  AFATG,
_today's_ C++ compilers have had more than their share of trouble with
these - and with the STL too.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Robb Nebbe]

Bertrand Meyer wrote:
> 
> Robert I. Eachus wrote:
> >
> >
> >       Bertrand Meyer said:
> >
> >    > In my opinion neither Ada (83 or 95) nor C++ has the combination
> >    > of mechanisms making it possible to have the full power of
> >    > generics in an object-oriented language, as present in Eiffel...
> >
> >      And then listed four properties, all of which are in Ada 95!
> 
> I disagree. What Mr. Eachus showed in his message is ways to achieve
> in Ada 95 the effect of the object-oriented mechanisms I described,
> as implemented in Eiffel. And he is correct that one can use Ada 95
> to obtain many of the same goals. (This would not be true, for example,
> of C++ and even less of Java.) But this does not mean the "four
> properties" that I listed are in Ada 95. Anyone who checks my
> message and the Ada 95 language definition will see that.

Actually anyone who checks your message and the Ada language definition
will see that Ada provides direct support for the four properties you
listed but of course it doesn't use the same terminology (constrained
and unconstrained genericity) as Eiffel. 

Robb Nebbe

Re: OO, C++, and something much better!

[Matt Austern]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]


kst@aonix.com (Keith Thompson) writes:

> In <dewar.852652911@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> > Actually, when I talked to Alex, he indicated that there were critical
> > features in Ada 95 that were missing in C and C++ for this kind of
> > work. In particular, he noted that C lacks a general address comparison
> > operation, useful for hashing data structures, whereas Ada does have such
> > an operation (in System.Storage_Elements on type Integer_Address). It is
> > a bit ironic to identify this particular feature as crucial (since most
> > people mistakenly think that C has such a feature and Ada doesn't!)
> 
> Well, sort of.
> 
> It's true that C pointer comparison is undefined unless the pointers being
> compared point into the same object (or one past the end of an array).
> However, any real-world C implementation isn't going to go out of its
> way to make such comparisons invalid.  If pointers "look like" integers
> at the hardware level, pointer comparison is almost certainly going to be
> implemented as integer comparison.  It may be signed or unsigned, but it's
> almost certainly going to be consistent within a given implementation.

Since this article is posted to several different groups, including 
comp.lang.c++, I'd like to point out that the situation in C and in 
C++ is somewhat different.

Keith's description is correct in the case of C.  In C++, though, it's
only part of the story.  Pointer comparison in C++ using the <
operator does work just the way that he says; C++ didn't change the
meaning of the < operator.  However, C++ includes another way of
comparing the magnitude of two values: the standard library function
object less<T>.  

Operator< isn't necessarily a total ordering on pointers, but less<T>
is.  To quote the draft standard (section 20.3.3): "For templates
greater, less, greater_equal, and less_equal, the specializations for
any pointer type yield a total order, even if the built�in operators
<, >, <=, >= do not."

Re: OO, C++, and something much better!

[Marky Mark]

Don Harrison <donh@syd.csa.com.au> wrote in article
<E3rDu6.7AJ@syd.csa.com.au>...
> David Emery writes:
> 
> :>> 	- A completely consistent type structure, in which 
> :>> 	  even basic types such as INTEGER are classes,
> :>> 	  present in the general inheritance structure.
> :>> 	  (In C++ or Java, for example, the basic types
> :>> 	  are completely separate from the class and inheritance

Besides, in a hybrid language like C++ you could always have the best of
both worlds - encapsulating integers as classes or using the intrinsics as
you'd like.

Re: What is wrong with OO ?

[Marky Mark]

All you guys are talking about is inlining some code!!  Is it really worth
this long thread?

Re: What is wrong with OO ?

[Ken Garlington]

Fergus Henderson wrote:

> Hence this control should normally be expressed via
> compiler options, rather than being embedded in the source code.

However, you can't usually specify compiler options in a language
definition.
In practice, many of the capabilities expressed in the Ada language spec
as
pragmas are often available as compiler options, including pragma
Inline.

> 
> --
> Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
> WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
> PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <E3q536.31D@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> Jon S Anthony writes:
> 
> :This too is in Ada95:
> :
> :generic
> :    type G is new Comparable with private;
> :package Sorted_List is ...
> :
> :Same instantiation constraints as in the Eiffel case...
> 
> Yes. However, I'm not sure whether you lose some of the power of combining 
> genericity with inheritance through Ada's module-type distinction.

I have never seen any example supporting your "unease" - by you or
anyone else.

> genericity in Ada is essentially module-based and inheritance is type-based,
> I suspect you may lose something here.

Presumably you forgot to add "only" to "inheritance is type-based".
But this is just plain false.  Counter-examples are everywhere.


> :> 	- True static typing (with no cast a la C++).
> :
> :Yes, this is in Ada95 too.  
> 
> No. Ada offers type casting in a couple of ways:
> 
>   1) UNCHECKED_CONVERSION and
>   2) Address representation clauses (overlays).

1. This is not "casting"
2. It's irrelevant anyway as these are type system trap doors (outside
   the type system).
3. Ada _is_ statically safer than Eiffel as it avoids broken polymorphism.

> Eiffel, by contrast, has no such thing in the standard language. That isn't 

Irrelevant.

> :In fact it is better in Ada95 since it
> :does not have system validity problems.
> 
> Perhaps not the same kind of problems. But it's dead easy to write 'system
> invalid' Ada which will result in runtime errors.

Only if you _intentionally_ do so - by using UC in a dodgy way.  You
won't get it "by accident".


> For example, by using the value of a parent type where a subrange
> value is required.

Give an example.  This sort of thing will be statically checked.


> :Here is where you actually get some more flexibility with Ada as you
> :can parameterize your generic (either the constrained or unconstrained
> :type) with more than just types.  You can specify complete signatures
> :including operations and/or packages as well.  What's more, these can
> :have constraints on them as well.  
> 
> Yes. However, these kinds of formal parameters are only needed in Ada because
> it distinguishes between module and type.

Nah.  That's irrelevant to why they are there.  They are there, as
Rober Eachus points out, because you have the flexibility of not
_only_ organizing your structures strictly hierarchically.  Or _only_
on type.


> simpler because it is a *pure* OOPL compared to hybrid Ada.

Pure, schmure.  No programming language is "pure" in my estimation.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Robert Dewar]

Keith says

"On the other hand, for Ada 95, RM95-13.7.1(16) says that "Operations that
do not make sense should raise Program_Error".  The AARM (Annotated Ada
Reference Manual) gives the examples of X < Y and conversions between
Integer_Address and Address on a segmented architecture.  (Note also that
it's not necessary to use System.Storage_Elements; relational operators
on type Address are provided in System.)"

Nope, you are reading too much into the RM here. Also reading the AARM
is always a risky business (remember it is just opinion, nothing more :-)

Let's take the case of a segmented architecture. It is common for C
compilers in such environments (Large mode on the 8086) to limit objects
to 64K bytes and to compare ONLY the offset parts of the addresses
so that address comparison onlly works when it is defined to work, and
gives silent junk answers when used between different objects. One neither
expects nor encounters Keith's supposed "reasonable" behavior where this
is likely to work.

If we look at the corresponding Ada case, I cannot see any justification
whatsoever for not properly allowing conversoin of any possible segmented
address to an integer address. Such an operation makes perfect sense in
this environment and is therefore REQUIRED TO BE SUPPORTED! You are only
allowed to raise PE for things that do not make sense. Since this machine
has a well define notion of linear address, it is clear to me that (a) any
implementor on this environment would provide the obvious conversion and
(b) that if they did not, they could not seek refuge in the RM.

Let's actually look at the AARM wording, it says, if we quote it in full,
rather than paraphrase as Keith did:

        16.a   Discussion:  For example, on a segmented architecture, X < Y
        might raise Program_Error if X and Y do not point at the same segment
        (assuming segments are unordered).  Similarly, on a segmented
        architecture, the conversions between Integer_Address and Address
        might not make sense for some values, and so might raise Program_
        Error.

Why this "for some values", that's becuse the conversoin in the opposite
direction from Integer_Address to Address is indeed problematical, and
one might well decide to raise Program_Error for some values in this
direction.

Keith's point that there is a comparison operation on addresses directly
is true, but it is not a good idea to use these operations, since it is
indeed sensible to decide that certain comparisons are not meaningful
when performed directly on segmented addresses.

So, to summarize (and explain Alex's legitimate point), an implementation
of data structures in Ada which converts Address values to Integer_Address
and then compares the Integer_Address values will work on all likely
architectures including segmented architectures, and is from a formal
point of view defined to either work as expected or raise Program_Error.

By contrast, if you compare addresses in a corresponding C program, the
address comparison will in fact produce meaningless results silently
in the case of segmented architectures, and from a formal point of view
nothing at all can be said about the semantics of the comparison operation.

*quite* a difference, and enough for Alex to decide quite reasonably, that
a standard implementation of libraries for C++ (which has the same semantics
as C here) could not legitimately use these undefined comparison operations,
whereas in the Ada 95 case, they could reasonably used. 

Yes, in the Ada 95 case, one could perhaps imagine a machine in which
there was no sensible linearization of addresses, but I certainly don't
know of any such machine, so such considerations are of a purely
theoretical nature.

In the C case, many programmers have been burned by the "unexpected"
behavior of address comparisons on a segmented machine. For example,
if you have

    int p [10];

then ((p-1) < p) can be false, so a loop that works by pointing one before
the array to initialize can fail. equally if you do something like

   (x = p; x < &p[10]; p += 3)

you can find you have an infinite loop, all quite in accordance with the
C semantics, although somewhat surprising.

Re: OO, C++, and something much better!

[Roy Phillips]

Don Harrison wrote:
> Mark A Biggar writes:
> 
> :Of course there is nothing that requires
> :that the provided function realy be a less-than function (which is usefull
> :as providing a ">" instead reverses the order of the list) but Eiffel has the
> :same problem and there is no guarentee that a class derived from COMPARABLE
> :hasn't redefined "<" to do something else either.
> 
> While it wouldn't be possible in this case, a level of confidence can be
> provided in other situations using Eiffel postconditions.

   The problem with this approach is not really the deliberate
substitution
of the ">" with a "<": as stated, this can be a useful technique (I'd
hate
to have to maintain that code, all the same!).  More problematical is
the
accidental substitution, for example of an operation with same name but
an
entirely differant meaning (for example, the terms 'interest' (financial
domain) and 'interest' (marketing domain)) - blame the English language
if
you will, but without semantic specification (i.e., Eiffel assertions)
the
whole thing is a can of worms.

- Roy

Re: What is wrong with OO ?

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>There are times when you want optimizations yet you want to avoid
>cross-module optimizations, but those should be exceptions;
>automatic cross-module inlining ought to be the norm.
>
>  I think not. You can only do cross-module inlining if every compilation
>  potentially recompiles code for the entire application. This seems out
>  of the question in large applications.

During the edit-compile-debug cycle, you want rapid turn-around, and so
you don't want optimizations (except for those that actually speed up
the turn-around time).

Then when you're doing integration testing, when you can afford to
compile with optimization, you can usually also afford cross-module
inlining.

>  It seems to me here that the Ada approach is just right. Fergus, if you
>  are aware of the Ada approach, what would you change?

The Ada language design is OK; I consider having "private" sections
in package specifications to be a fairly low-level, implementation-oriented,
and inelegant approach, but I understand its advantages.

What I would change is the implementations: specifically, I'd like to
see a cross module inlining option for GNAT.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

Richie Bielak <richieb@calfp.com> writes:

>Optimizations that require global analysis of all the classes
>of a program at compile time do not work if we need dynamic loading
>of classes at runtime, because adding a new class to a running system
>may invalidate optimizer's assumptions.

True, but there are plenty of cross-module optimizations (such as
cross-module inlining) that require the compiler to use information
from more than one module but don't require analysis of *all* parts of
a program.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Keith Thompson]

In <dewar.852652911@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Actually, when I talked to Alex, he indicated that there were critical
> features in Ada 95 that were missing in C and C++ for this kind of
> work. In particular, he noted that C lacks a general address comparison
> operation, useful for hashing data structures, whereas Ada does have such
> an operation (in System.Storage_Elements on type Integer_Address). It is
> a bit ironic to identify this particular feature as crucial (since most
> people mistakenly think that C has such a feature and Ada doesn't!)

Well, sort of.

It's true that C pointer comparison is undefined unless the pointers being
compared point into the same object (or one past the end of an array).
However, any real-world C implementation isn't going to go out of its
way to make such comparisons invalid.  If pointers "look like" integers
at the hardware level, pointer comparison is almost certainly going to be
implemented as integer comparison.  It may be signed or unsigned, but it's
almost certainly going to be consistent within a given implementation.

On the other hand, for Ada 95, RM95-13.7.1(16) says that "Operations that
do not make sense should raise Program_Error".  The AARM (Annotated Ada
Reference Manual) gives the examples of X < Y and conversions between
Integer_Address and Address on a segmented architecture.  (Note also that
it's not necessary to use System.Storage_Elements; relational operators
on type Address are provided in System.)

The use of the word "should" means that an Ada implementation is not
*required* to raise Program_Error.  Thus it's permissible for address
comparisons to behave inconsistently.

To summarize, both C and Ada provide relational operations on addresses.
Both require such operations to be well-behaved only in certain cases,
and leave them more or less undefined in other cases.  Both are defined
in such a way that any reasonable real-world implementation will almost
certainly implement address comparison in the obvious manner, which
should be useful for hashing data structures.

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: What is wrong with OO ?

[Jay Martin]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Jay, in typical fulminating mode says

> "It seems to me need for "pragma inline" and "inline" is/was social.
> It came from compiler writers continually slacking off since the 60's
> and not implementing inlining."

>nonsense, all decent compilers implement inlining today, it is a more
>vital optimization than ever because of icache considerations (particularly
>in direct addressed caches).

Gee I don't remember fully general inter-unit automatic/intellegent
global analysis procedure inlining in the early 80's when "pragma
inline" and "C++ inline" features were created.  Maybe I just used
lame compilers.

But then I remembered I was just parroting Stroustrup: "I had had poor
experiences with languages that left the job of inlining to compilers
"because clearly the compiler knows best" The compiler only knows best
when if it has been programmed to inline and it has a notion of
time/space optimization that agrees with mine.  My experience with
other languages was that only "the next release" would actually
inline, and it would do so according to an internal logic that a
programmer couldn't effectively control."  (Design Evolution C++ pg
33)


>In a large project it is essential not to accidentally create interunit
>dependences so that a small change to one unit causes millions of lines
>to need to be recompiled.

>The problem is that you definitely do NOT want the compiler rushing off
>and creating unlimited body dependencies (think interunit dependencies
>if you don't want to think Ada specifically) by doing automatic interunit
>inlining.

>Still some interunit inlining is highly desirable especially with
>heavy layering of abstractions. But you want to give the programmer
>some control, to avoid the problem of inter-unit dependencies running
>amok!

Here's an ignorant question: Why would inlining or extensive
optimations be turned on for frequent builds of a quickly changing
large software project.  It seems testing of optimized builds could be
done less frequently and in parallel.  I mean if you don't inline
quickly changing source by using compiler controls, then you don't get
these sort of dependencies.  I must be missing something here.

Here is an even more ignorant question: Why is compilation time still
a driving factor? (excluding hardcore optimizations) Obviously it
still is as I watched large systems compile lately.  But wait, wasn't
Turbo Pascal long ago seemly compile stuff faster on a 4.77MHz PC
faster than VC++ on my P5-100.  For fun I compiled old programs with
vintage a Turbo Pascal Compiler and it seems to compile these suckers
instantanously!  It doesn't seem to me that current system build times
are keeping pace with processor speed improvements.  I mean shouldn't
a Pentium Pro 200 be compiling like a million lines a second or
something?  If its not, then how about the eventual P7-600Mhz or the
P8-2000Mhz-16(processors per chip).  I mean I can write N lines of
code a day and that is not going to change much, but computer speeds
are increasing exponentially.

Jay

Re: What is wrong with OO ?

[Simon Willcocks]

In article <dewar.852833957@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) says:

>Simon said

>"[...]
>I think that even in [Ada] inlining could be done by a suitable linker,
>provided the compiler could mark parts of object code as suitable for inlining.
>The linker could insert the relevant code in place of the call statement,
>rather than just setting the location to be called."

>[...]

>Inlining is MUCH more than just sticking in the code at the point of call
>and cannot be done at all by a stupid linker. The whole point of inlining
>is that you optimize the code that is inserted, minimally by increasing
>scheduling opportunities, but in the presence of global optimization, knowing
>what the body of a procedure does and does not do can buy a great deal. The
>elimination of the call itself is small stuff compared to the other gains.

I agree it can't be done with a stupid linker, but I was just pointing out
that inlining can be done in Ada without affecting the programmer.

You just have to leave the jobs of optimisation and (machine) code generation
to a later stage.

Simon

Re: What is wrong with OO ?

[Robert Dewar]

Fergus said

"What I would change is the implementations: specifically, I'd like to
see a cross module inlining option for GNAT."

If you mean that you want every possible opportunity for cross-module
inlining to be attempted, that is easily achieved, just write a little
tool that generates pragma Inline's for all visible subprograms in all
package specs. Then turn on the usual -O2 -gnatn switches.

It certainly would be easy to implement a compiler option to force this
treatment, but so far none of our customers has suggested this as a
requirement.

Re: What is wrong with OO ?

[Bart Samwel]

Robert wrote:

> "You shouldn't bother programmers with inlining. Inlining can be done
> automatically by the compiler."
> 
> I don't see this is possible across modules without violating the
> integrity of separation of specs and implementations.

In C++, it's not possible, that's true. This is because C++ uses a
modular model that completely separates different parts of the system.
When compiling one module, the compiler doesn't know anything about the
other modules other than that they are there and their specifications.
This makes automatic inlining very hard, because the implementation is
just _not available_ to the compiler!

The problem here is that C++ honours the principle of modularity, which
is a Good Thing, but fails to recognize the fact that many modules
form a System as a whole. This results in C++ not doing any global
analysis of programs, so that it cannot automatically detect functions
which need dynamic binding ("virtual"), it cannot choose to inline
functions which were not designated by their writer to be inlined,
and it cannot perform optimizations that cross module boundaries (these
optimizations would be valid only within the system they were performed
on, so that when you use some of the modules in another system, other
optimizations might be chosen).

In languages like Eiffel, which provide for global analysis of the
system, automatic inlining is possible. It is even possible to inline
one call to a function (for instance, within a loop), and not to inline
another call in the same function, only a few lines later.

As for separation of specs and implementations: C++ violates this too,
by forcing inline functions to be defined in the class INTERFACE
specification. With global analysis, you can still keep this separate,
and even better, because you don't have to put the inline function in
the interface: the global analysis has access to the implementation
anyway, so you don't need that anymore.

The point I have here is that the fact that the implementation is
visible to the compiler does not directly imply it should visible to
the programmer.

   Bart

Re: What is wrong with OO ?

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>If it was consdered useful to allow unlimited inlining in Ada, it would
>be trivial, and very much within the spirit of the language to add a
>configuration pragma Inline_All (implementations of Ada are allowed to
>add such configuration pragmas, or it could simply be a compiler switch).
>
>To implement such a switch would be about thirty minutes work in GNAT, but
>I doubt it would be found to be of much use in practice, certainly no one
>has indicated an interest in such a switch.

Let me hereby indicate interest in such a switch!
I think it would be quite useful in practice.

>On the contrary, in large 
>programs, people are VERY concerned about compilation dependencies. If
>any change to any unit requires recompiling ten million lines of code,
>then even with a fast compiler, the impact on development productivity
>is worrisome.

My (non-Ada) experience is that many programs consist of between a few
thousand and a few hundred thousand lines of code, and that often I am
interested in building the fastest possible executable and not
particularly concerned with compilation speed (since I'm building it in
the background) and entirely unconcerned with recompilation speed
(since I am just doing `make && make install && make clean').

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Robert Dewar]

Simon says

"I agree it can't be done with a stupid linker, but I was just pointing out
that inlining can be done in Ada without affecting the programmer.

You just have to leave the jobs of optimisation and (machine) code generation
to a later stage."


Let's look at that carefully. The second paragaph implies that the link
step redoes optimization and compilations for the entire program. Even
with fast machines and fast compilers, I think that this is definitely
something that would "affect the programmer".

As I have pointed out before, it is of course a trivial adjustment
to an Ada compiler to make it automatically check for inlining everywhere
(it is in fact a one line change to the GNAT compiler). But it is not
clear that this is a useful option in practice, although maybe this
discussion will suddenly make one of our customers suggest it :-)

Re: OO, C++, and something much better!

[Bart Samwel]

Robert Dewar wrote:

> values of one type to values of another type. It is that these
> operations can generate abnormal values.

I just thought of a way to implement safe type (read: class) casting
in Eiffel:

Use the Attempted Assignment operator ?= to try to assign, as in:

   local
      object1 : CLASS1
      object2 : CLASS2

   do
      !!object1.make (whatever)
      object2 ?= object1         -- this is what I mean
      if object2 /= Void then
        ...
   end

This operation makes object2 a reference to object1, but belonging to
class CLASS2, but only if, after conversion, object2 satisfies the
class invariant of CLASS2. Otherwise, object2 will be Void.

Oh, by the way, this is meant to be interpreted as humour, not as
a serious proposal. ;-)

Re: What is wrong with OO ?

[Robert Dewar]

Fergus said

"library?).  Hence this control should normally be expressed via
compiler options, rather than being embedded in the source code."

Are you using GNAT? I would guess not, because you seem to assume that
is not the case, but in fact inlining is controlled by compiler options
in GNAT. The pragma inlines merely enable the establishment of interunit
dependences. The extent to which inlining takes place depends on 
compiler switches -- see the GNAT documentation for details.
n

Re: What is wrong with OO ?

[Jay Martin]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Jay, in typical fulminating mode says

> "It seems to me need for "pragma inline" and "inline" is/was social.
> It came from compiler writers continually slacking off since the 60's
> and not implementing inlining."

>nonsense, all decent compilers implement inlining today, it is a more
>vital optimization than ever because of icache considerations (particularly
>in direct addressed caches).

An example of inlining getting the shaft by compiler writers is G++
which does not support the normal inlining of templated class methods.
There is a "G++ only" workaround (source code hack) in the latest
compiler but again you have to wait for the real fix until "the next
release".

Re: What is wrong with OO ?

[Michael Malak]

In article <32D64931.167E@wi.leidenuniv.nl>,
Bart Samwel  <bsamwel@wi.leidenuniv.nl> wrote:
>
>In C++, it's not possible, that's true. This is because C++ uses a
>modular model that completely separates different parts of the system.
>When compiling one module, the compiler doesn't know anything about the
>other modules other than that they are there and their specifications.
>This makes automatic inlining very hard, because the implementation is
>just _not available_ to the compiler!

Yet, Microsoft Visual C++ does exactly that.  In fact, it has since
version 1.5 (early 1994).  MSVC++ performs "auto-inlining" (Microsoft's
terminology) by compiling all the source modules all at once.  That's
why it exhibits the curious behavior during compilation where it says
"Compiling...", then lists the modules one by one, then says
"Generating code...", then lists the modules all over again.

-- 
Michael Malak         Magic forwarding e-mail address:
Washington, DC        malak@acm.org

Re: What is wrong with OO ?

[Robert Dewar]

Fergus said, responding to me

">To implement such a switch would be about thirty minutes work in GNAT, but
>I doubt it would be found to be of much use in practice, certainly no one
>has indicated an interest in such a switch.

Let me hereby indicate interest in such a switch!
I think it would be quite useful in practice."


Well of course people are interested if it costs them nothing to be
interested :-)

It will be interesting to see if any of our customers picks up on this
as something that might be useful to them. Right now, we have lots of
things to do that definitely *are* of interest to our customers, so
these certainly have higher priority.

Actually, not many people in practice are even using -gnatn to activate
interunit inlining (which works fine, and we use it in the compiler itself).
Relatively few applications are at the level where they are worrying about
performance that much, but of course for those that do, it helps a lot.

Also if you have efective inlining, you tend to design with this
expectation. The GNAT compiler is certainly written this way. So far,
all released compilers have had full debugging assertions turned on,
and no inlining, but the compiler we recently shipped for the second
phase of the DEC field test for the VMS Alpha port is the fast compiler
with assertions off, and full inlining, and it does make quite a
difference in speed.

I don't know if the 3.09 releases will be the fast compiler or not, we have
not decided yet ...

Robert Dewar
Ada Core Technologies

Re: OO, C++, and something much better!

[Robert Dewar]

Bart says

"This operation makes object2 a reference to object1, but belonging to
class CLASS2, but only if, after conversion, object2 satisfies the
class invariant of CLASS2. Otherwise, object2 will be Void.

Oh, by the way, this is meant to be interpreted as humour, not as
a serious proposal. ;-)"


If we are doing design at this level, we should make it clear that when
you say "the class invariant of CLASS2", you also include all the 
unstated invariants that are in the mind of the programmer only :-)

Re: What is wrong with OO ?

[Robert Dewar]

Bart said

"In languages like Eiffel, which provide for global analysis of the
system, automatic inlining is possible. It is even possible to inline
one call to a function (for instance, within a loop), and not to inline
another call in the same function, only a few lines later."

Such discrimination is typical of modern compiler technology, and has 
nothing to do with whether the "language provide[s] for global analysis
of the system", whatever that might mean. Certainly any language allows
an implementation in which you delay some or all of code generation until
link time (for example, the old MIPS C compilers used to do global
register allocation at link time).

Whether you want to do this global recompilation, with dynamic adjustment
of inlining depends on the size of the system, the speed of the compiler,
and the extent to which you worry about things not working any more if
they have been recompiled in a different inlining environment.

Re: What is wrong with OO ?

[Pieter Schoenmakers]

In article <5b4f6l$aeq@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

   Richie Bielak <richieb@calfp.com> writes:

   >Optimizations that require global analysis of all the classes
   >of a program at compile time do not work if we need dynamic loading
   >of classes at runtime, because adding a new class to a running system
   >may invalidate optimizer's assumptions.

   True, but there are plenty of cross-module optimizations (such as
   cross-module inlining) that require the compiler to use information
   from more than one module but don't require analysis of *all* parts of
   a program.

With any kind of static binding (and inlining is the summum in static
binding), the possibilities of dynamically loaded code are limited.  What
to do if a dynamically loaded class redefines some feature causing that
feature to no longer be statically bindable?  Recompile the whole
executable?  --Tiggr

Re: OO, C++, and something much better!

[Ken Garlington]

Robert Dewar wrote:
> 
> If you like, consider Ada *minus* these two features as the interesting
> language to be analyzed. Then understand that in real life programs can
> break the bounds of this analysis to the extent they need to.

I think the other interestings aspects of the Ada approach are (1) the
language
makes it clear when something potentially nasty is being done -- both in
terms
of the language definition, and in terms of the syntax making the
operation
clear in the source code -- and (2) there is at least some attempt,
through
features such as 'Valid, to try to mitigate these effects where
possible. This
won't necessarily help with formal analysis, but it is useful in "real
life"
programs.



--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: What is wrong with OO ?

[Bart Samwel]

Michael Malak wrote:
> Yet, Microsoft Visual C++ does exactly that.  In fact, it has since
> version 1.5 (early 1994).  MSVC++ performs "auto-inlining"
> (Microsoft's terminology) by compiling all the source modules all at
> once.  That's why it exhibits the curious behavior during compilation
> where it says "Compiling...", then lists the modules one by one, then
> says "Generating code...", then lists the modules all over again.

This is a pro for VC++. However, most compilers still use the old make-
based model, especially on Unix, where compilers must comply to this
model because almost all unix software not distributed as binaries is
distributed using make projects. That VC++ does do automatic inlining
does not imply that my argument is invalid, only that there are
exceptions to the general situation I described. And it still is true
that C++ doesn't exactly invite compiler writers to implement automatic
inlining.

Re: What is wrong with OO ?

[Joe Buck]

jmartin@cs.ucla.edu (Jay Martin) writes:
>An example of inlining getting the shaft by compiler writers is G++
>which does not support the normal inlining of templated class methods.

Not quite true: only the first occurrence of a template function, the
one that causes the expansion of the template cannot be inlined.  This
is a problem with the design of the template expansion code and long
recognized by the maintainers as a bug.

This problem is fixed in the 2.8.0 snapshots, which has a new template
implementation.

>There is a "G++ only" workaround (source code hack) in the latest
>compiler

No, the workaround (explicit template expansion) is to write standard
(draft ANSI/ISO standard) code to explicitly expand the template; all
occurrences will then be inlined.





-- 
-- Joe Buck	http://www.synopsys.com/pubs/research/people/jbuck.html

Help stamp out Internet spam: see http://www.vix.com/spam/

Re: OO, C++, and something much better!

[Norman H. Cohen]

(This note, concerned only with a esoteric nit about Ada, is posted only
to comp.lang.ada.)

Robert Dewar wrote:

> Note that it is not actually the unchecked conversion that is nasty, since
> the fundamental conversion can be modeled as simply a random mapping between
> values of one type to values of another type. It is that these operations
> can generate abnormal values.
> 
> This may still not be a problem, given that uninitialized values can also
> be abnormal, thus:
> 
>   a := nasty_unchecked_conversion (b);
> 
> is no worse that not assigning to a at all if a is uninitialized.

No, uninitialized variables may be "invalid", but not "abnormal". 
Abnormal is worse than invalid.  Even uninitialized objects of a
composite type might satsify certain conditions (e.g. gaps between
record components set to zero, dope vectors properly initialized, etc.)
that an abnormal value violates.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Robert I. Eachus]

In article <32D51BC8.41C67EA6@escmail.orl.lmco.com> Ted Dennison <dennison@escmail.orl.lmco.com> writes:

  > Does that mean that they ALSO started thinking about the revision
  > again in 1993, even though the Ada 95 effort was well underway?
  > ;-)

    I wouldn't have responded, but it is a funny story.

    First, there was a decision by the Ada Board in 1988 to recommend
revision of the Ada standard, and for the next revision to be the last
to use the government funded contractor approach.  I hope an
electronic copy of that report is around somewhere, but if not I may
still have it on a (Macintosh) disk.

    However, the ISO standard was not approved until 1987 due to
procedural and other problems--even though the ISO standard was a one
page document pointing to the ANSI and French standards.  (Alsys did
the French translation with a lot of involvement from Jean and Mike,
so it was very faithful to the original.)

    So at Zandvoort, after a long discussion at the WG9 meeting of
slipping the schedule for Ada 9X six months, with detailed debate on
dates for committee drafts, ISO standards processes, etc. Bob Mathis
announced during the "new business" part of the meeting that ISO had
asked him as WG9 convener if we were planning to revise the Ada 87
standard.

    And finally, the real requirement is to revisit every standard at
least every five years to take action on it: keep it, revise it or
abandon it.  After 10 years most standards organizations automatically
abandon a standard if no action has been taken.  There was a lot of
discussion about whether to take explicit action on the ANSI Ada 83,
or to let it disappear. (For most purposes it was technically already
superceded by the identical ISO standard, which wouldn't expire until
1997.)  This was resolved by the Memorandum of Agreement between the
DoD, ANSI and ISO.  All three basically agreed to approve Ada 9X
together, and that Ada 83/87 would be in force until then.

    Since Ada 95 was actually approved in January 1995, we have until
December 2005 to amend it or whatever.  At this point I hope we can
have a nice little fold in the fixes to minor gotchas revision, and
leave any major revision for Ada 10X.  (If you want to think of it as
a fix the annexes revision, fine.  Most of the problems the ARG has
discussed so far are either chapter 13 issues or related to one or
another annexes.  The core language apparently got lots of attention
during the revision process, but the annexes were trying to track a
moving target.)



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: What is wrong with OO ?

[Robert I. Eachus]

In article <32D53473.4DAA423A@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

  > The ISE Eiffel compiler performs inlining completely automatically.
  > There is no "pragma inline" or comparable programmer intervention,
  > since it is not the programmer's job to worry about whether a routine
  > is inlinable or not. This is a job for a compiler.

   For some things this works, but Bertrand then says:

  > (In addition, for an object-oriented language, inlining is only
  > possible for a routine that is never subject to dynamic binding.
  > This requires extensive analysis of the software. If the
  > programmer requests inlining but it is semantically wrong, the
  > compiler should ignore the request. But then if the compiler is
  > capable of doing this analysis it should take care of the inlining
  > too, without bothering the programmer!)

  This is where the problem arises.  If you compile everyting in one
big batch, this is possible.  But if you don't then the user needs to
be able to say:

  "I don't expect any later subclass to override this method.  If I do
that (or some other programmer does), I'm willing to take a big
recompilation hit."

  Add to this the fact that a lot of apparently dynamic links in Ada
are actually resolvable at compile or link time, and you want the
ability to mark methods this way.  

  For instance, you can have a call on a method of a specific type
which dispatches to an inherited method which then makes many other
calls on methods of the type.  If the outer call is inlined, then all
the inner calls dispatch statically as well.  Often these inner calls
are to placeholder routines which contain no code, or to routines
which are only a few machine instructions in most static cases.

  > ISE Eiffel does give the user a degree of parameterization:
  > a compilation option specifies the size threshold beyond which
  > a routine will not be inlined. This is measured in internal units
  > (number of bytecode words), but easy to relate to number of
  > instructions. This option provides a way to control space-time
  > tradeoffs. In practice, however, most users are happy with the
  > default, which inlines small, frequently called routines.

   Ah, most Ada compilers do this as well.  But occasionally there is
a big payoff from inlining an otherwise large routine.  One case is
that you know that it is only called in one place.  Another is
mentioned above--inlining a "big" routine may result in further
automatic optimizations so that the final code is very small.

  > This automatic optimization is crucial because the object-oriented
  > style of development, with its emphasis on  abstraction, naturally
  > tends to yield many small routines. With ISE Eiffel, you can write the
  > software as it should be, not asking yourself all the time "should
  > I violate abstraction here and avoid writing a small routine because
  > of the effect on performance?"...

  Same in Ada.

  > You just leave this kind of concern to the compiler. ("Inline"
  > pragmas would be almost worse here, because you would have to
  > perform yourself the analysis of what is inlinable and what is
  > not. The incrementality problem is particularly nasty: change a
  > single line somewhere in a large system, and a routine that was
  > inlinable, far away in the software text, now becomes
  > non-inlinable! This kind of systematic, exhaustive work,
  > error-prone when done by humans, is what computers are for.)

  This is why the Ada pragma is ADVICE.  If the compiler can no longer
follow the advice, it has to go back and recompile things.
(Technically, the compiler can just tell the user which items are
obsolete, but all Ada compilers I'm aware of do this automagically or
through a make facility.)  The important thing is that pragma INLINE
can affect speed, executable size and/or compilation time, but it can
never affect correctness.

  > I also think that the Eiffel view of "separation of specs and
  > implementations" is more sophisticated than Ada's one (which I
  > assume is the one Robert Dewar has in mind), but that will be the
  > topic for another debate...

    If a classical debate, one well worth following.  But please don't
frame it that way.  It is not a feature war.  Both Eiffel and Ada had
models in mind when the languages were developed, but the set of
models supported in each case is richer, and overlapping.  AFAIK, the
"pure" Eiffel and Ada models are supported in both languages.
However, there are design models that work in Ada but not Eiffel and
vice-versa.  Also there are features in both languages that make
impure versions of their design models much easier to work with.

    For example, in the previous discussion, we have seen a case where
the user wants to limit a generic to one with comparisions.  Ada can
follow the Eiffel model:

    generic
      type Foo is new Comparable with private;
      ...

    But more normally in Ada this will be done as:

    generic
      type Foo (<>) is private;
      with function ">" (L,R: Foo) return Boolean;
      ...

    As I pointed out, this is because the Ada type model sees classes
as sets of types all having a specific set of operations.  Therefore
it is more normal (in Ada) to specify a class by specifying the
required operations.  The fact that a class is hierarchical is
expressed by/visible because of the available type conversion
operations.  Two types are members of the the same class if an object
of one type can be explicitly converted to an object of the other, or
both can be converted to a third type.  (To make that "if only if" is
complex since I can't specify the third type to class mapping in less
than a page. For example all discrete types can be converted to
_universal_integer_ by 'Pos.)  In a hierarchical class all objects can
be converted to / passed as a parameter of the type at the top.

    In Eiffel, even though the actual concept of class is very
similar, the model is explicitly hierarchical.  (You can implement the
Ada number class in Eiffel by adding explicit conversions which break
the hierarchy.)  As I said, it is not that it is not possible in
Eiffel, it is more that it is not done.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: OO, C++, and something much better!

[Robert Dewar]

oops, my last example of surprising C code

   (x = p; x < &p[10]; p += 3)

should of course be

   (x = p; x < &p[10]; x += 3)

Re: OO, C++, and something much better!

[Norman H. Cohen]

Andrew Koenig wrote:

> What Alex told me about that effort was that he was unable to find
> a single Ada compiler that implemented the standard accurately enough
> to enable him to do what he wanted to do with his library.

Alex Stepanov's Ada project took place nine years ago.  A lot of early
Ada compilers had trouble with intricate uses of generics, particularly
with such things as generics nested within generics.  However, most Ada
compilers have been much more reliable than that for many years now.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32D536C6.64880EEB@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

> Robert I. Eachus wrote:
> > 
> > 
> >       Bertrand Meyer said:
> > 
> >    > In my opinion neither Ada (83 or 95) nor C++ has the combination
> >    > of mechanisms making it possible to have the full power of
> >    > generics in an object-oriented language, as present in Eiffel...
> > 
> >      And then listed four properties, all of which are in Ada 95!
> 
> I disagree. What Mr. Eachus showed in his message is ways to achieve
> in Ada 95 the effect of the object-oriented mechanisms I described,
> as implemented in Eiffel. And he is correct that one can use Ada 95
> to obtain many of the same goals. (This would not be true, for example,
> of C++ and even less of Java.) But this does not mean the "four
> properties" that I listed are in Ada 95. Anyone who checks my
> message and the Ada 95 language definition will see that.

I am willing to buy this - more or less - as I noted in my original
reply.  But, your original post (with the relevant part right up there
just above) does not SAY this.  It certainly _reads_ like you are
saying that Ada 95 has none of these properties - and that is just
plain outright indisputably FALSE.  In fact, the _only_ one that it
does not have at the level you suggest is the so called "completely
consistent type system" which seems to really mean "an Eiffel style
type system".  The other three are there and actually are rather
better done in Ada, IMO, than the equivalent Eiffel.


> At some point, of course, one runs into matters of taste. I will
> again contend, however, that a rational, systematic analysis of
> O-O principles and how they combine with genericity, information hiding
> and other software engineering concerns almost inevitably lead to the
> Eiffel mechanism

Well, the big problem here is that there are so many "loaded" terms in
this without any universally accepted definitions and certainly no
universally accepted _value_ judgements and absolutely no objective
series of studies supporting anything one way or the other, that it
just doesn't say anything more than: "In my reasoned view, Eiffel is
better, and I have listed various reasons for my belief."

Fair enough.  But having done the above so called "rational,
systematic analysis" of so called "O-O principles", I've arrived at
rather a different conclusion and have listed reasons for this in the
past as well.  In particular, MI useage, in my perusals, is nearly
universally conceptually confused.  It is not a very good way of
"modeling" things.  It _can_ be a decent way of "code reuse" - but it
is not worth the conceptual price given readily available
alternatives.

Shrug.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Robert Dewar]

Marky said

"All you guys are talking about is inlining some code!!  Is it really worth
this long thread?"

Inlining is an important optimization, and becoming more so for two reasons.

  1. In pipelined machines, especially those with small primary direct
     addressed caches, inlining calls in a loop can avoid nasty effects
     due to cache address clashes.

  2. layered development, particularly the style associated with layered
     abstract data structures or objects, can result in lots of trivial
     subprograms being called, which can severely affect performance, again
     because of I-cache effects, this gets worse in modern machines.

Re: What is wrong with OO ?

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>... some interunit inlining is highly desirable especially with
>heavy layering of abstractions.

I'm glad you agree.

>But you want to give the programmer
>some control, to avoid the problem of inter-unit dependencies running
>amok!

Yes, you should give the programmer some control.  But the degree to
which inter-unit dependencies and recompilation speed are important
varies considerably between different situations, even for the same
source code (e.g. How fast is the computer you are compiling it on? 
Do you plan to modify the code and recompile, or are you just doing a
build and install?  Are you building an executable or a shared
library?).  Hence this control should normally be expressed via
compiler options, rather than being embedded in the source code.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Robert Dewar]

"> Assembler will ALWAYS be the most efficient language.  The more you
> abstract the problem, the more you "generalize" the solution to a
> given problem, the more you necessarily give up in efficiency.  C
> takes a minimal 3x hit on integer arithmetic, 10x on more complex
> stuff; and OO, because of the overhead interpreting where
> to send things, is 10x on top of that."


First, it is only true that assembler is most efficient if written by
a competent programmer. Since well over 90% of the assembly language
that I have seen is highly incompetent, this is an important criterion.
In particular, I often see the phenomenon of super ferocious, super
tight coding of junk algorithms, and the result can easily be beaten
by a decent algorithm written in any language.

As for the 3x hit on integer arithmetic, this seems complete nonsense.
Almost any decent C compiler these days should be able to handle near
optimal code generation for simple integer arithmetic.

Finally, writing assembly these days is getting more and more difficult.
Doing your own global scheduling as well as a good optimizing compiler
can do it is a very big challenge on modern superscalar machines. Yes,
it is true that you can often pick up a considerable advantage by choosing
clever machine dependent data structures, and taking advantage of
processor flags etc, but a modern optimizing compiler will almost
certainly be able to do a better job than most assembly language
programmers of global register allocation and scheduling.

Indeed the most efficient way to write assembly language might well be to
use the machine insertions available in many compilers (including GCC
and GNAT) that allow you to write register independent code, and then let
the optimizer circuits of the compiler do register allocation and 
instruction scheduling on the instructions you write.

I should say that I certainly agree that it is *possible* to achieve
remarkable time and space efficiency in assembly. My DASC program is
a nice example. It is a complete scanner and syntax recognizer for
Ada 83, that gives a pretty nice first error message on syntactically
invalid programs. It runs well over a million lines a minute on a 
25MHz 386 (I have not run it on more recent machine -- actually let
me do it, easy enough in another window here --- OK, a source file
of 1.04 million lines of Ada (actually 100 concatenated copies of the
GNAT unit sem_ch3.adb) took 14 seconds on my 133 MHs Pentium notebook,
so well over four million lines a minute on a machine with a very slow
disk). The size is also startling, it is a COM file less than 15K bytes
long, and that size INCLUDES 2K bytes of help text, and all the error
message text. 

So this kind of ancedotal evidence does indeed suggest that it is possible
some times to get startling performance from hand coded programs, but you
have to be VERY careful about extending this kind of data. Whether this
approach is practical in other situations depends on all sorts of factors.

Re: What is wrong with OO ?

[Marin David Condic, 561.796.8997, M/S 731-93]

Jay Martin <jmartin@CS.UCLA.EDU> writes:
>It seems to me need for "pragma inline" and "inline" is/was social.
>It came from compiler writers continually slacking off since the 60's
>and not implementing inlining.  Its hard to blame them as it didn't
>seem a market priority due a totally irresponsible and incompetent

    I am mildly disturbed by the notion that the compiler should
    perform inlining on its own with no input from the programmer -
    at least if the target is an embedded system. There are times when
    you want to force inlining for speed isues and there are reasons
    you may want to totally supress inlining for verification issues.
    (You may have module test tools/requirements which need to keep
    the code for procedures callable rather than inlined.) For
    workstation types of apps, this may not be an issue, but those of
    us who have to take our code into a lab and peer at it through
    logic analyzers, etc, would like to maintain some control over
    this.

>Computer Science Academia which produced a generation of programmers
>who think "C" is Computer Science and had the attitude that it was the
>job of programmers not compilers to do optimizations and said such
>things as "I do low level pointer arithmetic so that my COMPILER runs
>faster (a top UC Berkeley Graduate).  Pragma inline gave us a hammer
>to which to pound the compiler writers into submission.
>
    I'm with you on this - basically. I want the compiler to be
    capable of all sorts of optimizations so that you aren't depending
    on any given programmer to know specific tricks needed to get
    efficient code out of some particular language implementation.
    (Obviously, different compilers may generate dramatically
    different code from the same statements and what might be an
    "optimization" for one compiler {or given release thereof} might
    make bad code out of a different compiler {or subsequent release
    of the same one.}) But us embedded guys really *need* the ability
    to turn on/off specific optimizations (constant folding, inlining,
    etc.) because of hardware considerations, test issues and so on.
    I'd prefer that capability from a command line switch rather than
    a pragma in the source, but I'll take it either way.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "There is just one thing I can promise you about the outer-space
    program: your dollars will go farther."

        --  Wernher von Braun
===============================================================================

Re: What is wrong with OO ?

[Bart Samwel]

> Assembler will ALWAYS be the most efficient language.  The more you
> abstract the problem, the more you "generalize" the solution to a
> given problem, the more you necessarily give up in efficiency.  C
> takes a minimal 3x hit on integer arithmetic, 10x on more complex
> stuff; and OO, because of the overhead interpreting where
> to send things, is 10x on top of that.

IMO this number is only a valid approximation for Smalltalk and other 
dynamically typed OO languages. Statically typed languages like C++
(hybrid, but supporting OO) and Eiffel (pure OO) achieve a much lower
impact on performance than 10x. I won't give any numbers because I
don't have them, but I know most number-crunching usually runs at
very acceptable speed in these languages; a bit, but not much slower
than C.

Re: What is wrong with OO ?

[Bart Samwel]

Tom Bushell wrote:

> I have noticed this also applies to Visual BASIC and Forth.  These
> languages all use a technique that is often poo pooed by C/C++ junkies
> obsessed with wringing every cycle out of the CPU - they compile to a
> virtual machine, which is then interpreted.  These runtimes tend to be
> very compact compared to the native code produced by conventional
> compilers.  Of course, the execution time is slower, but this normally
> is only an issue for about 10% or less of the code in a typical
> program.  This 10% can be written in C or assembler, but this is
> rarely necessary.

Ah! It is also useful to notice the incremental compilation available
in some Eiffel compilers (Visual Eiffel from SiG and ISE's Eiffel 4 have
this feature, but there might be other compilers that have it too).
These compilers compile to interpreted p-code only the parts in the
program that have changed, so that other truly compiled parts do
execute at full speed, only the changed bits are slower. This
saves lots of compilation time, but retains most of the speed if you
compile everything to native code every once in a while.

Re: What is wrong with OO ?

[Jay Martin]

jbuck@synopsys.com (Joe Buck) writes:

>jmartin@cs.ucla.edu (Jay Martin) writes:
>>An example of inlining getting the shaft by compiler writers is G++
>>which does not support the normal inlining of templated class methods.

>Not quite true: only the first occurrence of a template function, the
>one that causes the expansion of the template cannot be inlined.  This
>is a problem with the design of the template expansion code and long
>recognized by the maintainers as a bug.

>This problem is fixed in the 2.8.0 snapshots, which has a new template
>implementation.

As I said the "next release".

>>There is a "G++ only" workaround (source code hack) in the latest
>>compiler

>No, the workaround (explicit template expansion) is to write standard
>(draft ANSI/ISO standard) code to explicitly expand the template; all
>occurrences will then be inlined.

Well gee if I have to insert "explicit template expansion" lines not
needed by any other C++ compiler or the standard that sounds like "G++
only source code hack" to me.  Of course, since I might also use an
older C++ compiler on my code that doesn't yet recognize expansions,
then I am going to have to put "#ifdefs" around these expansions.
Yee Haw!

This "bug" (lack of inlining) has been in G++ for YEARS, it just shows
how much priority (Zero) that so many programmers give to basic data
abstraction (you can't efficiency implement abstract data-structures
like "smart pointers" in C++ without inlining).

Jay

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "bertrand" == Bertrand Meyer <bertrand@eiffel.com> writes:

bertrand> The ISE Eiffel compiler performs inlining completely
bertrand> automatically.  There is no "pragma inline" or comparable
bertrand> programmer intervention, since it is not the programmer's job
bertrand> to worry about whether a routine is inlinable or not. This is
bertrand> a job for a compiler.

It seems contrary to reasonabless: there are many contexts where
inlining is not necessary and others in which it is important, *even for
the same procedure*. Thus there is (usually) a space/time tradeoff, but
*at each call site*. It sounds astonishing to me an argument that the
compiler should try to second guess or infer space/time tradeoffs
(except perhaps in the simplest cases), in addition to doing its job of
compiling valid translations of a source.

bertrand> (In addition, for an object-oriented language, inlining is
bertrand> only possible for a routine that is never subject to dynamic
bertrand> binding.

This is not quite the whole story. It all depends on call sites: at some
call sites a procedure can well be inlined, if at those call sites the
procedure implementation invoked can be identified statically. If it is
*also* invoked at call sites where this cannot be done, then an
out-of-line version must also be generated.

A lot of people forget that overloading resolution *and* procedure
implementation call/inlining are crucially dependent, both as to
validity and desirability, on specific call sites. Call sites that are
part of inner loops tend to make inlining more desirable (there are
often opportunity for code reorganizations of various sorts), for
example. Static resolution and perhaps inlining can also be possible at
some call sites but not others.

bertrand> This requires extensive analysis of the software. If the
bertrand> programmer requests inlining but it is semantically wrong, the
bertrand> compiler should ignore the request. But then if the compiler
bertrand> is capable of doing this analysis it should take care of the
bertrand> inlining too, without bothering the programmer!)

Here is a confusion two very different concepts: whether inlining is
*useful* and whether it is *possible* (valid). It may be a job for the
compiler to check whether inlining a procedure at a given call site is
*possible*, as claimed here; but it may require a lot harder work for
the compiler to determine whether that inlining is also *useful*. A
programmer's suggestion as to the *usefulness* of inlining a procedure
at a given call site (or all call sites, much more coarsely and rather
less desirably) is not replaceable by the a compiler check on the
*possibility* of inlining it.

Ideally a compiler would use profiling feedback to evaluate whether it
is worth inlining a procedure at a given call site, by running the
program with an without (this check ought to be done for each procedure
at each call site for which is is possible, and every combination
thereof :->).

Cruder hints may be used:

bertrand> ISE Eiffel does give the user a degree of parameterization: a
bertrand> compilation option specifies the size threshold beyond which a
bertrand> routine will not be inlined. This is measured in internal
bertrand> units (number of bytecode words), but easy to relate to number
bertrand> of instructions. This option provides a way to control
bertrand> space-time tradeoffs.

but, just like the 'inline' keyword of ``C++'', it does not quite
recognize that hinting for inlining a procedure at *all* call sites is
not quite as useful as hinting for it to be inlined at particular call
sites. However probably simple compiler heuristics can be useful, like:

bertrand> In practice, however, most users are happy with the default,
bertrand> which inlines small, frequently called routines.

As to this some Ada compilers do allow selective inlining at call site,
or at least at call sites thru a region of code only (if I remember
well).

bertrand> This automatic optimization is crucial because the
bertrand> object-oriented style of development, with its emphasis on
bertrand> abstraction, naturally tends to yield many small
bertrand> routines.

Where have I heard some of those word already? Ah, yes, those are the
words used by Ken Thomson and Dennis Ritchie about the C procedure
calling conventions. Then people instead started using '#define'. :-)

bertrand> With ISE Eiffel, you can write the software as it should be,
bertrand> not asking yourself all the time "should I violate abstraction
bertrand> here and avoid writing a small routine because of the effect
bertrand> on performance?". You just leave this kind of concern to the
bertrand> compiler. ("Inline" pragmas would be almost worse here,
bertrand> because you would have to perform yourself the analysis of
bertrand> what is inlinable and what is not. The incrementality problem
bertrand> is particularly nasty: change a single line somewhere in a
bertrand> large system, and a routine that was inlinable, far away in
bertrand> the software text, now becomes non-inlinable! This kind of
bertrand> systematic, exhaustive work, error-prone when done by humans,
bertrand> is what computers are for.)

Exactly! As to the *possibility* of inlining. On the other hand
complexity analysis to determine where it is *useful* to inline is not
quite what programs are very good at.

[ ... ]

Re: What is wrong with OO ?

[Robert Dewar]

Bjarne, in the middle of a very nice extended discussion of C++, says

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


Hmmm! I don't think I buy that. People will learn what is at hand pretty
much regardless of whether something is easy to learn and use. After all
I am sure that far more programs are written using macro languages of
spread sheets, most of which are truly awful, very difficult to use, and
pretty difficult to learn. Nevertheless people do at least "sort of"
learn something regardless. Actually elsewhere in his article, Bjarne
complains of this phenomenon :-)

By the way just a quick note on spreadsheet languages. I saw a couple of
years ago a fairly comprehensive study of spread sheet programs (if you
don't think of spread sheets as a programming language, then you don't
know what people are trying to do with these programs :-) It showed that
over 50% of production spread sheets in use at Fortune 500 companies
that were studied contained serious errors. Now of course any such survey
is subject to concerns about sampling stablity. Still one would think that
such a result would spread wide alarm, but as far as I can tell everyone
shrugged and continued ("it must be the other guy who has all the errors,
I am sure my spreadsheets are fine!")

Going back to the main subject, which is the allegation that popularity
indicates ease of learning and use, I think the point is that such
popularity indicates accesibility more than anything else. By accessibility
I mean that something is available, viewed as hot, and can be learned well
enough to do *something*. Consider the situation today, students want to
learn Java, not C++, they see C++ as yesterday's language, and Java as
the language of tomorrow. Just from the incredible rate at which Java books
are cascading into bookstores, I have to guess that the rate of learning of
Java far exceeds the rate of learning of C++. But I would NOT conclude from
this that Java is easier to learn or use than C++. Maybe it is, but you
cannot conclude anything just from popularity.

Ada folks have never played the game of claiming popularity as an indicator
of any kind of quality, because they have not been able to. I realize that
C++ is in a position to make such claims, but I recommend against it, because
I think you will find that your arguments will backfire as Java becomes
the next hot language, at least for a while :-)

Robert

Re: What is wrong with OO ?

[Robert Dewar]

Chris said

"If it's that easy we would like to try it (customer #133) :-)"

Well, as I noted to him, if people have suggestions for GNAT enhancements
they should be sent to report@gnat.com with a very clear suggestion of
what feature is needed, and why it is important for a given application.

Note that the fact that something is easy to do is not in itself a good
justification for adding a feature to a language or compiler implementation.
Every feature you add adds complexity, so you have to be conservative in
adding new features and switches.

Chris, if you are really interested in trying this out, do it the simple
way first. Write an edit script that adds pragma Inline statements to all
subprograms in all specs, then recompile the program. That way you can
get some data as to whether this option would be worthwhile.

Re: What is wrong with OO ?

[Bjarne Stroustrup]

jsa@alexandria (Jon S Anthony) writes:

 > 
 > In article <fxtu3oysbzp.fsf@isolde.mti.sgi.com> Matt Austern <austern@isolde.mti.sgi.com> writes:
 > 
 > > jsa@alexandria (Jon S Anthony) writes:
 > > 
 > > > Oh, I don't know.  I think C++ was created simply because BS was
 > > > saddled with C (at ATT) and wanted _something_ that had a least _some_
 > > > abstraction capabilities in it.  Voila.  C++.  Whether it is any more
 > > > "usable" than several other options is highly open to question.  And
 > > > in fact, in general I would say the answer is "no".
 > > 
 > > It's not necessary to speculate on why Bjarne Stroustrup made the
 > > design decisions that he did: he discusses them, in a fair amount
 > > of detail, in _The Design and Evolution of C++_.
 > 
 > He also gave various descriptions of this process while it was
 > happening cira 87-89 and I happened to attend some of these.

What was happening circa 87-89 was the refinements of C++ version 2
(abstract classes, multiple inheritance, etc.) and beyond (templates,
exceptions, etc.). The initial work was much earlier (1979-1983).


 > > he was trying to create a language that, like C, made it possible to
 > > write low-level programs, but that also, like Simula, included
 > > high-level abstraction facilities.  
 > 
 > Exactly.  This came from his direct experience of having to recode a
 > Simula program for his thesis into BCPL.  The resulting nightmare was
 > not something he wished to have to go through again.  When getting to
 > ATT and seeing that it was C or nothing, he decided to "fix it" before
 > suffering the same experience.
 
This description is misleading on two counts:

(1)	I wanted something from both Simula and BCPL. Both have strengths
	and weaknesses relatively to my needs.

		Simula, had classes and a (much) stronger type system.

		BCPL had speed, easy porting of implementations, and the
		ability to easily cooperate with code fragments written
		in other languages (it was ``open'').

	The issue was not as simple as ``Simula was ideal except for
	efficiency concerns.'' That was the case for my Cambridge
	simulations, but not for the work I wanted to do later.

	The lessons I drew from my experiences in Cambridge was that I
	needed both sets of "good aspects" (and that there were "bad
	aspects" to both that I'd rather do without) NOT that one was
	strictly better than the other. This is documented in D&E and
	in papers written earlier than '87-'89. What I synthesized from
	my Cambridge rogramming experience was an initial set of criteria
	for a tool for higher-level systems programming.

(2) It was not "C or nothing" at AT&T. I was in a research organization
	that did not dictate what languages to use and several languages
	were used in various parts of AT&T at the time. The alternatives
	I knew of during the first years included C, Simula, Algol68, BCPL,
	Pascal, Modula-2, and Lisp. Naturally, I knew of more languages,
	but not every language I knew was an alternative for the work I
	was doing.

	I chose C because I rated it the best systems programming language
	at the time. It had obvious flaws, but I rated them secondary and
	manageable, whereas I considered the other alternatives to have
	more fundamental flaws relative to my needs. Being in THE hotbed
	of C at the time of course helped me appreciate the strengths of
	C and taught me how the experts compensated for its weaknesses,
	but that is a far cry from "C or nothing."


Why is any of this relevant now? Why do I bother with this debate on
"innovation?" Because some of what is said related directly to what C++
is and should be, and that again affects where it is reasonable to use
it and how it is best used. If you misunderstand some of the fundamentals
of a language, the code you write in it is going to be suboptimal in several
ways.
	
	- Bjarne

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

Re: What is wrong with OO ?

[Robert Dewar]

Marin David Condic said

"    I am mildly disturbed by the notion that the compiler should
    perform inlining on its own with no input from the programmer -
    at least if the target is an embedded system. There are times when
    you want to force inlining for speed isues and there are reasons
    you may want to totally supress inlining for verification issues."

Compilers are always free to generate any code that meets the semantic
specifications of the language, and inlining (apart from the issue of
creating body dependencies in the interunit case in Ada) is semantically
neutral, so of course a compiler can perform inlining whenever it feels
like it.

Now, you may want for various special purposes, such as those you mention
above and others, to have ways of limiting the basic semantic freedom of
a compiler to generate any semantically correct code. Such compiler options
are common, but have very little to do with source language syntax or
semantics.

Note that there *is* no way in the Ada *language* of forcing or preventing
inlining. The use of pragma inline simply controls whether certain body
dependencies are allowed to be created.

An Ada compiler that delayed all code generation till link time, and at
that time did all possible inlining across units, even in the absence
of any pragma inline statements in the source, is a perfectly valid
implementation of Ada.

Re: What is wrong with OO ?

[Randy A. Ynchausti]

Bart Samwel wrote:
> 
> > Assembler will ALWAYS be the most efficient language.  The more you
> > abstract the problem, the more you "generalize" the solution to a
> > given problem, the more you necessarily give up in efficiency.  C
> > takes a minimal 3x hit on integer arithmetic, 10x on more complex
> > stuff; and OO, because of the overhead interpreting where
> > to send things, is 10x on top of that.
> 
> IMO this number is only a valid approximation for Smalltalk and other
> dynamically typed OO languages. Statically typed languages like C++
> (hybrid, but supporting OO) and Eiffel (pure OO) achieve a much lower
> impact on performance than 10x. I won't give any numbers because I
> don't have them, but I know most number-crunching usually runs at
> very acceptable speed in these languages; a bit, but not much slower
> than C.


So what's your point.  Computer speeds are increasing rapidly.  The cost
is decreasing rapidly.  I am willing to trade your perceived efficiency
of Assembler for the ease and enjoyment of creating applications for
families of micro-processors in a high-level language.

Re: What is wrong with OO ?

[Robert Dewar]

Jay said

"Here is an even more ignorant question: Why is compilation time still
a driving factor? (excluding hardcore optimizations) Obviously it
still is as I watched large systems compile lately.  But wait, wasn't
Turbo Pascal long ago seemly compile stuff faster on a 4.77MHz PC
faster than VC++ on my P5-100.  For fun I compiled old programs with
vintage a Turbo Pascal Compiler and it seems to compile these suckers
instantanously!"

Yes, but the quality of code turned out by your "vintage Turbo pascal
compiler" is truly horrible. If you don't mind that then fine, it is
certainly possible to turn out compilers that compile lousy code
fast. It is even possible to make compilers that generate pretty good
code locally and are very fast (e.g. Realia COBOL).

But almost in the same breath you were talking about intelligent global
optimziation, and interunit IGO at that!

Global optimization, even at the level of simply worrying about good
global register allocation and good scheduling across basic blocks,
is non-trivial, and tends to eat up large amounts of computing resources.
Furthermore, anything approximating optimal algorithms tends to be
super-linear --- at least quadratic sometimes worse -- we know of
course that truly optimal code generators are NP complete in time
complexity -- but we don't go that far).

Still this super-linear behavior means that if you try doing global
optimziation across the entire program, you are liable to use very
large amounts of computing resources. The MIPS compiler did link time
register allocation, and even just doing that resulted in very long
link times.

Of course this thread is NOT about intellignemt global optimziation, it is
about something much more trivial, which is simply doing inlining. I won't
comment on the issue of "parroting" BS on inlining in the past, but the
fact of the matter is that all compilers today implement inlining, and
that was true when Ada 83 was designed. As I have repeatedly pointed out,
the pragma Inline of Ada 83 is not about asking the compiler to inline,
it is about *permitting* the compiler to establish the body dependency
necssary to inline.

Doing all possible inlining is certainly not that hard, but it is likely
to be time consuming, since it creates a large number of body dependencies.
In a million line program, there is a lot of stuff to wade through to
find out lots of cases where inlining will NOT work, and I still suspect
that the benefits of such unrestricted searching for inlining opportunities
are dubious, especially given normal Ada style in which people do write
pragma Inlines where there is some possibility of interunit inlining
being useful.

Note that interunit inlining is not one iota more difficult than
intraunit inlining. The issue here is simply one of restricting how
much stuff the compiler must look at.

Re: What is wrong with OO ?

[Fergus Henderson]

Bart Samwel <bsamwel@wi.leidenuniv.nl> writes:

>Michael Malak wrote:
>> Yet, Microsoft Visual C++ does exactly that.  In fact, it has since
>> version 1.5 (early 1994).  MSVC++ performs "auto-inlining"
>> (Microsoft's terminology) by compiling all the source modules all at
>> once.
>
>This is a pro for VC++. However, most compilers still use the old make-
>based model, especially on Unix,

Which Unix are you thinking of?  The C++ compilers from Sun (Solaris),
SGI (IRIX), and DEC (Alpha/OSF) are all capable of automatic
cross-module inlining.

Oh, I guess you must have been thinking of Linux ;-)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

tiggr@es.ele.tue.nl (Pieter Schoenmakers) writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>   Richie Bielak <richieb@calfp.com> writes:
>
>   >Optimizations that require global analysis of all the classes
>   >of a program at compile time do not work if we need dynamic loading
>   >of classes at runtime, because adding a new class to a running system
>   >may invalidate optimizer's assumptions.
>
>   True, but there are plenty of cross-module optimizations (such as
>   cross-module inlining) that require the compiler to use information
>   from more than one module but don't require analysis of *all* parts of
>   a program.
>
>With any kind of static binding (and inlining is the summum in static
>binding), the possibilities of dynamically loaded code are limited.  What
>to do if a dynamically loaded class redefines some feature causing that
>feature to no longer be statically bindable?  Recompile the whole
>executable?  --Tiggr

If you allow new classes to be dynamically loaded, then the compiler
can't statically bind features of objects whose dynamic type is unknown,
but it can still statically bind features of objects whose dynamic type
is known.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Fergus said
>
>"Hence this control should normally be expressed via
>compiler options, rather than being embedded in the source code."
>
>Are you using GNAT?

Nope, not at the moment, although I have used it in the past.

>I would guess not, because you seem to assume that
>is not the case, but in fact inlining is controlled by compiler options
>in GNAT.

I know that -- in fact, I don't know of any compiler that does any
inlining for which you can't control the inlining with compiler options.

But in Ada with gnat/gnatmake, the control is normally specified using
a mixture of compiler options and embedded pragmas, and there is no
way of getting maximum inlining without scattering pragmas throughout
your code.

This contrasts with e.g. SGI C++, which has command-line options
that allow you to do full cross-module inlining without a single
`inline' or pragma in your source code.

>The pragma inlines merely enable the establishment of interunit
>dependences.

But the real interunit dependencies depend on the compiler options.
If you're compiling with gnat/gnatmake without inlining enabled, but
you have the pragmas scattered throughout your source code, then you
will get some unnecessary recompilation, won't you?

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Josh Stern]

Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote:

>Perhaps the most important advantage of inlining is that it creates
>opportunities for other optimizations, such as constant propagation,
>strength reduction, dead code elimination, common sub-expression
>elimination, and hoisting code out of loops.  The advantage of inlining
>comes not just from avoiding the call/return, but also from being able
>to specialize the subroutines's code for each particular invocation.

Agreed!  And I would go one step further to add that when
a programmer can assume that these sort of optimizations
will take place, then it is possible to produce code at
a given level of performance efficiency that is much
more readable and maintainable than otherwise.
And it will also be faster to write this code.

-Josh

Re: OO, C++, and something much better!

[Richard Riehle]

On 6 Jan 1997, Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:

> However, if I remember correctly, Alex Stepanov had earlier tried to
> implement a library like the C++ STL in Ada, but was incapable of
> doing it. This would indicate that the C++ template mechanism is more
> flexible than the Ada generics.
> Any comments?

  In an in-depth interview published in Dr. Dobbs (I do not recall the
  date) Stepanov was both complimentary of Ada and critical of it. His
  primary criticsim was the inability to create generic packages in which
  he could use generic formal package parameters.  C++ and Eiffel both
  allow something analogous to this.

  This was perceived by many as a problem in Ada 83, and "fixed" in 
  Ada 95.  ISO Standard 8652:1995 Ada does include generic formal 
  package parameters, though the model seems, to some, a little more 
  awkward to use than the same mechanism in C++ or Eiffel. STL could be
  implemented in Ada 95 if anyone wanted to take the time to do it.

  Probably a better approach than STL, for Ada 95, would be that by
  Bertrand Meyer as published in his book, "Reusable Software" from
  Prentice-Hall. 

  At a Tri-Ada conference in Los Angeles, Mr. Stepanov re-visited
  this Ada 83 criticism while on a panel discussion with Tucker Taft.
  At that time, Tucker made it clear to Mr. Stepanov that Ada 95 does
  include generic formal package parameters. 

  Richard Riehle

Re: What is wrong with OO ?

[Robert Dewar]

iFergus said

"But the real interunit dependencies depend on the compiler options.
If you're compiling with gnat/gnatmake without inlining enabled, but
you have the pragmas scattered throughout your source code, then you
will get some unnecessary recompilation, won't you?"

No, of course not. The pragma Inline's represent *permission* to create
dependencies, not a requirement to do so, and as clearly documented in 
the gnat users guide, if you do not use -gnatn, then pragma Inline is
ignored.

Re: What is wrong with OO ?

[Slavik Zorin]

Inlining in Smalltalk is a pain in the ass, esspecially when the
compiler bluntly chooses to do it for you.  Message like >>isNil which
is automatically inlined by the compiler wreeks all kinds of havoc when
one uses proxies which are subclasses of nil.  When I initialize an
instance variable with some semantic proxy which gets dereferenced when
it receives its first message (goes to DB and caches the real object in
its place), the message >>isNil to this proxy should return true, that
is the message isNil should be overriden!  But, since the compiler
rudely ignores it (how can it not, Smalltalk has not types, so there is
now way the compiler knows the expression "obj isNil" should not be
precompiled), one must replace all isNil messages to = or ~=; what a
pain!!!

How about:
	Compiler
		doNotInlineSelectors: someSelectorArray
		forMeta: aClassOrMetaclass

If Smalltalk icludes a compiler, its time to include some public
compiler APIs as well.

Slavik Zorin

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "eachus" == Robert I Eachus <eachus@spectre.mitre.org> writes:

[ ... interesting discussion on Ada generics and inling and OO ... ]

eachus>     As I pointed out, this is because the Ada type model sees classes
eachus> as sets of types all having a specific set of operations. [
eachus> ... ]
eachus>     In Eiffel, even though the actual concept of class is very
eachus> similar, the model is explicitly hierarchical. [ ... ]

Let me put here a warning to the reader: this is true only in a certain
sense that is apparent to those familiar with the Ada 95 usage of the
word "class"; in Ada 95 the word "class" denotes something more like
what is called a "protocol", for example in ``Smalltalk''-like
languages, or rather the classes that share a protocol, while "class" in
most OO languages means a single instantiable module/type.

Re: What is wrong with OO ?

[Martin ELLISON]

Robert Dewar wrote:
> 
> Simon says
> 
> "I agree it can't be done with a stupid linker, but I was just pointing out
> that inlining can be done in Ada without affecting the programmer.
> 
> You just have to leave the jobs of optimisation and (machine) code generation
> to a later stage."
> 
> Let's look at that carefully. The second paragaph implies that the link
> step redoes optimization and compilations for the entire program. Even
> with fast machines and fast compilers, I think that this is definitely
> something that would "affect the programmer".

Why can't the compiler optimise the whole program? (Assuming that it is
all written in the same language). Who says that you have to compile and
generate code for each module and then link them together? Doing so may
be quicker for a development version, but surely a production compile
can be optimised across the whole system.
---------------------------------------------------
Martin Ellison                  		mailto:martin@mpce.mq.edu.au  
				    		http://www.jrcase.mq.edu.au/~martin/

Re: What is wrong with OO ?

[Matt Telles]

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

Re: What is wrong with OO ?

[Chris Morgan]

In article <dewar.852893729@merv> dewar@merv.cs.nyu.edu (Robert Dewar)
writes (regarding an "attempt automatic inline" switch :

> It certainly would be easy to implement a compiler option to force this
> treatment, but so far none of our customers has suggested this as a
> requirement.

If it's that easy we would like to try it (customer #133) :-)

Chris
-- 
Never run with scissors.

Re: What is wrong with OO ?

[Chris Morgan]

In article <01bbff25$8b1fa3c0$26170880@annex9-38.dial.umd.edu> "Marky
Mark" <mrox@wam.umd.edu> writes:

> All you guys are talking about is inlining some code!!  Is it really worth
> this long thread?

Hint :

Yes!

Chris
-- 
Never run with scissors.

Re: What is wrong with OO ?

[Thierry Goubier]

On 11 Jan 1997, Piercarlo Grandi wrote:

[On the subject of inlining by the compiler, with B. Meyer]

> Ideally a compiler would use profiling feedback to evaluate whether it
> is worth inlining a procedure at a given call site, by running the
> program with an without (this check ought to be done for each procedure
> at each call site for which is is possible, and every combination
> thereof :->).

I believe this technology already exists, for example in the Self 3.0 and
4.0 inlining compilers. Things like polymorphic inline caches may be used
as a tool to record profiling information for the compiler.

But I should let interested people look the Cecil/Vortex project to see
how this may be used in static compilation. What Chambers describes seems
to be relevant to this thread. A pointer is :

http://www.cs.washington.edu/research/projects/cecil/www/Overview/overview_1.html

Thierry.
___________________Thierry.Goubier@enst-bretagne.fr__________________
    Je ne suis pas un patriote car je n'ai pas peur de l'etranger
        I'm not a patriot because I don't fear foreigners
http://www-info.enst-bretagne.fr/~goubier/                    

Re: What is wrong with OO ?

[Fergus Henderson]

bs@research.att.com (Bjarne Stroustrup) writes:

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

It's not important to learn every obscure language detail, but it is
important to know all the language rules that govern the behaviour of
the subset of language features that you do use.  Without that
knowledge, it is very easy to accidentally write programs that are
non-portable or buggy.

Most C++ programmers make use of class libraries (e.g. the C++ standard
library) that use a broad range of C++ language features.  Correct use
of such class libraries may require knowledge of a large number of
those obscure details. 

(See, for example, the thread on "operator delete and template
instantiation" in comp.std.c++, or consider the many discussions in
comp.lang.c++(.moderated) on how to write "exception-safe" code.)

>Usually, people manage in the end, and
>if not they try something else - which they may or may not find more
>suitable.

Usually, people do manage in the end, but then again most software
produced today is full of bugs.  Usually it works well enough only
because it has been carefully tested and debugged, but usually it will
fail when exercised in novel ways.  Choice of programming language is
certainly not the only or the most important factor in this, but I do
think that it can make a significant difference.

>Reliability and mainatainability can be eased by a programming
>language (such as C++) but is the result of a more comprehensive
>process.

Yes, but I think one part of that comprehensive process should be
ensuring that programmers do know the language rules that govern the
behaviour of the language features that they use.  (It's not too
important for a programmer to know about the tricky cases if the
compiler will catch them, but it is important to know about possible
pitfalls that would not be caught by the compiler and would instead
result in undefined or implementation-dependent behaviour at runtime.)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Fergus said, responding to me
>
>">To implement such a switch would be about thirty minutes work in GNAT, but
>>I doubt it would be found to be of much use in practice, certainly no one
>>has indicated an interest in such a switch.
>
>Let me hereby indicate interest in such a switch!
>I think it would be quite useful in practice."
>
>Well of course people are interested if it costs them nothing to be
>interested :-)

We were interested enough to implement this in the Mercury compiler.

Compiling the Mercury compiler with inter-module inlining enabled
improved performance by about 10%.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Marky said
>
>"All you guys are talking about is inlining some code!!  Is it really worth
>this long thread?"
>
>Inlining is an important optimization, and becoming more so for two reasons.
[...]

Perhaps the most important advantage of inlining is that it creates
opportunities for other optimizations, such as constant propagation,
strength reduction, dead code elimination, common sub-expression
elimination, and hoisting code out of loops.  The advantage of inlining
comes not just from avoiding the call/return, but also from being able
to specialize the subroutines's code for each particular invocation.

Increasing amounts of code reuse is making this effect more important.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Marin David Condic, 561.796.8997, M/S 731-93]

Russ McClelland <russmc@NETBOX.COM> writes:
>> > Near the beginning of "The Mythical Man Month" an interesting
>> > observation is made: Since we so often hear about the stunning
>> > success of one or two programmers working at the kitchen table,
>> > why is it that all software is not written that way? Why is it that
>> > corporations continue to build these crazy, wasteful, failure-prone
>> > development departments when all they really needed to do was stuff
>> > a couple of talented programmers in a garage for a few months?
>
>Ahh, some say a dated book...I say a book that should be manditory reading
>for EVERY person involved in software development, from coders to managers
>to CIOs.  It should be read, discussed, studied, and read again every year
>until it sinks in!
>
    I liked the book, but I thought there was a certain sort of
    naivete to some of the concepts - especially this one. Yes, there
    is a large class of programs that can be built by a coding
    genius in a garage a lot better/faster/cheaper than by a team of
    average programmers sitting in Dilbert cubicles and forced to
    attend endless status meetings, etc. Especially where one needs to
    get particularly "creative" in inventing new and interesting
    solutions to a problem.

    But there is an even larger class of problems that by their very
    nature are going to demand that lots of people get together to
    build the software. (domain experts, software specialists,
    hardware designers, marketing dweebs, burnt out managers, etc.
    etc.) Not to mention the sheer magnitude of code involved in some
    of this stuff. (try typing out a million lines of *anything* and
    see how long it will take) And you're *never* going to get a whole
    team full of "A-String" players any more than the Dalas Cowboys
    will - there's only a few stars in the world by definition. So
    you're going to get stuck with some average, slow, error prone hackers
    and even a few clods who are a waste-of-skin and dumber than a bag of
    hammers.

    Once you get beyond 3 or 4 people working on a software project,
    you're going to get status meetings, turf wars, conflicting design
    goals, cost and schedule pressures, etc. etc. ad nauseam. And for
    those who believe there's a simple solution to it all, I'd refer
    them to the story of the Tower of Babel. I think it's inherent in
    all human endeavors that beyond a certain size, there's no way to
    do it without waste, errors, compromises, delays, and so on.

    (Of course, that's not what I tell my bosses - they have trained
    me with many and severe beatings how to read from The Book Of
    Devoutly To Be Desired Results ;-)

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "When the going gets weird, the weird turn pro."

        --  Dr. Hunter S. Thompson
===============================================================================

Re: What is wrong with OO ?

[Robert Dewar]

Marin said

"    I liked the book, but I thought there was a certain sort of
    naivete to some of the concepts - especially this one. Yes, there
    is a large class of programs that can be built by a coding
    genius in a garage a lot better/faster/cheaper than by a team of
    average programmers sitting in Dilbert cubicles and forced to
    attend endless status meetings, etc. Especially where one needs to
    get particularly "creative" in inventing new and interesting
    solutions to a problem."


Sounds like you are reacting to the quote, and not to the book. The author
never implies that all code can be built in a garage by two people. I think
you must be misremembering what you read?

Re: What is wrong with OO ?

[Corey Minyard]

> Assembler will ALWAYS be the most efficient language.  The more you
> abstract the problem, the more you "generalize" the solution to a
> given problem, the more you necessarily give up in efficiency.  C
> takes a minimal 3x hit on integer arithmetic, 10x on more complex
> stuff; and OO, because of the overhead interpreting where
> to send things, is 10x on top of that.

These numbers are completely bogus for modern compilers.  There have
been documented cases where compiled code has actually produced faster
code than an experienced human writing assembler.  See the ammunition
section at http://www.adahome.com.  I would expect the numbers for a
compiler would improve with a complex system.

Two factors contribute to this.  Modern optimizing compilers can do
global optimization far beyond what a human could ever do.  This is
why I expect compilers to do better than humans for complex systems.

The other is the state of modern processors.  In the old days,
processors were very simple and so were compilers.  Now, processors
have big pipelines, tons of registers, lots of little tricky speed
optimizations, lots of condition code registers, etc.  I have done
pipeline and register optimization in assembly language for small
routines (50-200 instructions for TMS320C40); it is enough to make
your head hurt.  Although the routines where better than could be
produced by a compiler (they HAD to be fast), they took an extremely
long time to write.  You can spend all day optimizing and debugging
100 instructions.  With VLIW coming, humans optimization anything that
is not dirt simple is just simply not feasible.  A compiler will
always do a better job.

And the OO hit is not 10x.  I have seen numbers on that for C and C++;
although I don't remember them exactly they were in the 20-30% range.

-- 
Corey Minyard               Internet:  minyard@acm.org
  Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "bsamwel" == Bart Samwel <bsamwel@wi.leidenuniv.nl> writes:

>> Assembler will ALWAYS be the most efficient language.  The more you
>> abstract the problem, the more you "generalize" the solution to a
>> given problem, the more you necessarily give up in efficiency.  C
>> takes a minimal 3x hit on integer arithmetic, 10x on more complex
>> stuff; and OO, because of the overhead interpreting where
>> to send things, is 10x on top of that.

bsamwel> IMO this number is only a valid approximation for Smalltalk and
bsamwel> other dynamically typed OO languages. Statically typed
bsamwel> languages like C++ (hybrid, but supporting OO) and Eiffel (pure
bsamwel> OO) achieve a much lower impact on performance than 10x. I
bsamwel> won't give any numbers because I don't have them, but I know
bsamwel> most number-crunching usually runs at very acceptable speed in
bsamwel> these languages; a bit, but not much slower than C.

By using clever implementation tricks (such as dynamic inlining!) many
dynamically typed languages can be just as fast as. Self is claimed to
run at just half the speed of C, and two to three times the speed of
most compiled ``Smalltalk'' implementations (to the point that the
Smalltalk-80 implementation written in Self by Mario Wolzcko usually
runs twice as fast as native commercial ``Smalltalk'' implementations).
Then some Lisp implementations are amazingly fast as well; CMU CL with
the Python compiler can be quite impressive. The NeXT and GNU
Objective-C iplementations have been carefully tuned, and result in
programs usually about as fast as those written in C; for dynamic
resolution is quite fast and is not the dominant overhead. ``Eiffel''
compilers also offer default dynamic resolution which is well optimized.

In many cases high performance is also achieved by analyzing the program
and inferring where dynamic overload resolution is actually not needed...

Re: What is wrong with OO ?

[Pieter Schoenmakers]

In article <5bbcom$gc7@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

   tiggr@es.ele.tue.nl (Pieter Schoenmakers) writes:

   >With any kind of static binding (and inlining is the summum in static
   >binding), the possibilities of dynamically loaded code are limited.  What
   >to do if a dynamically loaded class redefines some feature causing that
   >feature to no longer be statically bindable?  Recompile the whole
   >executable?  --Tiggr

   If you allow new classes to be dynamically loaded, then the compiler
   can't statically bind features of objects whose dynamic type is unknown,
   but it can still statically bind features of objects whose dynamic type
   is known.

If a class B can be dynamically loaded, and B is a subclass of the
statically loaded (i.e. known to the compiler) class A, then every feature
invocation of an object accessed through a variable of type A, where the
actual object could just as well be a B, can not be statically bound or
inlined.  If, in that situation, you inline the feature implementation of
A, and B redefines that feature, the wrong code is executed if the actual
object (still denoted by the variable with type A) is a B and not an A.
--Tiggr

Re: OO, C++, and something much better!

[Don Harrison]

Jon S Anthony writes:

:> Yes. However, I'm not sure whether you lose some of the power of combining 
:> genericity with inheritance through Ada's module-type distinction.
:
:I have never seen any example supporting your "unease" - by you or
:anyone else.

Oh well. 
 
:> genericity in Ada is essentially module-based and inheritance is type-based,
:> I suspect you may lose something here.
:
:Presumably you forgot to add "only" to "inheritance is type-based".

No.

:> No. Ada offers type casting in a couple of ways:
:> 
:>   1) UNCHECKED_CONVERSION and
:>   2) Address representation clauses (overlays).
:
:1. This is not "casting"

1) is; 2) isn't. But both violate safe typing.

:2. It's irrelevant anyway as these are type system trap doors (outside
:   the type system).

Yes. They're loopholes.

:> For example, by using the value of a parent type where a subrange
:> value is required.
:
:Give an example.

Would like to. There's something wrong with the system here at the moment.
If I get an example running, I'll send it to you.

:This sort of thing will be statically checked.

I agree it ought to be.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Don Harrison]

Robert Dewar writes:

:I have been trying to think of a safe way of doing this sort of thing but
:thus far haven't thought of any. :)"
:
:
:Well there obviously is no safe way of doing something whose entire purpose
:is to allow unsafe operations!

Yes, these mechanisms are inherently unsafe but their purpose is to allow 
different views of the same data. There are different ways of acheiving 
that and some ways are safer than others. For example, UNCHECKED_CONVERSION 
is safer than overlaying because the data is copied thus protecting the 
original object.

As you suggest, there's no completely safe scheme of allowing alternate
views.

:Still I would not characterize these as "type casting" in Ada. Rather I 
:would think of them as loopholes, equivalent to calling a C or assembly
:routine. Any formal analysis or discussion of the type system of Ada
:has to ignore these features, and of course any real language to be used
:for low level systems programming needs such features, but I don't think
:it is a useful excercise to include these features in the type analysis.
:
:If you like, consider Ada *minus* these two features as the interesting
:language to be analyzed. Then understand that in real life programs can
:break the bounds of this analysis to the extent they need to.

Agree.

:Note that it is not actually the unchecked conversion that is nasty, since
:the fundamental conversion can be modeled as simply a random mapping between
:values of one type to values of another type. It is that these operations
:can generate abnormal values. 
:
:This may still not be a problem, given that uninitialized values can also
:be abnormal, thus:
:
:  a := nasty_unchecked_conversion (b);
:
:is no worse that not assigning to a at all if a is uninitialized.

True.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Bart Samwel]

Fergus Henderson wrote:

> Usually, people do manage in the end, but then again most software
> produced today is full of bugs.  Usually it works well enough only
> because it has been carefully tested and debugged, but usually it will
> fail when exercised in novel ways.  Choice of programming language is
> certainly not the only or the most important factor in this, but I do
> think that it can make a significant difference.

I certainly agree! The reason I like Eiffel so much is that it has
language support for pre- and postconditions, class invariants, loop
variants and invariants and in-code assertions, which are closely linked
to the exception mechanism. In alpha, beta and gamma releases,
one can compile with a specific subset of these assertions tested at
run time, so that when a program is used in a way it didn't expect and
wasn't prepared for, the program generates an exception. With the
compilers I've seen so far, this results (when no exception handler is
installed) in displaying of the call stack and the precise class and
feature name in which the exception occurred, and the name of the
assertion that failed.

Because of this language support, many of the Eiffel programmers use
these assertions throughout all of their code. They do this because
they know that when something goes wrong, they will more often know
exactly _where_ things went wrong, and _what_ went wrong, without
debugging.

> Yes, but I think one part of that comprehensive process should be
> ensuring that programmers do know the language rules that govern the
> behaviour of the language features that they use.  (It's not too
> important for a programmer to know about the tricky cases if the
> compiler will catch them, but it is important to know about possible
> pitfalls that would not be caught by the compiler and would instead
> result in undefined or implementation-dependent behaviour at runtime.)

And indeed, C++ does have many of these pitfalls, IMHO anyway. There
are languages available that are able to catch many more of these
pitfalls. One of the reasons these languages can catch these pitfalls
better than C++ can is that they are a bit more constrained than C++,
which is not necessarily a Bad Thing.


   Bart

Re: OO, C++, and something much better!

[Robert Dewar]

Don Harrison said

"Yes, these mechanisms are inherently unsafe but their purpose is to allow
different views of the same data. There are different ways of acheiving
that and some ways are safer than others. For example, UNCHECKED_CONVERSION
is safer than overlaying because the data is copied thus protecting the
original object."


That is a misconception. Unchecked_Conversion does not require the data
to be copied. The whole point of 13.9(12) is to remove this requirement:

12   An implementation may return the result of an unchecked conversion by
reference, if the Source type is not a by-copy type.  In this case, the
result of the unchecked conversion represents simply a different (read-only)
view of the operand of the conversion.



The design principle here is that since this is a d0-it-at-your-own-risk
and make-sure-you-know-what-you-are-doing operation, it is inappropriate
to waste time trying to increase the safety of the operation. If you
want to ensure that a copy is made, you must make the copy. Note that
in the common case of:

   a := unchecked_convert (b);

the assignment makes a copy anyway (and this is the case where avoiding
the requirement for unchecked_conversion to make a copy of its own 
improves efficiency -- well to be fair the compiler can optimize this
case since it is transparent, but encouraging return by reference will
generally improve efficiency, and is unlikely to be noticeable.

GNAT does take advantage of this permission where appropriate, and UC
for large objects works by pointer punning if the alignments are
compatible (if the alignments don't match, or more specifically if the
target has a stricter alignment than the source, then of course you have
no choice but to make a copy.

Re: OO, C++, and something much better!

[Ken Garlington]

Don Harrison wrote:
> 
> Robert Dewar writes:
> 
> :I have been trying to think of a safe way of doing this sort of thing but
> :thus far haven't thought of any. :)"
> :
> :
> :Well there obviously is no safe way of doing something whose entire purpose
> :is to allow unsafe operations!
> 
> Yes, these mechanisms are inherently unsafe but their purpose is to allow
> different views of the same data. There are different ways of acheiving
> that and some ways are safer than others. For example, UNCHECKED_CONVERSION
> is safer than overlaying because the data is copied thus protecting the
> original object.

Why does UC require copying? The following code works fine with my copy
of
GNAT, and I've used the same technique on Ada 83 compilers as well...

  with Unchecked_Conversion;
  with Ada.Text_IO;
  procedure Test_UC is

    type My_Integer is new Integer;    
    function To_Int is new Unchecked_Conversion ( My_Integer, Integer );
  
    Foo : My_Integer := 7;
    Bar : constant Integer := 0; 

  begin

    To_Int(Foo) := Bar;
    Ada.Text_IO.Put_Line(My_Integer'Image(Foo));
  
  end;

Re: What is wrong with OO ?

[ak]

Chris Morgan wrote:
> 
> Mark" <mrox@wam.umd.edu> writes:
> 
> > All you guys are talking about is inlining some code!!  Is it really worth
> > this long thread?
> 
> Hint :  Yes!

If so, then please give it a proper subject name that describe 
the case instead of "what is wrong with OO"
This will help the readers to realise the content of the post ..
and anybody not interested should simply skip it

Cheers
   Ak

Re: OO, C++, and something much better!

[Robert I. Eachus]

In article <E3xprM.4pB@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

  > :> No. Ada offers type casting in a couple of ways:
  > :> 
  > :>   1) UNCHECKED_CONVERSION and
  > :>   2) Address representation clauses (overlays).
  > :
  > :1. This is not "casting"

  > 1) is; 2) isn't. But both violate safe typing.

   Casting in C normally maps to type conversions in Ada:

   foo a;
   bar b;
   ...
   b = bar(a);

   Should be translated as:

   A: Foo;
   B: Bar;
   ...
   B := Bar(A);
   -- The case changes are due to standard Ada and C style.

   This in Ada is a completely type safe conversion.  If you want to
go outside the compilers type checking, you can use
Unchecked_Conversion.  But interpret what you are doing correctly.
You the programmer are taking responsibility for doing type checking
which the compiler is unable to do.  There are many uses for
Unchecked_Conversion where this is exactly what is going on...  For
example, in one version of the ADAR components, to preserve the
visible (to the user of the components) type hierarchy, I had to do an
Unchecked_Conversion in the body of one unit--from a derived type to
its parent, but the actual derivation wasn't visible at that point in
the code.

   Doing "punning" using Unchecked_Conversion from the formal point of
view is an error, and Ada compilers are allowed (but not able in all
cases) to detect such violations and raise Program_Error.  For
example, someone was just asking how to do a boolean or on two Ada
strings.  The answer posted was more complex than necessary because it
used Unchecked_Conversion.  An Ada character can be converted to a
(universal) integer type, and "or" exists for unsigned integer types
in Ada 95.  So a better approach would be:

    function "or"(L,R: Character) return Character is
      type Byte is mod 256;
    begin return Character'Val(Byte(Character'Pos(L)) or
                               Byte(Character'Pos(R))); 
    end "or";

    function "or"(L,R: String) return String is
      Result: String(1..L'Length) := L;
    begin
      if L'Length /= R'Length then raise Constraint_Error; end if;
      for I in Result'Range loop
        Result(I) := Result(I) or R(I-R'First+1);
      end loop;
      return Result;
    end "or";

    With appropriate compiler inlining ;-) this should give results as
good or better than the non-portable version, but that is another subject.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: OO, C++, and something much better!

[Norman H. Cohen]

Ken Garlington wrote:

> Why does UC require copying? The following code works fine with my copy
> of
> GNAT, and I've used the same technique on Ada 83 compilers as well...
> 
>   with Unchecked_Conversion;
>   with Ada.Text_IO;
>   procedure Test_UC is
> 
>     type My_Integer is new Integer;
>     function To_Int is new Unchecked_Conversion ( My_Integer, Integer );
> 
>     Foo : My_Integer := 7;
>     Bar : constant Integer := 0;
> 
>   begin
> 
>     To_Int(Foo) := Bar;
>     Ada.Text_IO.Put_Line(My_Integer'Image(Foo));
> 
>   end;

I can confirm that this works on my copy of GNAT too.  The only problem
is that this should NOT work!  (To_Int(Foo) is a function call, not a
variable.)  

RM 13.9(12) mentions that an instance of Unchecked_Conversion can return
its result by reference, meaning that the result is just another view of
the argument (i.e., there is no copying), but it is specifically stated
that this is a read-only view.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Don Harrison]

Jon S Anthony writes:

:> For example, by using the value of a parent type where a subrange
:> value is required.
:
:Give an example.

The following is a valid Ada83 program (and presumably valid Ada95):

procedure Test_Type_Hole is
  subtype Sub_Integer is Integer range 1 .. 10;
  I: Integer;
  S: Sub_Integer;

  procedure Use_Subtype (S: Sub_Integer) is
  begin
    null;
  end;

begin
  I := 1000;
  Use_Subtype (I);       -- System Invalid call - raises 
                         -- Constraint_Error at runtime.
end Test_Type_Hole;

So, contrary to your claim, Ada *does* permit a form of broken polymorphism.


:Don.
:=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
:Don Harrison             donh@syd.csa.com.au
:
:



-- 
Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Chris Morgan]

In article <dewar.853041031@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Chris, if you are really interested in trying this out, do it the simple
> way first. Write an edit script that adds pragma Inline statements to all
> subprograms in all specs, then recompile the program. That way you can
> get some data as to whether this option would be worthwhile.

Robert has told me how to try this out either the above method or a
local gnat tweak, either of which will be fine until (and if) we
identify a firm need for this facility.

We have found manual control of inlining using pragma inline and the
-gnatn option can offer very good performance increases, but I agree
that a brainless "attempt to inline everything" facility is a rather
marginal extra (but I will probably try it when our project gets built).

Chris
-- 
Never run with scissors.

Re: What is wrong with OO ?

[Fergus Henderson]

tiggr@es.ele.tue.nl (Pieter Schoenmakers) writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>   If you allow new classes to be dynamically loaded, then the compiler
>   can't statically bind features of objects whose dynamic type is unknown,
>   but it can still statically bind features of objects whose dynamic type
>   is known.
>
>If a class B can be dynamically loaded, and B is a subclass of the
>statically loaded (i.e. known to the compiler) class A, then every feature
>invocation of an object accessed through a variable of type A, where the
>actual object could just as well be a B, can not be statically bound or
>inlined.

Yes, but often the compiler can prove that the actual object type
must be A, not B.  Some languages, e.g. Ada, allow the programmer to
distinguish between something of type A (meaning just type A, nothing
else) and something of type A'class (meaning something of type A
or some type that inherits from A).  Even if the language doesn't
distinguish, the compiler can often see the type used when an object
is created.

(All I'm trying to say is that you _can_ do useful inter-module
optimization even in the presence of dynamic loading.  Sheesh!)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Robert Dewar]

Ken Garlington wrote

"    type My_Integer is new Integer;
    function To_Int is new Unchecked_Conversion ( My_Integer, Integer );"


Why on earth use an unchecked conversion here when a perfectly ordinary,
and completely safe type conversion will work just fine?

Re: What is wrong with OO ?

[Nick Thurn]

Corey Minyard wrote:
> 
> And the OO hit is not 10x.  I have seen numbers on that for C and C++;
> although I don't remember them exactly they were in the 20-30% range.
> 
My experience with OO suggests there can be a 10x hit for *bad* design.

OO code (C++) can be faster than procedural code because it is 
possible to use more complex algorithms (because you can hide the 
complexity). A *good* OO system *should* be smaller, faster and easier
to
understand than the procedural equivalent. 

The sad fact that many use OO as an excuse to wallow in complexity is
another issue. 

cheers
Nick (my opinions only)

> --
> Corey Minyard               Internet:  minyard@acm.org
>   Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com

Re: OO, C++, and something much better!

[Don Harrison]

Marky Mark writes:

:Don Harrison <donh@syd.csa.com.au> wrote in article
 ^^^^^^^^^^^^
No, it was Bertrand Meyer.

:> :>> 	- A completely consistent type structure, in which 
:> :>> 	  even basic types such as INTEGER are classes,
:> :>> 	  present in the general inheritance structure.
:> :>> 	  (In C++ or Java, for example, the basic types
:> :>> 	  are completely separate from the class and inheritance
:
:Besides, in a hybrid language like C++ you could always have the best of
:both worlds - encapsulating integers as classes or using the intrinsics as
:you'd like.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Don Harrison]

Robert Dewar writes:

:Don Harrison said
:
:"Yes, these mechanisms are inherently unsafe but their purpose is to allow
:different views of the same data. There are different ways of acheiving
:that and some ways are safer than others. For example, UNCHECKED_CONVERSION
:is safer than overlaying because the data is copied thus protecting the
:original object."
:
:
:That is a misconception. Unchecked_Conversion does not require the data
:to be copied. The whole point of 13.9(12) is to remove this requirement:
:
:12   An implementation may return the result of an unchecked conversion by
:reference, if the Source type is not a by-copy type.  In this case, the
:result of the unchecked conversion represents simply a different (read-only)
:view of the operand of the conversion.

Okay. So, in both cases - whether a copy or a reference is returned -  the
source object is protected. Correct? If so, I don't follow why you might
bother making a copy:

:The design principle here is that since this is a d0-it-at-your-own-risk
:and make-sure-you-know-what-you-are-doing operation, it is inappropriate
:to waste time trying to increase the safety of the operation. If you
:want to ensure that a copy is made, you must make the copy.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Jeff Carter]

Don Harrison wrote:
> 
> The following is a valid Ada83 program (and presumably valid Ada95):
> 
> procedure Test_Type_Hole is
>   subtype Sub_Integer is Integer range 1 .. 10;
>   I: Integer;
>   S: Sub_Integer;
> 
>   procedure Use_Subtype (S: Sub_Integer) is
>   begin
>     null;
>   end;
> 
> begin
>   I := 1000;
>   Use_Subtype (I);       -- System Invalid call - raises
>                          -- Constraint_Error at runtime.
> end Test_Type_Hole;
> 
> So, contrary to your claim, Ada *does* permit a form of broken polymorphism.
> 
Nonsense. This is a violation of an explicit precondition (that the
actual value associated with S be in the range of Sub_Integer).
-- 
Jeff Carter
Innovative Concepts, Inc.

Re: What is wrong with OO ?

[Vos nom et pr�nom]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]


Bjarne Stroustrup <bs@research.att.com> a �crit dans l'article
<E3pzy4.DHE@research.att.com>...
...
> 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.

In an absolute way, surely C++ is harder to learn than a lot of other
languages.

Now, let's talk about the "relatively easy to learn". Another way that
effort vs benefit to relativise is language's complexity vs the complexity
of the job to do.
An exemple : if you want to display the "hello world", C++ is not the
better language. 

Conclusion : More and more complex becomes the job to do, the less and less
the language is hard to learn (still talking relatively).
...
> Deciding which member functions should be virtual is a design decision,
> not an optimization. If a designer has provided a poor base class, you
> will typically have problems beyond what can be fixed by overriding.
Just a question about it (I just posted a new thread about this) : when a
member function is better as non virtual ?


-- 
Chris
"The nail pulling up calls the hammer"
                                     zen proverb

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "goubier" == Thierry Goubier <goubier@palmarella.enst-bretagne.fr> writes:

goubier> On 11 Jan 1997, Piercarlo Grandi wrote:
goubier> [On the subject of inlining by the compiler, with B. Meyer]

piercarl> Ideally a compiler would use profiling feedback to evaluate
piercarl> whether it is worth inlining a procedure at a given call site,
piercarl> by running the program with an without (this check ought to be
piercarl> done for each procedure at each call site for which is is
piercarl> possible, and every combination thereof :->).

goubier> I believe this technology already exists, for example in the
goubier> Self 3.0 and 4.0 inlining compilers. Things like polymorphic
goubier> inline caches may be used as a tool to record profiling
goubier> information for the compiler.

From what I have read I haven't the impression that the Self compiler
actually decides _whether_ to inline an implementation using the
profiles/inference used to decide _which_ implementation *can* be
inlined.

In other words, my impression is that Self implementations use
profiles/inference to find out whetherit is _possible_ to inline at some
cal site and which implementatin(s) may be inlined, not whether it is
_useful_ to inline them, and as the latter they use heuristics not
dissimilar from those used in ``Eiffel'' or ``C++'' compilers, such as
the size of the implementation.

Perhaps somebody more familiar with the innards of the Self
implementation can throw some light on this.

BTW, the point I was making above is that one of the great worths of
inlining is that it allows merging the code of the callee in the
caller, and those provides significantly greater/easier opportunities
for optimization. However if there are several call sites of several
different potentially inlinable callees in a given caller procedure,
*which* of these calles at which call sites are worth inlining is not so
obvious for not only merging in the code at each call site with that of
the caller produces _different_ opportunities for optimization, it also
results in merging the codes of the callees as well. *Which* combination
of inlinings is optimal is thus an intricate problem.

Consider the following example (in something like C, so we have that
each implementation has exactly one interface and overload resolution,
offline and inline, does not complicate the picture)

  p(a,b,c)
  {
    .... q1(a); ....
    .... q2(b); ....
    .... q3(c); ....
    .... q1(42); ....
  }

Now each of the four calls to the three implementations might or might
now be worth inlining seaprately; for example 'q1(a)' may not be worth
inlining, but 'q1(42)' later on may well be, because it is passed a
statically know argument. Inlining each of these call sites may produce
positive interactions with the code of their caller. But it may well
happen that inling 'q2(b)' merges in code that then makes the merged in
code of 'q3(c)' significantly more optimizable, but neither call is
worth merging into 'p' on its own.

This effect actually _might_ well be important; after all if there are
several call sites of several procedures in a block it is because they
supposedly cooperate in establishing some result and are thus related,
and this perhaps could well provide good optimizations.

Thus in theory one should verify the possibility for optimization for
every possibly combination of call site inlinings... :-)

What I really think should be done, and this is not a new idea, but one
that is rarely considered, is to do compilers as symbolic reduction
engines, which operate in the domain of instances (that is operate as
intepreters) when such are known and in the domain of abstractions (that
is operate as compilers) when they are not; then inlining would become a
mere byproduct of symbolic reduction between dependent modules.

goubier> But I should let interested people look the Cecil/Vortex
goubier> project to see how this may be used in static compilation. [
goubier> ... ]

That's very interesting work. I also hope that Sun be deploying their
Self technology towards the Java compiler, for it is claimed rather
convincingly that the Self compiler technology can result in Self or
``Smalltalk'' code that runs only twice as slow as C code. Given that
Java is a more constrained sort of language than Self or ``Smalltalk'',
the same technology should get it to deliver much the same performance
as statically compiled C, while instead being dynamically compiled.

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "martin" == Martin ELLISON <martin@mpce.mq.edu.au> writes:

martin> Why can't the compiler optimise the whole program? (Assuming
martin> that it is all written in the same language). Who says that you
martin> have to compile and generate code for each module and then link
martin> them together? Doing so may be quicker for a development
martin> version, but surely a production compile can be optimised across
martin> the whole system.

This is more or less what Ole Agesen has done for type inference in Self
for the production of shrink wrapped applications...

The problem with type inference and OO is that OO modules are supposedly
designed to be as resuable as possible, that is as generic as
possible. Thus type inference returns wide sets of types for
constraints; consider for example a stack class: you can infer that all
variables in it will have a type constraint like 'Object', that is
anything.

Unfortunately such tyep inference is next to useless, for type ifnerence
results in significant safety advantages when type constraints are
narrower, and in optimization when type constrains are narrowest, that
is about a single type.

Since supposedly an OO program is composed mostly of reusable modules,
which are written to be as generic as possible, the situation seems
hopeless.

What Oleg Agesen has done for Self is a kind of type-based ``tree
shaker''; it is base don the idea that if one infers type on reusable
modules *in the context of each application in which they are reused*
then type inference can become significantly stronger (the price of
course one payus to take advantage of it is then code duplication).

So for example a matrix package which is otherwise totally generic can
in the context of a numerical application to be about matrixes of
floats, and in the context of a graphics application to be about
matrixes of integers/pixels.

What then happens is that the whole source of the application is
examined at the same time, and the type constraints of the application,
which are usually quite specific, are propagates across call sites back
to the generic reuable modules that i t references, and these are
specialized for those type constraints. The specialized modules are then
optimized mercilessly as a whole.

This technique naturally has some severe limitations; in practice it is
only useful to develop shrink wrapped, standalone applications, for it
involves a stark tradeoff between code replication and slowness.

Very vaguely similar techniques are used in recent versions of some
``C++'' implementations where template instantion/inlining is in effect
done by the linker in a somewhat clumsy iterative way; or the programmer
does inference by hand listing which templates instances are neded, like
in ``Ada''.

I may be wrong, but the Sather compiler does much the same automatic
process (less clumsily) of global inference and instantiation; in this
is is significantly helped by the rather regrettable limitation which
still exists AFAIK that Sather does not allow separate compilation, so
all modules are merged as _sources_, and (possibly slow) compilation
then on the full source (application plus reusable modules).

Re: OO, C++, and something much better!

[Michael F Brenner]

   > Why does unchecked_conversion require copying? The following 
   > code works fine with my copy of GNAT, and I've used the same 
   > technique on Ada 83 compilers as well...

First, the code in that post gets the following error message
under gnat:

    spectre% gnatmake test_uc
    gcc -c test_uc.adb
    test_uc.adb:13:12: left hand side of assignment must be a variable
    gnatmake: "test_uc.adb" compilation error

Second, unless the code generator in the compiler includes specific
copy optimizations to eliminate the copy, unchecked_conversion is
in the form of a function which logically returns a copy of the 
argument. Unless the compiler has this optimization the code will
make a copy. This is in contrast to the situation where you use
address clauses to overlay variables. Then the two variables are
permanent aliases to each other, and you do not have to copy
the value from one to the other. 

There are many algorithms in mathematics that require an object of 
one type to be considered as an object of another type, for example,
fast Fourier transforms, set membership, ASCII to numerical conversion,
braid group conjugacy, floating point normalization, integer square
root, extracting bits from binary numbers, binary radix exchange
sorting, hash codes, multiple precision integer division, parity bits,
garbage collectores, cyclical redundancy checks, segmenting, and 
pixel maps. In each of these cases, an ordinary exact number (which
happens to be a twos complement on every CPU that survived the
IBM PC era), needs to be viewed as an algebraic integer with
Addition, Subtraction, Multiplication, and Division, YET at the
same time, as a bit string to do And, Or, Xor, Substr, Set_bit,
Set_substr, First_nonzero_bit, Impl, Nand, Nor, Next_bit, and
Bit_merge sequentially according to a bit_pattern_vector. In 
all of these algorithms there is one choice of representing
the <Number As Bitstring> two different memory addresses
with an unchecked_conversion to get the data from one address
to the other. And there is another choice to represent it
as two objects of different types at the same memory
address with an address clause. Without a copy optimization
to remove the copy implied by the output of the function
unchecked_conversion (or any other function), the algorithms
which use unchecked_conversion will run slower than those
using the address overlay technique.

In some cases, such as FFTs and hash codes, that copy time can
occur several times and add up to more than the rest of the
algorithm, so there is evidence for requiring support for
address overlays, and for asking vendors to improve the  
code generation of their compilers to automatically alias
the addresses of objects being converted through unchecked
conversion to their targets address, when this can be done,
so that no copy has to take place. 

Purists sometimes forbid explicit aliasing via addressing overlays.
But that can be short-sighted for the above algorithms, because
aliasing in the address dimension also occurs whenever
a variable has more than one name: equivalences, renames, overlays, 
common variables, objects with tags or discriminants, polymorphisms, 
external objects shared with other languages, parameters passed by 
reference, and pointers. The last three are more troublesome
than the rest (for analysis tools) because they potentially 
involve multiple copies of pointers. Aliasing also occurs in 
the name dimension when a name can refer to two different objects, 
e.g., array elements, homonyms, and inheritance. 

Re: OO, C++, and something much better!

[Don Harrison]

Ken Garlington writes:

:> Yes, these mechanisms are inherently unsafe but their purpose is to allow
:> different views of the same data. There are different ways of acheiving
:> that and some ways are safer than others. For example, UNCHECKED_CONVERSION
:> is safer than overlaying because the data is copied thus protecting the
:> original object.
:
:Why does UC require copying? 

It may not, as Robert Dewar suggests. However, IMO, the source object should
be protected from corruption by any alternative view of its data. One way is
by copying it.

BTW, your program contains an illegal assignment to a function! :)

:    To_Int(Foo) := Bar;
                 ^^


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Vos nom et pr�nom]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]


Piercarlo Grandi <piercarl@sabi.demon.co.uk> a �crit dans l'article
<yf3afqg12ho.fsf@sabi.demon.co.uk>...
> >>> "bertrand" == Bertrand Meyer <bertrand@eiffel.com> writes:
> 
> bertrand> The ISE Eiffel compiler performs inlining completely
> bertrand> automatically.  There is no "pragma inline" or comparable
> bertrand> programmer intervention, since it is not the programmer's job
> bertrand> to worry about whether a routine is inlinable or not. This is
> bertrand> a job for a compiler.
> 
> It seems contrary to reasonabless: there are many contexts where
> inlining is not necessary and others in which it is important, *even for
> the same procedure*. Thus there is (usually) a space/time tradeoff, but
> *at each call site*. It sounds astonishing to me an argument that the
> compiler should try to second guess or infer space/time tradeoffs
> (except perhaps in the simplest cases), in addition to doing its job of
> compiling valid translations of a source.
etc...

Here's my 2cts...
If the function is very short, it's obvious for the compiler to
automatically inline it.
When it's long, it's also obvious not to make it inline.
But where is the point where the short function becomes a long function ?
For all these cases, it's the programmer's responsability to inline or not
regarding size vs speed.

-- 
Chris
"The nail pulling up calls the hammer"
                                     zen proverb

Re: What is wrong with OO ?

[Marin David Condic, 561.796.8997, M/S 731-93]

Robert Dewar <dewar@MERV.CS.NYU.EDU> writes:
>Note that there *is* no way in the Ada *language* of forcing or preventing
>inlining. The use of pragma inline simply controls whether certain body
>dependencies are allowed to be created.
>
    Good point. I can see that it's not specifically a language issue
    - that any legal implementation of what the source specified is
    fair game. I'd just hope that those who were writing compilers for
    the embedded marketplace would provide some measure of control
    over it. (I've used some very fine compilers that produce very
    efficient code and I've *still* wished the compiler gave me the
    ability to turn on/off specific optimizations individually.
    Worrying about the exact form of the code you get out is much more
    important in the embedded world.)

    Or maybe it would be fair if the implementation at least *warned*
    you that it was inlining specific routines? Nahhh! I still need to
    be able to say "don't do it because I've got verification issues."

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "Whatever is not nailed down is mine. Whatever I can pry up is not
    nailed down."

        --  Collis P. Huntington, railroad tycoon
===============================================================================

Re: What is wrong with OO ?

[Vos nom et pr�nom]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]


Corey Minyard <minyard@acm.org> a �crit dans l'article
<m26812ld16.fsf@acm.org>...
> > Assembler will ALWAYS be the most efficient language.  The more you
> > abstract the problem, the more you "generalize" the solution to a
> > given problem, the more you necessarily give up in efficiency.  C
> > takes a minimal 3x hit on integer arithmetic, 10x on more complex
> > stuff; and OO, because of the overhead interpreting where
> > to send things, is 10x on top of that.

I agree. Assembler is the fastest when (and because you can in assembler)
you wrote specialized routines. For more generalized routines, compilers
are becoming quite as good optimizers to perform the job (closely) like any
assembly programmer.

But in most systems, time is spent in OS (or waiting I/O). Most
applications are databases. Assembler for these ones is irrelevant.
Assembler is useful for complex calculus.

But only critical parts (the most often used) of the code should be written
in assembler because finding more efficient algorythms gives generally far
more improvements that just rewriting the C++ code in assembler.

Because C++ is HLL, we can try many algorythms easier and quicker than we'd
do in assembly.


-- 
Chris
"The nail pulling up calls the hammer"
                                     zen proverb

Re: What is wrong with OO ?

[Jay Martin]

lga@sma.ch (Laurent Gasser) writes:

>In article <dewar.853091062@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>> Jay said
>> 
>> "Here is an even more ignorant question: Why is compilation time still
>> a driving factor? (excluding hardcore optimizations) Obviously it
>> still is as I watched large systems compile lately.  But wait, wasn't
>> Turbo Pascal long ago seemly compile stuff faster on a 4.77MHz PC
>> faster than VC++ on my P5-100.  For fun I compiled old programs with
>> vintage a Turbo Pascal Compiler and it seems to compile these suckers
>> instantanously!"
>> 
>> Yes, but the quality of code turned out by your "vintage Turbo pascal
>> compiler" is truly horrible. 
>[ sound arguments about global optimization and inlining deleted ]

>I am no more sure about the fact for Turbo Pascal.  But it may had used 
>the same strategy than Think Pascal on Mac (once a Lightspeed product, 
>still sold by Symantech today, a record sale life span).  The compilation 
>was extra speedy because the syntax tree building was embodied in the editor.

>While you typed down the source, the syntax was checked and the front
>part of the compilation (decorated syntax tree) was done.

Turbo Pascal was a normal compiler.  

Going back to the original question: I understand that a compiler can
spend an practically infinite time optimizing, but when optimizations
are disabled or restricted to the typical simple ones it still seems
to me that compilers have not kept up with processor speeds.  Its as
if compilers are parallelling the code bloat practices of other
software areas, eating processor cycles as they come available.
Suppose optimizations give a factor of 2X-3X, why would I bother
turning on the time consuming optimizations early in a project needing
a rapid development cycle?  (Though optimized builds could be continiously
be built as a background task)  

Jay

Re: OO, C++, and something much better!

[Don Harrison]

Jeff Carter writes:

:> So, contrary to your claim, Ada *does* permit a form of broken polymorphism.
:> 
:Nonsense. This is a violation of an explicit precondition (that the
:actual value associated with S be in the range of Sub_Integer).

It's both and it shows that Ada is not typesafe.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[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

Re: What is wrong with OO ?

[Bjarne Stroustrup]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

 > Bjarne, in the middle of a very nice extended discussion of C++, says
 > 
 > "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."
 > 
 > Hmmm! I don't think I buy that. People will learn what is at hand pretty
 > much regardless of whether something is easy to learn and use.
 > ...
 > Going back to the main subject, which is the allegation that popularity
 > indicates ease of learning and use,

I don't think I claimed that, and I don't think that I have to. C++ use grew
very nicely for years without hype. I base my statement on years of looking
at C++ use, teching, and learning - many of those years were before anyone
was given time off from their day job to learn C++.

I think that if C++ was as hard to understand and use as some people claim,
it would have failed to become popular in the first place and would have
vanished under the continuous barrage of fair and unfair criticism - despite
its (eventual) popularity.

 >  I think the point is that such
 > popularity indicates accesibility more than anything else. By accessibility
 > I mean that something is available, viewed as hot, and can be learned well
 > enough to do *something*. Consider the situation today, students want to
 > learn Java, not C++, they see C++ as yesterday's language, and Java as
 > the language of tomorrow. Just from the incredible rate at which Java books
 > are cascading into bookstores, I have to guess that the rate of learning of
 > Java far exceeds the rate of learning of C++. But I would NOT conclude from
 > this that Java is easier to learn or use than C++. Maybe it is, but you
 > cannot conclude anything just from popularity.

It is amazing what hype and serious marketing dollars can do, but what
little objective data I can lay my hands on indicates that C++ use is
still increasing very nicely. However, I have my doubts whether all of
those books will actually help the Java community. 

I have often found myself wondering if the C++ wouldn't have been much better
for all concered had there (just) been two dozen good C++ books instead of
the 400+ books that mostly fail to teach the basic principles and mostly
lead students and programmers astray. The snag, of course, is that we have
no mechanism of separating the good from the bad. I doubt such a mechanism
could exist - at least while things change as fast as they do in our industry
and we have little agreement on what is good and bad.

 > Ada folks have never played the game of claiming popularity as an indicator
 > of any kind of quality, because they have not been able to. I realize that
 > C++ is in a position to make such claims, but I recommend against it, because
 > I think you will find that your arguments will backfire as Java becomes
 > the next hot language, at least for a while :-)

Thanks for the advice. The furthest I go is to claim that unless C++
had at least some of the virtues I claim for it, it would have died during
the early years where there were essentially no C++ marketing and alternatives
languages with marketing dollars behind them existed.

Naturally, even that is invariably mistaken for the disreputable "5 million
morons cannot be wrong" argument :-(

	- Bjarne

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

Re: OO, C++, and something much better!

[Don Harrison]

Robert I. Eachus writes:

:   Casting in C normally maps to type conversions in Ada:

Okay.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Laurent Gasser]

In article <dewar.853091062@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Jay said
> 
> "Here is an even more ignorant question: Why is compilation time still
> a driving factor? (excluding hardcore optimizations) Obviously it
> still is as I watched large systems compile lately.  But wait, wasn't
> Turbo Pascal long ago seemly compile stuff faster on a 4.77MHz PC
> faster than VC++ on my P5-100.  For fun I compiled old programs with
> vintage a Turbo Pascal Compiler and it seems to compile these suckers
> instantanously!"
> 
> Yes, but the quality of code turned out by your "vintage Turbo pascal
> compiler" is truly horrible. 
[ sound arguments about global optimization and inlining deleted ]

I am no more sure about the fact for Turbo Pascal.  But it may had used 
the same strategy than Think Pascal on Mac (once a Lightspeed product, 
still sold by Symantech today, a record sale life span).  The compilation 
was extra speedy because the syntax tree building was embodied in the editor.

While you typed down the source, the syntax was checked and the front
part of the compilation (decorated syntax tree) was done.

So, when you finally decided to see it running, it only had to generate
the object code and link.

The strategy seemd to be one cause of the abandon of Think Pascal (it still 
only generates 68K, and never did the PowerPC leap).  Today, compiler favor 
a much clearer separation with text editors.

-- 
Laurent Gasser (lga@sma.ch)
Computers do not solve problems, they execute solutions.

Re: What is wrong with OO ?

[Jonas Nygren]

Laurent Gasser wrote:
> 
> I am no more sure about the fact for Turbo Pascal.  But it may had used
> the same strategy than Think Pascal on Mac (once a Lightspeed product,
> still sold by Symantech today, a record sale life span).  The compilation
> was extra speedy because the syntax tree building was embodied in the editor.
> 
> While you typed down the source, the syntax was checked and the front
> part of the compilation (decorated syntax tree) was done.
> 
> So, when you finally decided to see it running, it only had to generate
> the object code and link.
> 

Ah yes, Lightspeed, in my case C, defines what an IDE should be.
Lightning
fast compilation, as Laurent stated, but also linking. LC did not really
link the application when it was inside the IDE, only if you wanted to 
generate a standalone app. The '.o' files were kept linked together in
memory 
and after a file had been compiled these linked '.o' files were patched
up
to link in the new '.o' file, and then the IDE executed the image given
by the
linked '.o' files.

I remember I had a GUI app on my MacPlus where the cycle 'stop testing -
fix something small - compile - link - ready to test again' was under 30
secs,
with a M68000 ~7 MHz!!

I still haven't found anything as fast :-( 

/jonas

Re: OO, C++, and something much better!

[Richard Kenner]

In article <dewar.852928982@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>equally if you do something like
>
>   (x = p; x < &p[10]; p += 3)
>
>you can find you have an infinite loop, all quite in accordance with the
>C semantics, although somewhat surprising.

This case must work.  Such a reference to the end of an object is required
to be treated like a reference within the object.

Re: OO, C++, and something much better!

[Ken Garlington]

Robert Dewar wrote:
> 
> Ken Garlington wrote
> 
> "    type My_Integer is new Integer;
>     function To_Int is new Unchecked_Conversion ( My_Integer, Integer );"
> 
> Why on earth use an unchecked conversion here when a perfectly ordinary,
> and completely safe type conversion will work just fine?

Because then it wouldn't demonstrate the use of an unchecked conversion,
would it?
(I _knew_ someone was going to ask that. :)

Anyway, if it didn't already get posted, the example is wrong. It works
with GNAT 3.05,
but is flagged as a compile-time error in 3.07. However, via access
values, an
unchecked conversion could still be used without creating a copy, so the
comment is
still valid: using address specs to create an overlay should not be
significantly less/more safe than unchecked_conversion, at least not for
the reason originally given...

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <5bie2d$eat$1@news.nyu.edu> kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

   In article <dewar.852928982@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
   >equally if you do something like
   >
   >   (x = p; x < &p[10]; p += 3)
   >
   >you can find you have an infinite loop, all quite in accordance with the
   >C semantics, although somewhat surprising.

   This case must work.  Such a reference to the end of an object is required
   to be treated like a reference within the object.

Yes, indeed it must work, and it does, but it IS an infinite loop.
So it is probably not what you wanted the program to do....

Ole-Hj. Kristensen

Re: OO, C++, and something much better!

[Fergus Henderson]

kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

>In article <dewar.852928982@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>>equally if you do something like
>>
>>   (x = p; x < &p[10]; p += 3)
>>
>>you can find you have an infinite loop, all quite in accordance with the
>>C semantics, although somewhat surprising.
>
>This case must work.  Such a reference to the end of an object is required
>to be treated like a reference within the object.

No, you missed the subtle point of Robert Dewar's example.
(Robert could obviously get a job advertising PC-LINT if he wanted ;-)
If it was `p++' rather than `p += 3', you would be right, but
since it is `p += 3', the behaviour is undefined -- ANSI/ISO C
only allows a reference to one past the end of an object, not
two past the end.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Marin David Condic, 561.796.8997, M/S 731-93]

Robert Dewar <dewar@MERV.CS.NYU.EDU> writes:
>Sounds like you are reacting to the quote, and not to the book. The author
>never implies that all code can be built in a garage by two people. I think
>you must be misremembering what you read?
>
    It's been a while since I read the book - true. And yes, I may be
    reacting more to the comments than the content of the book. But I
    seem to recall that Brooks had some sort of idea about a "Software
    Surgical Team" which had the coding genius as "head surgeon" and
    the rest of the staff working for the coding genius - which sounds
    a _little_ like the couple of guys working in the garage scheme.

    While I'd personally like to be declared "head surgeon" and have
    the whole staff put to work for me, I'm not convinced that this
    will ever happen (unless I start generating code in my garage! ;-)
    A small fact of life standing in the way is that it's the guys who
    control the ca$h who will always control the operation. You can
    choose to spend your time writing software or writing budgets &
    schedules. It's pretty hard to do both.

    Still, it's nice to dream, eh?

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "Languages don't kill people. *Programmers* do!"

        --  Rich Stewart - Language Lawyer & Language Control Opponent.
===============================================================================

Re: What is wrong with OO ?

[Richard Kenner]

In article <dewar.852912391@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>Indeed the most efficient way to write assembly language might well be to
>use the machine insertions available in many compilers (including GCC
>and GNAT) that allow you to write register independent code, and then let
>the optimizer circuits of the compiler do register allocation and 
>instruction scheduling on the instructions you write.

This is actually not as straightforward as it might seem since there needs
to be a way of describing the scheduling attributes of the instructions
you write and such a mechanism would be tricky (GCC and GNAT don't
support it, for example).

However, some assemblers will do instruction scheduling.

Re: OO, C++, and something much better!

[Ken Garlington]

Keith Thompson wrote:
> 
> In <dewar.853194201@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> > Ken Garlington wrote
> >
> > "    type My_Integer is new Integer;
> >     function To_Int is new Unchecked_Conversion ( My_Integer, Integer );"
> >
> >
> > Why on earth use an unchecked conversion here when a perfectly ordinary,
> > and completely safe type conversion will work just fine?
> 
> 1. I think it was meant to be a simple example of what you can do
>    Ada.Unchecked_Conversion, not a useful program.
> 
> 2. A simple conversion wouldn't work; you can't assign to a conversion
>    (unless passing it as an "out" or "in out" parameter is considered
>    assignment).
> 
> 3. Actually, Unchecked_Conversion won't work either; an earlier version
>    of GNAT incorrectly allowed assignment to an Unchecked_Conversion.

As do various Ada83 compilers (which is why I tried it in the first
place!)

> If you really want a writable view of an object with a type other than the
> object's declared type, you can use 'Access and Unchecked_Conversion on
> access types, though it's generally simpler to do an Unchecked_Conversion
> on the type itself in the opposite direction.  Be careful; it's really
> easy to get erroneous execution this way.
> 
> --
> Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
> TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
> 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
> "SPOON!" -- The Tick

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Keith Thompson]

In <dewar.853194201@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Ken Garlington wrote
> 
> "    type My_Integer is new Integer;
>     function To_Int is new Unchecked_Conversion ( My_Integer, Integer );"
> 
> 
> Why on earth use an unchecked conversion here when a perfectly ordinary,
> and completely safe type conversion will work just fine?

1. I think it was meant to be a simple example of what you can do
   Ada.Unchecked_Conversion, not a useful program.

2. A simple conversion wouldn't work; you can't assign to a conversion
   (unless passing it as an "out" or "in out" parameter is considered
   assignment).

3. Actually, Unchecked_Conversion won't work either; an earlier version
   of GNAT incorrectly allowed assignment to an Unchecked_Conversion.

If you really want a writable view of an object with a type other than the
object's declared type, you can use 'Access and Unchecked_Conversion on
access types, though it's generally simpler to do an Unchecked_Conversion
on the type itself in the opposite direction.  Be careful; it's really
easy to get erroneous execution this way.

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: What is wrong with OO ?

[Patrick Doyle]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]


In article <01bbd23a$5b667cc0$LocalHost@christophe-leph>,
Vos nom et pr�nom <gaijin@infonie.fr> wrote:
>Just a question about it (I just posted a new thread about this) : when a
>member function is better as non virtual ?

  Suppose a function does some important manipulation of private data
members.  If it were virtual, then an heir class could override this
function without ever calling it, and the data manipulation would never
happen.  This could leave the object in an invalid state.  In C++, the
only way to prevent this is by NOT declaring the function virtual.

  In Eiffel, I presume, this could be prevented using postconditions?


-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: What is wrong with OO ?

[Patrick Doyle]

In article <01bc03db$2de477c0$ba1e1990@ap352pc.us.oracle.com>,
Risto Lankinen <rlankine@us.oracle.com> wrote:
>
>Patrick Doyle <doylep@ecf.toronto.edu> wrote in article
><E440xD.Lu0@ecf.toronto.edu>...
>> 
>>   Suppose a function does some important manipulation of private data
>> members.  If it were virtual, then an heir class could override this
>> function without ever calling it, and the data manipulation would never
>> happen.  This could leave the object in an invalid state.  In C++, the
>> only way to prevent this is by NOT declaring the function virtual.
>
>This is true.  I would like to add, that if *both* the important data
>manipulation *and* virtualness are needed, then there is still a way
>to do it.  Here's how:
>
>--------------------------------------------------
>class Base
>{
>private:
>   virtual void Function_imp()

  I was not aware that private virtual functions existed.  Can a descendant
class override this function even though it does not have access to it?

>Note that *IF* the Java keyword 'final' was also in C++ (in Java
>it means that a member function cannot be overridden, or a class
>cannot be derived) then in the example, 'Base::Function()' could
>itself be a virtual function derived from yet-another-base, but
>then overridden and declared as 'final'.  Obviously this would
>make it possible to stack postcondition checks by doing the same
>'final'-trick to 'Derived::Function_imp()' and have it call, say,
>private virtual 'Function_imp_imp()' that *its* derived classes
>can override...

  Woah, sorry, you lost me here.  Do you have an example of what you're
thinking of?

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: What is wrong with OO ?

[Risto Lankinen]

Hi!

Patrick Doyle <doylep@ecf.toronto.edu> wrote in article
<E440xD.Lu0@ecf.toronto.edu>...
> 
>   Suppose a function does some important manipulation of private data
> members.  If it were virtual, then an heir class could override this
> function without ever calling it, and the data manipulation would never
> happen.  This could leave the object in an invalid state.  In C++, the
> only way to prevent this is by NOT declaring the function virtual.

This is true.  I would like to add, that if *both* the important data
manipulation *and* virtualness are needed, then there is still a way
to do it.  Here's how:

--------------------------------------------------
class Base
{
private:
   virtual void Function_imp()
   {
      // enforce preconditions
      // do 'Base' stuff
   }

public:
   void Function();
   {
      // do some important manipulation of private data
      Function_imp();
      // do more important manipulation of private data
      // enforce postconditions
};

class Derived : public Base
{
private:
   virtual void Function_imp()
   {
      // enforce preconditions
      // do 'Derived' stuff
   }
};
--------------------------------------------------

Then, any derived class can override the implementation, while
the public interface remains the same (hence the postconditions
are checked whenever the method is called, and the integrity of
the object becomes easier to maintain).

Note that *IF* the Java keyword 'final' was also in C++ (in Java
it means that a member function cannot be overridden, or a class
cannot be derived) then in the example, 'Base::Function()' could
itself be a virtual function derived from yet-another-base, but
then overridden and declared as 'final'.  Obviously this would
make it possible to stack postcondition checks by doing the same
'final'-trick to 'Derived::Function_imp()' and have it call, say,
private virtual 'Function_imp_imp()' that *its* derived classes
can override...

terv: Risto

Re: What is wrong with OO ?

[Risto Lankinen]

Hi!

Patrick Doyle <doylep@ecf.toronto.edu> wrote in article
<E448IK.4qI@ecf.toronto.edu>...
> In article <01bc03db$2de477c0$ba1e1990@ap352pc.us.oracle.com>,
> 
>   I was not aware that private virtual functions existed.  Can a
descendant
> class override this function even though it does not have access to it?

Sure can.  The descendant cannot, however, *call* the base version.
Also, the descendant is responsible for using the proper protection
for its own version: 'Derived::Function_imp' can be made public if
that is desired.

> >Note that *IF* the Java keyword 'final' was also in C++ (in Java
[blah blah blah]
> >can override...
> 
>   Woah, sorry, you lost me here.  Do you have an example of what you're
> thinking of?

Here is (in a hypothetical language that looks like C++ but has a
keyword 'final' to declare a class that cannot be derived from; or
a class method that cannot be overridden by a method in a derived
class):

---------------------------------------------
class Bottom
{
public:
   virtual void do()
   {
      // do what bottom objects do
   }
};

class Middle : public Bottom
{
private:
   virtual void do_imp()
   {
      // do what middle objects do
   }

public:
   final void do() // <<<<<<<<<<<< see below (#)
   {
      // middle preconditions
      do_imp();
      // middle postconditions
   }
};

class Top
{
private:
   virtual void do_imp()
   {
      // do what top objects do
   }
};
---------------------------------------------

Note (#):
In original example this function was a non-virtual.  Here, it is
an inherited virtual.  Alas, declaring it 'final' prevents it from
being overridden by any derived class.

If 'Middle::do()' was non-final, the programmer of class 'Top' may
be tempted to override that instead of 'do_imp()', shortcutting the
integrity maintenance performed by 'Middle::do()'.

Furthermore, if class 'Top' has a reason to make its postcondition
more strict, it can declare 'do_imp()' as 'final', and have its own
implementation call a private virtual 'do_imp_imp()'.  Here is such
modified definition of class 'Top' (note how it looks like 'Middle'
in previous example):

---------------------------------------------
class Top
{
private:
   virtual do_imp_imp()
   {
      // do what top objects do
   }

   final void do_imp()
   {
      // top preconditions
      do_imp_imp();
      // top postconditions
   }
};
---------------------------------------------

When a 'Top' object is passed to a function as a 'Base' pointer
or a reference, it performs the following calls, when 'do()' is
called:

   do() [Middle]
    + // middle preconditions
    + do_imp() [Top]
    |  + // top preconditions
    |  + do_imp_imp() [Top]
    |  |  + // do what top objects do <<<<<<<< see below (@)
    |  + // top postconditions
    + // middle postconditions

Note (@):
Because 'Middle::do()' and 'Top::do_imp()' would be final, the
only function that could be overridden is do_imp_imp().  Note,
that doing so cannot by-pass any of the integrity maintenance
that are performed by some of its base classes.

terv: Risto L.

Re: What is wrong with OO ?

[Mark Woodruff]

Vos nom et pr�nom wrote:

> If the function is very short, it's obvious for the compiler to
> automatically inline it.
> When it's long, it's also obvious not to make it inline.

When should a call to Ackerman() be inlined? Or exit()?

Key questions seem to be: 

What information is required to make the decision?
Can the information be represented programatically?
Can an algorithm be written to make the decision?

I'm not convinced it's decidable because performance criteria frequently can't be 
determined in advance. Should a function be inlined if the resultant code pushes 
code onto a new page and causes page faults?
-- 
My views may reflect the presence of the company I'm in
but don't reflect my company's views nor my clients.

Re: What is wrong with OO ?

[Lawrence G. Mayka]

bs@research.att.com (Valerie Torres) wrote:

>In the area of exceptions, C++ may have added something important:
>C++ exceptions can be of arbitrary type and inheritance is taken
>into account when catching an exception. This provides important
>possibilities for grouping exceptions that I don't know precedence
>for (though the need for grouping has been known for decades).

The use of inheritance in defining and handling conditions dates at
least back to Symbolics' New Error System, circa 1984, which was the
forerunner of the Pittman Condition System, circa 1985.  The latter
quickly found its way into the other commercial Common Lisp
implementations and was incorporated into ANSI Common Lisp.


Lawrence G. Mayka
lgmayka@sprynet.com

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "gaijin" =3D=3D Vos nom et pr=E9nom <gaijin@infonie.fr> writes:

piercarl> It seems contrary to reasonabless: there are many contexts
piercarl> where inlining is not necessary and others in which it is
piercarl> important, *even for the same procedure*. Thus there is
piercarl> (usually) a space/time tradeoff, but *at each call site*. It
piercarl> sounds astonishing to me an argument that the compiler should
piercarl> try to second guess or infer space/time tradeoffs (except
piercarl> perhaps in the simplest cases), in addition to doing its job
piercarl> of compiling valid translations of a source.

gaijin> Here's my 2cts...  If the function is very short, it's obvious
gaijin> for the compiler to automatically inline it.  When it's long,
gaijin> it's also obvious not to make it inline.  But where is the point
gaijin> where the short function becomes a long function ?  For all
gaijin> these cases, it's the programmer's responsability to inline or
gaijin> not regarding size vs speed.

Those are good points, but not necessarily true. The situation is
*really* subtler than most people think.

Consider the two extremes:

Should we always inline very short functions?

  Not necessarily, because this makes a number of activities, from
  profiling to debugging/backtracing rather harder, for it breaks simple
  correspondences between the structure of the source and that of the
  generated code. Also, it is not always worth doing it, and by default
  it should not be done unless there is a clear advantage; consider for
  example an inline functione like:

    vs(x) { return (x > 0) ? take_a_long_time : also_take_along_time)() ; }

Should we always leave outofline very long functions?

  Not necessarily, because when they are inlined they might shrink
  dramatically. Consider:

    vl(x) { if (x < 0) return 0; else { ... /*lots of lines*/ }; }
    ....
    vl(-23); // this is worth inlining

Again the choice depends often on the context of the call site.

Re: What is wrong with OO ?

[Michael Malak]

In article <5bo7nq$b8b@news.istar.ca>,
Tom Bushell <tbushell@fox.nstn.ns.ca> wrote:
>
>As I believe someone else already pointed out, the C++ compiler
>convention of creating an optimized, native code, standalone
>executable file on disk is ass backwards - this should be a batch
>operation that is performed once to create the production version of
>the program.  The rest of the time, it is much more important to allow
>rapid turnaround for modifications, at the expense of execution speed
>if necessary.

The reason C++ is not interpreted is because there don't even exist
correct C++ _compilers_ that conform to the ANSI Draft Working Paper.
And the reason for that, of course, is because C++ is a complicated,
quickly evolving (mutating?) language.

-- 
Michael Malak         Magic forwarding e-mail address:
Washington, DC        malak@acm.org

Re: What is wrong with OO ?

[Tom Bushell]

On Wed, 15 Jan 1997 14:13:05 +0100, Jonas Nygren
<ehsjony@ehs.ericsson.se> wrote:

>
>I remember I had a GUI app on my MacPlus where the cycle 'stop testing -
>fix something small - compile - link - ready to test again' was under 30
>secs,
>with a M68000 ~7 MHz!!

30 seconds seems like a lifetime after you get used to RAD languages
like Smalltalk, VB, or Prograph.  Turnaround is instant, and you can
usually fix the program _while it is running_ - no need to even
restart.  This allows the programmer to much more easily stay in an
immersive state of "flow", and probably accounts for a large portion
of the productivity gains possible with these language/environments.

As I believe someone else already pointed out, the C++ compiler
convention of creating an optimized, native code, standalone
executable file on disk is ass backwards - this should be a batch
operation that is performed once to create the production version of
the program.  The rest of the time, it is much more important to allow
rapid turnaround for modifications, at the expense of execution speed
if necessary.

I was impressed by the description of Eiffel's approach to this -
sounds exactly right to me.

-Tom



----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <E42nv9.LL7@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> Jeff Carter writes:
> 
> :> So, contrary to your claim, Ada *does* permit a form of broken polymorphism.
> :> 
> :Nonsense. This is a violation of an explicit precondition (that the
> :actual value associated with S be in the range of Sub_Integer).
> 
> It's both and it shows that Ada is not typesafe.

Sorry, Don.  You are in the weeds.  It shows absolutely nothing of the
kind.  Ada may or may not be "type safe" but your absurd example has
nothing to say on the matter.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Eirik Mangseth]

Tom Bushell wrote:
> 
> On Wed, 15 Jan 1997 14:13:05 +0100, Jonas Nygren
> <ehsjony@ehs.ericsson.se> wrote:
> 
> >
> >I remember I had a GUI app on my MacPlus where the cycle 'stop testing -
> >fix something small - compile - link - ready to test again' was under 30
> >secs,
> >with a M68000 ~7 MHz!!
> 
> 30 seconds seems like a lifetime after you get used to RAD languages
> like Smalltalk, VB, or Prograph.  Turnaround is instant, and you can
> usually fix the program _while it is running_ - no need to even
> restart.  This allows the programmer to much more easily stay in an
> immersive state of "flow", and probably accounts for a large portion
> of the productivity gains possible with these language/environments.
> 
> As I believe someone else already pointed out, the C++ compiler
> convention of creating an optimized, native code, standalone
> executable file on disk is ass backwards - this should be a batch
> operation that is performed once to create the production version of
> the program.  The rest of the time, it is much more important to allow
> rapid turnaround for modifications, at the expense of execution speed
> if necessary.
> 
> I was impressed by the description of Eiffel's approach to this -
> sounds exactly right to me.

Check out Bertrand Meyer's article regarding the work ISE is doing on
concurrency in Eiffel. It's a gem and Mr. Meyer is just impressive.

(Just hope he signs my copy of the OOSC 2nd ed. book)

> 
> -Tom
> 
> ----------------------------------------------------------
> Tom Bushell           * Custom Software Development
> Telekinetics            * Process Improvement Consulting
> 2653 Highway 202          * Technical Writing
> RR#1, Elmsdale, NS
> B0N 1M0
> (902)632-2772         Email: tbushell@fox.nstn.ns.ca
> ----------------------------------------------------------

Eirik M.

/Eirik Mangseth			United Consultants A/S, Oslo Office, Norway
ema@uc-unitedconsultants.com	"Quality Software Through Quality People"
(TM)
emangset@online.no								/

Re: OO, C++, and something much better!

[Norman H. Cohen]

Don Harrison, referring to the fact that Ada subtype constraints are
checked at run time, wrote:

> ... it shows that Ada is not typesafe.

Wrong.  It shows that Ada is not subtype-safe.  Anyone who expects
otherwise does not understand how the term "subtype" is used in Ada.

Long before Luca Cardelli used the term "subtype" to mean a type bearing
a certain relationship to some other type, Ada used the term to mean a
subset of the values of a given type, consisting of those values of the
type obeying a particular constraint.  In Ada, a subtype is not a kind
of type, and distinctions between subtypes are qualitatively different
from distinctions between types.  It can be determined at compile time
that the value of an expression belongs to a particular type, but it
cannot in general be determined until run time whether the value of an
expression obeys the constraint of a particular subtype.  (Indeed, the
answer may be different for different evaluations of the expression.) 
One cannot, in general, deduce from the fact that A and B belong to a
particular subtype that A+B will as well.

Ada subtypes are specifically meant to express assertions beyond those
implicit in the type of an expression.  These are assertions about
values, assertions that cannot, in general, be checked until those
values are generated.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: What is wrong with OO ?

[Kent Budge, sandia,]

Michael Malak wrote:
...
> The reason C++ is not interpreted is because there don't even exist
> correct C++ _compilers_ that conform to the ANSI Draft Working Paper.
> And the reason for that, of course, is because C++ is a complicated,
> quickly evolving (mutating?) language.
> 
...
But there is at least one C++ interpreter out there -- CenterLine C++.
Of course, it's not fully consistent with the latest ANSI working paper, 
for the reasons you mention.

-- 

-Kent

-------------------------------------------------------------------------------
					   
     _/_/_/  _/    _/  _/          SANDIA NATIONAL LABORATORIES    
_/_/_/    
   _/       _/_/  _/  _/          Department 9231                   
_/_/    
  _/_/_/   _/ _/ _/  _/          Albuquerque, NM 87185-0819    
_/_/_/_/_/_/
       /  _/  _/_/  _/          tel: 505 284 3825              _/  _/_/ 
_/
_/_/_/   _/    _/  _/_/_/_/    fax: 505 844 0918              _/  _/_/ 
_/
                                                                _/_/_/ 
  Computational Physics Research             
 and Development Department               Kent G. Budge -
kgbudge@sandia.gov
-------------------------------------------------------------------------------

(usual disclaimer)
Return address hacked to foil junk mail; edit before replying.

Re: OO, C++, and something much better!

[Keith Thompson]

In <32DCFB78.605A@lmtas.lmco.com> Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:
[...]
> However, via access values, an unchecked conversion could still be used
> without creating a copy, so the comment is still valid: using address
> specs to create an overlay should not be significantly less/more safe
> than unchecked_conversion, at least not for the reason originally
> given...

Personally, I'd still be more comfortable using Unchecked_Conversion
rather than overlays.  Part of this is a remnant of Ada-83-think; Ada
83 specifically stated that overlays are erroneous.  Also, it's not
necessarily guaranteed that updating one of the overlaid objects will
update the other; one of the objects may be cached in a register when
the other is updated.

I believe that applying pragma Volatile to one or both objects will
solve this problem (though there may still be some problems I'm missing).

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: OO, C++, and something much better!

[Patrick Doyle]

In article <E3z0zy.9qL@syd.csa.com.au>,
Don Harrison <donh@syd.csa.com.au> wrote:
>
>The following is a valid Ada83 program (and presumably valid Ada95):
>
>procedure Test_Type_Hole is
>  subtype Sub_Integer is Integer range 1 .. 10;
>  I: Integer;
>  S: Sub_Integer;
>
>  procedure Use_Subtype (S: Sub_Integer) is
>  begin
>    null;
>  end;
>
>begin
>  I := 1000;
>  Use_Subtype (I);       -- System Invalid call - raises 
>                         -- Constraint_Error at runtime.
>end Test_Type_Hole;
>
>So, contrary to your claim, Ada *does* permit a form of broken polymorphism.

  To me, this seems more of a broken assertion than broken polymorphism.

  (However, I've never use Ada in my life... :-)

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: What is wrong with OO ?

[Robert C. Martin]

In article <E448IK.4qI@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
Doyle) wrote:

>   I was not aware that private virtual functions existed.  Can a descendant
> class override this function even though it does not have access to it?
> 

Yes.  Visibility is not the same as accessibility.  You can override anything
that is visible, even if it is unaccessable.

If a class D overrides a private function F of its base B, the functions of 
D still cannot access B::f, but they *can* access D::f.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Ell]

Kent Budge ("kgbudge,"@,sandia,.gov) wrote:
: Michael Malak wrote:
: ...
: > The reason C++ is not interpreted is because there don't even exist
: > correct C++ _compilers_ that conform to the ANSI Draft Working Paper.
: > And the reason for that, of course, is because C++ is a complicated,
: > quickly evolving (mutating?) language.
 
: ...
: But there is at least one C++ interpreter out there -- CenterLine C++.
: Of course, it's not fully consistent with the latest ANSI working paper, 
: for the reasons you mention.

To me the reason no tools "conform" to the ANSI Working Paper is not
primarily because C++ is complicated, but because the "working paper" has
been quickly evolving.

Elliott

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "lgmayka" == Lawrence G Mayka <lgmayka@sprynet.com> writes:

lgmayka> bs@research.att.com (Valerie Torres) wrote:

bs> In the area of exceptions, C++ may have added something important:
bs> C++ exceptions can be of arbitrary type and inheritance is taken
bs> into account when catching an exception. This provides important
bs> possibilities for grouping exceptions that I don't know precedence
bs> for (though the need for grouping has been known for decades).

lgmayka> The use of inheritance in defining and handling conditions
lgmayka> dates at least back to Symbolics' New Error System, circa 1984,
lgmayka> which was the forerunner of the Pittman Condition System, circa
lgmayka> 1985.  The latter quickly found its way into the other
lgmayka> commercial Common Lisp implementations and was incorporated
lgmayka> into ANSI Common Lisp.

Unfortunately exceptions-as-object is a bad idea, and claiming priority
for bad ideas is hardly a sport worth engaging into. :-)

Re: What is wrong with OO ?

[Matthew Heaney]

In article <E424x4.5A3@research.att.com>, bs@research.att.com (Bjarne
Stroustrup) wrote:


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

Perhaps it has already been stated elsewhere in this thread, but in Ada,
access objects are by default initialized to null.  An attempt to
dereference a null access value raises Constraint_Error.

I see C++, Ada, and Eiffel being on a scale of safety with respect to
pointers (and other things, too).

Eiffel takes the attitude that pointers are unsafe (they can be), so
removes them from the language.  This is the approach taken by Java, too.

C++ is pragmatic, and given its C and systems-programming roots, has
pointers, and you can basically do anything you want.  In fact, a pointers
are often used to do a typeless kind of programming; this is the norm, for
example, in making UNIX system calls.  But there is little safety in that
approach, and your example proves the point that perhaps some built-in
support for pointer-safe programming is called for.

Ada is in the middle: it's pragmatic *and* safe.  You are free to use
pointers, but pointer type "casting" is not allowed.  Pointers to
statically declared objects are safe too, because you are only allowed to
point to an object that has a longer life than you.  "Reference" variables
are made safe by parameterizing the object with a reference to a
longer-lived object.

Of course, if you really do want to leave the type system in Ada, you can
do so by explicitly marking the conversion or dereference as "unchecked." 
So you can have your cake and eat it too.

I have said it before: I like Eiffel, and don't disagree with its
philosophy, but I think there's room for pragmatism.  I think Bjarne would
agree that it's important to give programmers all the tools they need to do
their job, and that includes pointers.  Ada's philosophy is give them
pointers, but make pointer manipulation safe.

If you are frustrated by repairing code that is broken because of
non-initialized pointers, then perhaps you should give Ada a try. 
Programming is a lot more productive then debugging, and a lot less
frustrating.

-matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Exceptions as objects (was Re: What is wrong with OO ?)

[Patrick Doyle]

In article <yf3sp3y9ur6.fsf@sabi.demon.co.uk>,
Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:
>
>Unfortunately exceptions-as-object is a bad idea, and claiming priority
>for bad ideas is hardly a sport worth engaging into. :-)

  Could you elaborate on why that is a bad idea?

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: What is wrong with OO ?

[Jay Martin]

bs@research.att.com (Bjarne Stroustrup) writes:


>dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> > Bjarne, in the middle of a very nice extended discussion of C++, says
> > 
> > "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."
> > 
> > Hmmm! I don't think I buy that. People will learn what is at hand pretty
> > much regardless of whether something is easy to learn and use.
> > ...
> > Going back to the main subject, which is the allegation that popularity
> > indicates ease of learning and use,

>I don't think I claimed that, and I don't think that I have to. C++ use grew
>very nicely for years without hype. I base my statement on years of looking
>at C++ use, teching, and learning - many of those years were before anyone
>was given time off from their day job to learn C++.

>I think that if C++ was as hard to understand and use as some people claim,
>it would have failed to become popular in the first place and would have
>vanished under the continuous barrage of fair and unfair criticism - despite
>its (eventual) popularity.

I find this incredibly naive.  C++ is popular because it is perceived
as "C version 2" or "C 8X-9X".  You pretty much automatically get
usage by a large number of C programmers.  That it came from Bell Labs
pretty much guaranteed its success over Objective C which came from
some pint size "is it out of business yet" company.  Since C
programmers are notorously ignorant of computer language design, the
audience is not too discerning.  Suppose instead that you had chosen
to do an almost identical language except with a clean well designed
syntax that was not syntactically upward compatible from C.  I believe
this "alternate reality C++" would have failed miserably.  I thought
it was brilliant the way you appealed to the anti-SE neanderthal
dark-side of C programmers with the "No nanny-ism, any safety checks
would be "dangerous" and demeaning".  You see there is a huge segment
of programmers who love the arcane, the complex and the hard to
understand.  This is because they are smart and they know that hard to
learn tools that require alot of special expertise will give them a
competive advantage in the programming marketplace because it limits
the number of programmers that can do the work thus guaranting high
salaries and job security!  Thus "high learning curve" tools leads to
daydreams of speeding down the freeway in your high powered BMW
convertable with an adoring and beautiful big titted blond bimbo at
your side.

Is their any wonder why the software field is not "rational"?

Still I find C++ a remarkable job given that you had to stay upward
compatible (syntax/sematically and philosophy-wise) with a turd.

> >  I think the point is that such
> > popularity indicates accesibility more than anything else. By accessibility
> > I mean that something is available, viewed as hot, and can be learned well
> > enough to do *something*. Consider the situation today, students want to
> > learn Java, not C++, they see C++ as yesterday's language, and Java as
> > the language of tomorrow. Just from the incredible rate at which Java books
> > are cascading into bookstores, I have to guess that the rate of learning of
> > Java far exceeds the rate of learning of C++. But I would NOT conclude from
> > this that Java is easier to learn or use than C++. Maybe it is, but you
> > cannot conclude anything just from popularity.

>It is amazing what hype and serious marketing dollars can do, but what
>little objective data I can lay my hands on indicates that C++ use is
>still increasing very nicely. However, I have my doubts whether all of
>those books will actually help the Java community. 

This field is driven by marketing and rational behavior is at a
minimum.  Sometimes I wish a rational force like some academic
scholars would actually study the field in an objective fashion.
Alas, CS Academia is total failure (I will restrain myself from the
usual explicative strewn rant).  Anyway, any argument based
on the rationality of field "like it must be good because people
use it" is nonsense.  There are just too many non-SE factors
in these decisions.
  

I think though Java may turn out to be a better software engineering
language than C++ and Ada95 as it contains two extra design
philosophies which I deem necessary for good language design:

                                 C++      Ada95     Java
1. Simplicity                    No        No        Yes
2. Programmers are morons.       No        Yes       Yes


> > Ada folks have never played the game of claiming popularity as an indicator
> > of any kind of quality, because they have not been able to. I realize that
> > C++ is in a position to make such claims, but I recommend against it, because
> > I think you will find that your arguments will backfire as Java becomes
> > the next hot language, at least for a while :-)

>Thanks for the advice. The furthest I go is to claim that unless C++
>had at least some of the virtues I claim for it, it would have died during
>the early years where there were essentially no C++ marketing and alternatives
>languages with marketing dollars behind them existed.

>Naturally, even that is invariably mistaken for the disreputable "5 million
>morons cannot be wrong" argument :-(

Of course programmers are morons, just look at them!

Jay

Re: What is wrong with OO ?

[Richard A. O'Keefe]

bs@research.att.com (Bjarne Stroustrup) writes:
>I think that if C++ was as hard to understand and use as some people claim,
>it would have failed to become popular in the first place and would have
>vanished under the continuous barrage of fair and unfair criticism - despite
>its (eventual) popularity.

Speaking as someone who bought the first C++ book to come out,
the C++ that became popular in the first place
is not the C++ that people discuss now.
To start with, it didn't have multiple inheritance, templates,
exceptions, or RTTI.

It follows that claims about the difficulty of understanding
about C++ *AS IT IS NOW* cannot fairly be founded on its
acceptance *AT FIRST*, just as arguments about the difficulty
or otherwise of learning or teaching Ada 95 cannot be directly
founded on the acceptance or otherwise of Ada 83 (ditto with
Fortran 90 and Fortran 66).

>I have often found myself wondering if the C++ wouldn't have been much better
>for all concered had there (just) been two dozen good C++ books instead of
>the 400+ books that mostly fail to teach the basic principles and mostly
>lead students and programmers astray.

Here of course it is very important to separate out the books from the
language.  The marked prevalance of trash books about C++ says nothing
about C++ except that it is popular.

>Thanks for the advice. The furthest I go is to claim that unless C++
>had at least some of the virtues I claim for it, it would have died during
>the early years where there were essentially no C++ marketing and alternatives
>languages with marketing dollars behind them existed.

Hmm.  When I learned about C++ in the mid-80s, the only available
alternatives _that I was aware of_ were some sort of Lisp (Common
Lisp not then being available) with some sort of home brew Flavors
lookalike (CLOS not then being available) or Smalltalk.  Simula 67
_may_ have been available for VAX & Sun but if there were marketing
dollars behind it they never managed to put a mention of it where I
could see it.  What _were_ the VAX, Sun, Apollo alternatives to C++
a decade ago?

-- 
My tertiary education cost a quarter of a million in lost income
(assuming close-to-minimum wage); why make students pay even more?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <E47rDG.AC8@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> In article <E3z0zy.9qL@syd.csa.com.au>,
> Don Harrison <donh@syd.csa.com.au> wrote:
> >
> >The following is a valid Ada83 program (and presumably valid Ada95):
> >
> >procedure Test_Type_Hole is
> >  subtype Sub_Integer is Integer range 1 .. 10;
> >  I: Integer;
> >  S: Sub_Integer;
> >
> >  procedure Use_Subtype (S: Sub_Integer) is
> >  begin
> >    null;
> >  end;
> >
> >begin
> >  I := 1000;
> >  Use_Subtype (I);       -- System Invalid call - raises 
> >                         -- Constraint_Error at runtime.
> >end Test_Type_Hole;
> >
> >So, contrary to your claim, Ada *does* permit a form of broken polymorphism.
> 
>   To me, this seems more of a broken assertion than broken polymorphism.
> 
>   (However, I've never use Ada in my life... :-)

Well, now this is amusing.  Patrick here states he's never used Ada
in his life, but he gets it _right_!  Nice little piece of anecdotal
evidence for the readability of Ada... :-)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[David Emery]

With many OO languages, including C++ and SmallTalk, I've observed that
it seems to be easy to get familiar with the language, but it's much 
harder to become fluent/expert in it.  I suspect we'll see a similar
pattern with Java.  This is certainly my personal experience learning
Java.  

Thus I'd suspect that the initial popularity of C++ was due to the 
following: (no ranking)

	*  popularity of C
	*  price
	*  ease/intuition for the basic OO concepts.  

So, once Joe/Jane Programmer has reached the "familiarity" stage, the
real issue is the amount of time it takes to get to the "fluent"
stage.  

Thus I think that a more appropriate way at looking at this is not
popularity or familiarity, but rather time to reach expertise.  I'll
leave it to others to define "expertise" for a given language.  At the
minimum, I'd expect "expertise" to include the ability to avoid common
syntax/semantic mistakes, the ability to read/reason about and
maintain code written by others, and at least passing familiarity with
the distinction between "the language specifies..." and "this
implementation does...".

If you are going to be a practicing/professional programmer, producing
real code, "familiarity" is not good enough.  Expertise is required. 

				dave
-- 
<.sig is away on vacation>

Re: OO, C++, and something much better!

[Andrew Koenig]

In article <5bie2d$eat$1@news.nyu.edu> kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

> In article <dewar.852928982@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> >equally if you do something like

> >   (x = p; x < &p[10]; p += 3)

> >you can find you have an infinite loop, all quite in accordance with the
> >C semantics, although somewhat surprising.

> This case must work.  Such a reference to the end of an object is required
> to be treated like a reference within the object.

I haven't seen the original of this, but the fragment above appears
to contain at least three mistakes (not counting the missing `for'
as a mistake):

	1. It probably should have said `x += 3' instead of `p += 3';
	   as it is, the loop will just keep incrementing p until something
	   dire happens.

	2. If we change `x += 3' to `p += 3,' it still won't work,
	   because p will take on the value of &x[9], and then
	   &x[12], which is undefined, assuming that p has 10 elements.

	3. If p is indeed the name of a 10-element array, then
	   &p[10] is undefined in C.  Really!  The reason is that
	   it is defined as equivalent to *(p+10), and, although it
	   is legal to create p+10, the effect of dereferencing it
	   is undefined.  So, formally speaking, &p[10] is supposed
	   to be written as p+10.

I hope I haven't derailed the discussion too much.
-- 
				--Andrew Koenig
				  ark@research.att.com
				  http://www.research.att.com/info/ark

Re: What is wrong with OO ?

[rharlos*cybercomm.net]

bs@research.att.com (Bjarne Stroustrup) wrote:

   << snipped the debate parts >>

| Why is any of this relevant now? Why do I bother with this debate on
| "innovation?" Because some of what is said related directly to what C++
| is and should be, and that again affects where it is reasonable to use
| it and how it is best used. If you misunderstand some of the fundamentals
| of a language, the code you write in it is going to be suboptimal in several
| ways.

PMFJI.  If there is a gem to be gleaned from this debate, it is in the above
paragraph.

Every development environment (DE) has strengths and weaknesses.  These are the
"fundamentals" of the DE.  As developers, we have a responsibility to understand
both the needs of the situation to be "solved" and the fundamentals of the
various tools which may be used to create a solution to the situation at hand.

Our ability to select the right tool for the job can make the solution several
times easier to implement, maintain and enhance than if we had selected a less
optimal DE.  Its a message that, in my experience, can never be overemphasized!

Thanks for this little gem -- it's a keeper!

  O-------------------------0   0----------------------------------0
  |  Richard C Harlos II     \ /       Software Analyst/Developer  |
  |  aka:   .:.Richard.:.     X    Logical Design Solutions, Inc.  |
  |  rharlos@cybercomm.net   / \               http://www.lds.com  |
  0-------------------------0   0----------------------------------0

  ** opinions expressed are mine, not necessarily those of LDS, Inc.

  Anit-Spam Tactic:  replace the '*' with '@' when replying to
            me via e-mail as I've been inundated with spam !!!

Re: What is wrong with OO ?

[John W. Sarkela]

Richard A. O'Keefe wrote:
> 
... text ommitted ...
> Hmm.  When I learned about C++ in the mid-80s, the only available
> alternatives _that I was aware of_ were some sort of Lisp (Common
> Lisp not then being available) with some sort of home brew Flavors
> lookalike (CLOS not then being available) or Smalltalk.  Simula 67
> _may_ have been available for VAX & Sun but if there were marketing
> dollars behind it they never managed to put a mention of it where I
> could see it.  What _were_ the VAX, Sun, Apollo alternatives to C++
> a decade ago?
> 
There were some very sound alternatives. In the days when C++ was
still in the 1.x range (ie pre multiple inheritance, pre templates,
pre exceptions, etc) the languages Trellis/OWL, Eiffel and Modula-3
were around. 

In fact, there was a protracted thread in the comp.lang.eiffel and
comp.lang.c++ groups about Eiffel v. C++. Most of the content 
revolving upon the need for multiple inheritance and genericity
(templates) in a statically typed OOP language and the need for 
exceptions for robustness. All three languages paid great homage
to the needs of software engineering. All three are worth reading
about, if only for historical perspective.

John Sarkela
jsarkela@enfish.com
-- Standard disclaimers apply.

Re: What is wrong with OO ?

[Ulrich Windl]

I guess it's just a matter of fact that short routines are most
oftenly called (If you don't manipulate your instance variables
directly).

Ulrich Windl

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "ok" == Richard A O'Keefe <ok@goanna.cs.rmit.EDU.AU> writes:

[ ... on ease of learning ``C++'' and its popularity ... ]

ok> Speaking as someone who bought the first C++ book to come out, the
ok> C++ that became popular in the first place is not the C++ that
ok> people discuss now.  To start with, it didn't have multiple
ok> inheritance, templates, exceptions, or RTTI.

Very good point! Which adds to the motivation for my oft repeated stance
that ``C++'' is a brand name, and can in effect mean any of a few quite
different (even if related by very good backwards compatibility) languages.

ok> Hmm.  When I learned about C++ in the mid-80s, the only available
ok> alternatives _that I was aware of_ were some sort of Lisp (Common
ok> Lisp not then being available) with some sort of home brew Flavors
ok> lookalike (CLOS not then being available) or Smalltalk.  Simula 67
ok> _may_ have been available for VAX & Sun but if there were marketing
ok> dollars behind it they never managed to put a mention of it where I
ok> could see it.  What _were_ the VAX, Sun, Apollo alternatives to C++
ok> a decade ago?

This is an excellent point, but one that has some (partial) answers.

Most importantly there was ``Objective-C'' which was implemented rather
portably by generating ``C'', like 'cfront' was doing for ``C++''; I
have my early copy of Brad Cox's "OOP: and evolutionary approach"
describing it dated 1986, and indeed I bout it over ten years ago.  It
was used to develop RMG, an impressive ``Smalltalk''-like graphical
environment, which would still be impressive today, never mind 10 years
ago, which was being distributed, in very good shape as well, to
universities and research institutes in 1987. It is easy to argue that
Objective-C never achieved lasting fame for a number of unfortunate
reasons; among them that Brad Cox ``cleverly'' kept its compiler
proprietary instead of more or less givin it away ("cfront" was licensed
fairly cheaply, so that even a one man company like Comeau could port it
and sell it on a variety of platforms).

But there were other alternatives, which however have remained
resolutely locked up in the research world (and some like ``Smalltalk''
have only escaped it as their sell-by-date has already expired).

Some of them originated from BTL themselves; there was a number of C
derived languages being developed at BTL concurrently with ``C++'', some
of them being good contestants. But it was ``C++'', for various not
necessarily technical reasons, that became popular within AT&T and the
world (again, easy compiler licensing was IMNHO crucial: a bit like the
sudden popularity of Pascal in Universities was due to the easy
availability of the bytecode compiler, and of the CDC sample
implementation).

Now, I personally like ``C++'' (up until 2.x, that is, more recent
features I like less), for I am a language lawyer and a system
implementor with it; but I find it abhorrent that it has become popular
as the application development language of choice by anybody, as it is
simply too sophisticated and low-level (just like C itself). If only had
Objective-C become the application development language of choice! If
only more people had seen RMG! and so on.

Re: What is wrong with OO ?

[Bertrand Meyer]

Chris Bitmead wrote:
 
[Quoting me, quotation abridged:]

> >ISE Eiffel does give the user a degree of parameterization:
> >a compilation option specifies the size threshold beyond which
> >a routine will not be inlined. 

[...]

> >Most users are happy with the
> >default, which inlines small, frequently called routines.

[Chris Bitmead:]

> How on earth does the compiler know if a routine is "frequently
> called"?

Sorry, sloppy wording on my part. I meant "called from many different
places in the code", which  does tend to correlate with the numbers of
times the routine will be called, although of course this is not always
true (as with a routine that is called from just one place, but that
place is in a loop). Just one criterion among others. Thanks for noting
the incongruity in my original message. 

-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: What is wrong with OO ?

[Bertrand Meyer]

Bjarne Stroustrup wrote:

> C++ use grew
> very nicely for years without hype. I base my statement on years of looking
> at C++ use, teching, and learning - many of those years were before anyone
> was given time off from their day job to learn C++.

[...]

> [C++] would have died during
> the early years where there were essentially no C++ marketing and alternatives
> languages with marketing dollars behind them existed.

This is really too far off the reality to let pass. Not that I think
Bjarne Stroustrup is less than forthcoming; he is undoubtedly sincere in
believing that he was a researcher led by purely intellectual motives
competing against crass commercialists. From within Bell Labs he may
have had that impression. But anyone seeing the real situation in the
software world at large could not fail to notice the gigantic amount of
both "hype" (his term in the first paragraph) and "marketing" (his term
in the second) behind C++. The mere fact that it came from AT&T and was
from the start endorsed by other billion-dollar companies was what got
the industry to listen. It does not mean that the language was bad (and
neither does it mean the reverse) - simply that the quality of the
language was, if not completely irrelevant, far secondary to the
marketing push.

In the field of advanced technology, furthermore, marketing is not just
expensive ads in magazines. It is also access of various approaches to
scientific conferences and publications. The record of OOPSLA in this
respect has been (and continues to be) less than pristine. To put it
politely, it has always been made very clear that some approaches were
more equal than others.

This has had a rather vicious consequence: that people promoting
less-hyped and less-politically-correct approaches, coming in many cases
from private industry (often precisely because they were more innovative
and could not find a hospitable environment in academia or even large
corporate research labs) had to resort to the normal, commercial forms
of "marketing", thus allowing their better endowed competitors to drape
themselves in the mantle of Pure Science and accuse the former of crass
commercialism. This is a very effective tactic, and worked quite well in
the history of O-O: keeping innovators  away from the Establishment,
forcing them to go to the commercial sector, and then frowning on them
on the grounds of academic impurity. Quite smart.

All this being said, I must add that while I am not a great fan of C++ I
agree with Bjarne Stroustrup that marketing and hype alone, on any
scale, would not by themselves have been able to bring C++ to the level
of success that it reached. Clearly, it filled for many people a
pressing need at the right time. Although Dr. Stroustrup's second
paragraph as quoted above (the point about there being no marketing for
C++) does not hold water, the first part (omitted above):

	[U]nless C++ had at least some of the virtues I claim for it,
	it would have died during the early years

is absolutely correct. To take  the first analogy that comes to mind,
the Apple Newton is yet one more example that no company, however big,
can force on the public a technology that the public does not want.


-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: What is wrong with OO ?

[Chris Bitmead]

In article <32D53473.4DAA423A@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

>ISE Eiffel does give the user a degree of parameterization:
>a compilation option specifies the size threshold beyond which
>a routine will not be inlined. This is measured in internal units
>(number of bytecode words), but easy to relate to number of
>instructions. This option provides a way to control space-time
>tradeoffs. In practice, however, most users are happy with the
>default, which inlines small, frequently called routines.

How on earth does the compiler know if a routine is "frequently
called"?

language marketing question, was Re: What is wrong with OO ?

[Tom Moran]

> But anyone seeing the real situation in the
> software world at large could not fail to notice the gigantic amount of
> both "hype" (his term in the first paragraph) and "marketing" (his term
> in the second) behind C++. 
  Does anyone know of a marketing case study of the initial growth of C
and Unix?  Both the words and the money behind them?

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "doylep" == Patrick Doyle <doylep@ecf.toronto.edu> writes:

doylep> In article <yf3sp3y9ur6.fsf@sabi.demon.co.uk>,
doylep> Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:

piercarl> Unfortunately exceptions-as-object is a bad idea, and claiming
piercarl> priority for bad ideas is hardly a sport worth engaging
piercarl> into. :-)

doylep>   Could you elaborate on why that is a bad idea?

Of course, and easily; somebody asked me the same idea by private
e-mail, so I can just paste in the reply(s) and do a little bit of
editing. It's also one of my pet peeves... And it is astonishing that
what I am going to say, that has been part of the state of the art for
some dozen years, is not yet apparently widely known.

Let's start with the nature of exceptions. The first point is that if a
procedure implements a total function then it will never have an
exception.

Therefore exceptions arise only and only if a procedure implements a
partial function, and arise only and only when the inputs to a procedure
are outside its domain.

This means that an exception can only arise when at some point in a
procedure where there is a 'if' (or similar) statement whose
precondition is stronger than the postcondition of the statement that
precedes it. For example:

  float sqrt(float f) { if (f >= 0) return exp(0.5*ln(f)); }

Here the precondition of the 'if' is $f >= 0$, but the postcondition
preceding it is (more or less) $true$.

Now exception handling means extending the precondition of a procedure,
up to making it become a total function. This means simply weakening the
precondition of 'if's by adding 'else'/'elif' clauses.

Consider:

  extern float sqrt_neg_arg(float);

  float sqrt(float f)
    { return (f >= 0) ? exp(0.5*ln(f)) : sqrt_neg_arg(f); }

Now 'sqrt' is a total function. This is the general way of``defining''
and ``raising'' exceptions: provide an 'else' that invokes a procedure;
the name of the procedure is the name of the ``exception''.

Unfortunately in the general case this simply cannot be done as written,
because the author of a piece of software may not be in a position to
know what to code in those 'else's, for the more appropriate action may
depend on the runtime context. It is thus inappropriate to assign a
statically defined association between a name like "sqrt_neg_arg"
and a procedure implementation.

The obvious and correct solution is to make the name of the procedure
dynamically scoped; then it can be redefined whenever this is needed.

Thus:

* an exception is a fact, not an object;

* the fact is the absence of a suitable 'else' somewhere when it should
  be there;

* defining and raising an exception means simply adding an 'else' and a
  call to a dynamically bound procedure;

* handling an exception means simply resolving the dyanmically scoped
  name to a procedure body and executing it.

Finally, recovery from an exception may involve non local control
transfers out of the procedure that handles the exception; but this is
an entirely separate issue. It need not be the case.

So, basically *everything* is wrong (and clumsily so) with the ``C++''
exception-as-object system:

* the name of the exception class should be that of a dynamically scoped
  procedure.

* an exception object is really just a clumsy and silly way of
  specifying an argument list to that dynamically scoped procedure.

* non local control transfers are then mandatory.

Consider the stark contrast between (in some language reminiscent of
``C++''):

  fluid float sqrt_neg_arg(float);

  float sqrt(float f)
    { return (f >= 0) ? exp(0.5*ln(f)) : sqrt_neg_arg(f); }

  main()
  {
    {
      fluid float sqrt_neg_arg(float f) { return 0.0; }

      printf("%f\n",sqrt(-2.0));
    }

    {
      fluid float sqrt_neg_arg(float f)
      {
	fprintf(stderr,"panic: negative arg to 'sqrt': %f\n",f);
	abort();
      );
      
      printf("%f\n",sqrt(-2.0));
    }
  }

and

  class sqrt_neg_arg {
  public: float n;
    sqrt_neg_arg(float f) : n(f) {}
  };

  float sqrt(float f)
  {
    if (f >= 0)
	  return exp(0.5*ln(f));
    else  throw sqrt_neg_arg(f);
  }

  main()
  {
    try { printf("%f\n",sqrt(-2.0)); }
    catch(sqrt_neg_arg &sna)
    {
      // cannot just return 0.0 -- too bad.
      puts("0.0"); // not really what we wanted
    }

    try { printf("%f\n",sqrt(-2.0)); }
    catch(sqrt_neg_arg &sna)
    {
      fprintf(stderr,"panic: negative arg to 'sqrt': %f\n",sna.f);
      abort();
    }

  }

As you can see the second solution is really just a clumsy, misleading,
limited version of the first. Exceptions are not objects; and exception
objects are just stupid ways of passing a parameter list to a
dynamically scoped procedure name, which is confused with a class.

However, in most cases even for exception handling one does not really
need dynamically scoped function names; dynamically scoped function
pointer variables are about as good, as in (rewriting my example):

  float sqrt_neg_arg_default(float f)
    { fprintf(stderr,"sqrt neg arg: %f\n",f); abort(); }

  fluid float (*sqrt_neg_arg)(float) = sqrt_neg_arg_default;

  float sqrt(float f)
    { return (f >= 0) ? exp(0.5*ln(f)) : (*sqrt_neg_arg)(f); }

  float sqrt_neg_arg_zero(float f)	{ return 0; }
  float sqrt_neg_arg_abs(float f)	{ return sqrt(-f); }

  main()
  {
    {
      fluid float (*sqrt_neg_arg)(float) = sqrt_neg_arg_abs;
      printf("%f\n",sqrt(-4.0));  // prints 2.0
    }

    {
      fluid float (*sqrt_neg_arg)(float) = sqrt_neg_arg_zero;
      printf("%f\n",sqrt(-42.0)); // prints 0.0
    }

    printf("%f\n",sqrt(-33.0)); // default, aborts
  }

Dynamically scoped function pointers have the advantage that they don't
require introducing into the language nested functions, and allow one
more easily to separate ``exception handler'' interface and
implementation.

Note that in effect in ``C++'' the 'fluid' storage class that turns a
variable into a dynamically scoped one is pretty easy to simulate (in
the shallow binding way) using constructors/destructors:

------------------------------------------------------------------------
typedef void		*Fluid;

class FluidFrame
{
private:
  Fluid		   	  saved;
  Fluid			  *variable;
public:
  construct		  FluidFrame(Fluid *);
  destruct		  ~FluidFrame();
};

static inline		FluidFrame::FluidFrame
( register Fluid	  *const avariable)
{
  this->saved	  = *avariable;	/* Save old value	    */
  this->variable  = avariable;	/* Note where to restore it */
}

static inline		FluidFrame::~FluidFrame()
{ *this->variable = saved; }

#define fluid(NAME)							\
  FluidFrame Fluid_##NAME(& (Fluid) (NAME)); NAME

#define fluidfor(CLASS,MEMBER,NAME)					\
  FluidFrame Fluid_##CLASS##_##NAME					\
    (& (Fluid) (CLASS MEMBER NAME));					\
  CLASS MEMBER NAME
------------------------------------------------------------------------

The the example above becomes:

  float sqrt_neg_arg_default(float f)
    { fprintf(stderr,"sqrt neg arg: %f\n",f); abort(); }

  float (*sqrt_neg_arg)(float) = sqrt_neg_arg_default;

  float sqrt(float f) // implements a total function
    { return (f >= 0) ? exp(0.5*ln(f)) : (*sqrt_neg_arg)(f); }

  float sqrt_neg_arg_zero(float f)	{ return 0; }
  float sqrt_neg_arg_abs(float f)	{ return sqrt(-f); }

  #include <Fluid.H>

  main()
  {
    {
      fluid (sqrt_neg_arg) = sqrt_neg_arg_abs;
      printf("%f\n",sqrt(-4.0));  // prints 2.0
    }

    {
      fluid (sqrt_neg_arg) = sqrt_neg_arg_zero;
      printf("%f\n",sqrt(-42.0)); // prints 0.0
    }

    printf("%f\n",sqrt(-33.0)); // default, aborts
  }

which seems rather legible, vastly more flexible/reasonable than the
convoluted and limiting current ``C++'' syntax.

Now there is completely orthogonal problem of non local control
transfers, which might well be useful in a procedure implementation that
``handles'' an exception. In the above code snippets an example of the
use of non local control transfers is the call to 'abort()', which exits
the current process and transfers control back to the invoking process;
one could use 'setjmp()' or 'longjmp()', or something better, for finer
grained control transfers.

It is a pity that the ``C++'' exception handling features tie so
intimately together the distinct concepts of dynamically scoped
identifiers (and then they are provided in a rather clumsy form) and of
non local control transfers (and then they are also provided in a rather
clumsy form).

The issue of non local control transfers, even if only the form of
upward funargs, and scope entry/exit triggers, is interesting and
``C++'' provides only ad hoc and limited machinery to deal with it.

  As to this, I rememjber reading someone stating that as far as he knew
  only TECO (yes, TECO!) of most languages around provides general clean
  entry/exit scope functions/triggers. Ah well.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Paul Kyzivat]

piercarl@sabi.demon.co.uk (Piercarlo Grandi) wrote:

[snip a long and interesting explanation of exception handling]

I found the discussion very interesting. In a theoretical way I agree
with you. However I think in a practical sense it misses the point to
an extent:

For code to be readable, it is useful to have the exception handling
easily and clearly lexically scoped with the code that it applies to.
What you suggest is really very little different than what existed in
various libraries prior to the introduction of compiler supported
exception handling. I remember it in Fortran - it did a nice job of
adding to the confusion of all those gotos.

You are right that this really has more to do with how to suport a new
form of non-local control transfer than it does exceptions. But
usually non-local control transfer is required for exception handling
because the function otherwise has no return arguments that can be
used to express what happened. And, while TRY is ugly and clumsy in
some cases, it does allow the normal flow of control to be segregated
from the abnormal flow of control while still making it clear how they
are related.

I agree with you that classes as exceptions is in a way a kludge. But
they do more than pass arguments to a handler. They also server as a
hierarchical classification system for exceptions. Using classes for
this is a matter of economy of language concepts. (Perhaps we can call
it reuse of a language concept.)

	Paul Kyzivat

Re: What is wrong with OO ?

[Damon Feldman]

 Bertrand Meyer <bertrand@eiffel.com> wrote:
>Bjarne Stroustrup wrote:

>> C++ use grew
>> very nicely for years without hype. I base my statement on years of looking
>> at C++ use, teching, and learning - many of those years were before anyone
>> was given time off from their day job to learn C++.

>This is really too far off the reality to let pass

>people promoting
>less-hyped and less-politically-correct approaches, coming in many cases
>from private industry (often precisely because they were more innovative
>and could not find a hospitable environment in academia or even large
>corporate research labs) had to resort to the normal, commercial forms
>of "marketing", thus allowing their better endowed competitors to drape
>themselves in the mantle of Pure Science and accuse the former of crass
>commercialism. This is a very effective tactic, and worked quite well in
>the history of O-O: keeping innovators  away from the Establishment

Come come.  Private industry is more innovative than academia "or even large 
corporate" labs?  "This is an effective tactic [for] keeping innovators away 
from the Establisment?"  If the innovators did get close to the establishment, 
might they have discovered who really assasinated Kennedy :-).

Just kidding, of course.

But I think that the academic success of C++ was based on acceptance by 
tenured faculty who were not payed off or otherwise influenced by big business 
or in a conspiracy to foist C++ on the programming community.

C++ was object oriented, and it was downward compatible (almost) with C, which 
was and is in wide use.

Damon

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Ronald E Jeffries]

On 25 Jan 1997 02:07:04 +0000, piercarl@sabi.demon.co.uk (Piercarlo
Grandi) wrote:

>Let's start with the nature of exceptions. The first point is that if a
>procedure implements a total function then it will never have an
>exception.
>
>Therefore exceptions arise only and only if a procedure implements a
>partial function, and arise only and only when the inputs to a procedure
>are outside its domain.

Yes ... and then you go on to make the function more robust, which
would be a good thing when it's practical.  But as you point out, the
exceptions arise when the inputs are out of the range contemplated by
the function as written.  

Exceptions, however, whether represented as objects or long jumps, are
about handling the unexpected.

My application system must keep on going, whether or not the input
routines are prepared to deal with B's in the middle of the numbers,
and dates like 2/31/1997.  Complexity, lack of access to the code,
limited resources mean that the input routines won't ever be made
complete.  And they can't know what their users want done with those
B's and weird dates anyway.

At the same time, when using the input routines, it is impractical
(costly and error-prone) to have every call to the routines check for
errors.  It is much more practical and convenient to choose a standard
place where, if an input error occurs, a default action can be taken.

In a project I'm presently working on, the input routines try to
handle all the errors.  Then when the application definers decided
what kind of notifications they wanted on input errors, we had to go
in and edit the input routines and change them all around to get the
job done.  Had they just thrown an exception, we could have fielded
the exception where we wanted to, and filed our notifications and gone
on.

While complete program correctness is an interesting science, it is
not something that we often attain in practice.  Exceptions are a
simple and practical way to deal with the faults we humans often leave
in our programs and our data.

Regards,

Ron Jeffries
Smalltalker
How do I know what I think until I see what I type?

Re: OO, C++, and something much better!

[Robert Dewar]

Richard said, replying to me

>>equally if you do something like
>>
>>   (x = p; x < &p[10]; p += 3)
>>
>>you can find you have an infinite loop, all quite in accordance with the
>>C semantics, although somewhat surprising.
>
>This case must work.  Such a reference to the end of an object is required
>to be treated like a reference within the object.

(note, the p += 3 should of course be x += 3, as I noted in a followup
 post, but I assume Richard understands this typo)

Chuckle, chuckle, it is nice to be able to catch Richard out like this :-)

Richard, you did not look at the example carefully enough. The fact that
you think it works even after I warned that it does not is a perfect
example of how serious this pitfall is!

>   (x = p; x < &p[10]; x += 3)


The problem in my example is that I am bumping x by 3 each time. Sure
it would work if the 3 is replaced by 1, because of the special kludge
in the ANSI standard to allow &p[10] but the increment of 3 causes the
value of x to be further past the end of the array, and this is not
required to work.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Bryan Dollery]

Ronald E Jeffries wrote:

[...]

> Exceptions, however, whether represented as objects or long jumps, are
> about handling the unexpected.

Nice misconception. Exceptions are deviations from the rule.

There has also been some discussion in this thread about partial/total
functions, and how total functions don't need exception handlers (all
implementations of functions are partial because the state of the
underlying software/hardware can not be known, and this environment
constitutes part of the input to the function, thus making any 'total'
function partial, as some of its inputs are implied). 

I beg to differ. "Exceptions" aren't just techniques to handle errors in
input, output or computation. Exceptions are exactly that, exceptions.
The reason 'exception handlers' aren't called 'error trappers' is
because they don't just trap errors.

If one has a routine to search a list from a given position for a
paricular value one could implement this algorithm:


(pseudo-code)
search( this, for, from )
{
  if from < this.LowerBounds or from > this.UpperBounds
    return -1
  i := from
  while ( i < this.UpperBound)
    if ( this[i] = for )
      return i
  loop
  return -1
}

This has all sorts of problems. Uglyness is just one of them. However,
without exceptions and attempt to tidy it up would just make it longer,
and uglier.

With exception handling:

search( this, for, from )
  try
    i := from
    while ( this[i] != for )
    loop
    return i
  except
    return -1
end

Ok, this does enforce the precondition that FROM has to be within the
bounds of the list. But this is just a side effect, and could be made
explicit with a comment, or even a condition statement, or an assertion.
The main point is that the general rule is to itterate the list, and to
find the required item. That is what this routine does. If something
unusual happens, such as the item not being in the list, then an
exceptional situation has arrisen. Perfect.

This is of course not a perfect example, better ones could be found. It
could, and probably will, be argued that a search routine generally has
as good a chance of failing as succeeding. That is irrelevant. The point
is that exceptions to general processing should be handled by exception
handlers.

As to the question of an exception being an object. I have done some
research on this. It was proposed by my supervisor Dr Carl Bamford that
a new interface be added to the class structure, to augment the Public
and Private interfaces that are generally accepted by the C++
fraternity. This is an exception interface, to which exception handling
classes could be bolted. This was a method by which information and
control from exceptions could be gained.

-- 
Bryan Dollery.
MD ByteSmart Systems Ltd.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <yf3lo9iqzhz.fsf@sabi.demon.co.uk>,
Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:
>The obvious and correct solution is to make the name of the procedure
>dynamically scoped; then it can be redefined whenever this is needed.

Yes, it is well known that exception handling can be modeled as
dynamically-scoped procedure names.  And you explained that quite
clearly.  What is not clear (to me) is why you think that way of doing
things is so much better.

>Thus:
>
>* an exception is a fact, not an object;
>
>* the fact is the absence of a suitable 'else' somewhere when it should
>  be there;

Why "should be"?  What's wrong with partial functions?  I mean, it seems
perfectly reasonable to define "square root" such that negative numbers
don't have square roots.  Other definitions are possible (e.g. complex
numbers), but this definition is certainly a reasonable one.

>Finally, recovery from an exception may involve non local control
>transfers out of the procedure that handles the exception; but this is
>an entirely separate issue. It need not be the case.

It is almost always the case.

>So, basically *everything* is wrong (and clumsily so) with the ``C++''
>exception-as-object system:
>
>* the name of the exception class should be that of a dynamically scoped
>  procedure.
>
>* an exception object is really just a clumsy and silly way of
>  specifying an argument list to that dynamically scoped procedure.

You use words like "clumsy" and "silly", but you don't back them up with
real arguments very well.

>* non local control transfers are then mandatory.

This seems OK to me (see below).

>Consider the stark contrast between (in some language reminiscent of
>``C++''):
[example snipped]
>and
[C++ example snipped]

>As you can see the second solution is really just a clumsy, misleading,
>limited version of the first.

Sorry, but no, I can't see that.  They look more-or-less the same to me.
Here are some pieces of your example:

>    try { printf("%f\n",sqrt(-2.0)); }
>    catch(sqrt_neg_arg &sna)
>    {
>      // cannot just return 0.0 -- too bad.
>      puts("0.0"); // not really what we wanted
>    }

Why "not really what we wanted"?  If the goal is to "print out the
square root of the number, but if its negative, print 0.0", then the
above code seems to do that pretty clearly.  In your "fluid" example, on
the other hand, you trick the sqrt function into returning a bogus value
for a negative argument -- this doesn't seem clearer to me.

Alternatively, if you really want a sqrt function that returns zero for
negative arguments, why not write a wrapper function, which calls sqrt,
and has an exception handler saying "return 0.0"?  This is what you need
to do anyway, in the general case -- suppose I want to have square root
of a negative number return a complex number?  Well, I need a wrapper
function, since this new functionality has a different result type from
your sqrt, which returns a float.

But in any case, you normally don't want to print "0.0" for the square
root of -2 -- you want to print an error message, or do something else
entirely different, as in the next case:

>    try { printf("%f\n",sqrt(-2.0)); }
>    catch(sqrt_neg_arg &sna)
>    {
>      fprintf(stderr,"panic: negative arg to 'sqrt': %f\n",sna.f);
>      abort();
>    }

I claim that this is the sort of thing you usually want to do when you
handle an exception -- do something entirely different, and not just
pretend that all is well.  And your "fluid" example doesn't seem to do
this any better.

(Of course *most* exceptions aren't handled at all -- they're simply
bugs in the program, and you want to get rid of bugs before your
customers see them.  For this case, the value of an exception is just in
pinpointing the error, for ease of debugging.)

>Note that in effect in ``C++'' the 'fluid' storage class that turns a
>variable into a dynamically scoped one is pretty easy to simulate (in
>the shallow binding way) using constructors/destructors:
[example snipped]
>which seems rather legible, vastly more flexible/reasonable than the
>convoluted and limiting current ``C++'' syntax.

Again, why do you think this is better than using C++ exception
handling?

I'm reading this on comp.lang.ada, and Ada is a multi-threaded
language.  Your simulation of dynamic scoping doesn't quite work in a
multi-threaded environment.  You need to make the function pointer into
per-task data.

Note that this simulated dynamic scoping is likely to be much less
efficient than a (good) implementation of exception handling.  Exception
handling can (and should) be implemented using a PC-table-lookup
strategy, which makes it near-zero overhead to enter an exception-
handled region.

>Now there is completely orthogonal problem of non local control
>transfers, which might well be useful in a procedure implementation that
>``handles'' an exception. In the above code snippets an example of the
>use of non local control transfers is the call to 'abort()', which exits
>the current process and transfers control back to the invoking process;
>one could use 'setjmp()' or 'longjmp()', or something better, for finer
>grained control transfers.

A goto statement is what you want, but you want to goto an outer
procedure -- this is allowed in Pascal, for example.  And you want
nested procedures, of course.  (Of course, you can't use the word "goto"
in the name of a feature, or people will think you're evil.  On the
other hand, you can have a feature with semantics similar to goto, and
people will be perfectly happy -- so long as you don't call it goto.)

>It is a pity that the ``C++'' exception handling features tie so
>intimately together the distinct concepts of dynamically scoped
>identifiers (and then they are provided in a rather clumsy form) and of
>non local control transfers (and then they are also provided in a rather
>clumsy form).

OK, I guess I can see part of what you're saying: dynamic scoping and
non-local gotos ought to be two separate language features, each usable
in its own right, rather than combining them into a single feature
(exception handling).  (The "clumsy" doesn't add much to your argument,
since you don't really say what's so clumsy.)  Is this it?  I guess
there's some merit in that -- I like orthogonality.  Other than this, I
can't see any advantage of your scheme.

One advantage of the exceptions-as-objects viewpoint is that you can
have a hierarchy of exception classes.  This allows the call site to
determine the granularity of the exceptions to be handled.  E.g. handle
any I/O exception, or handle just the end-of-file exception, or handle
*all* exceptions.  This seems like a valuable capability, and I don't
see any way to do it in your "fluid" language.  E.g., suppose I want to
say, in the main program, "If I get *any* exception, send a signal to
the so-and-so device, telling it to shut down, and then I want to kill
the program"?

Another issue is efficiency:  I don't see any way to implement your
"fluid" feature with near-zero overhead on entering and leaving the
scope of a fluid object.  Exception handlers can be implemented
efficiently, because upon entering the scope of the handler, you can
know at compile time the address of the handler.  With fluid variables,
how do I know (at the original declaration point) that somebody won't
make a binding to some dynamic value?

Another issue is stack overflow: In Ada, if the stack overflows, you get
a Storage_Error exception.  The exception handler is executing *after*
chopping back the stack (i.e. after doing the non-local goto), so the
handler can reasonably do some work.  In your scheme, the handler is a
function, which is called while the stack is still "full".  You need
some way of ensuring that this function has enough stack space to do its
job -- perhaps hold a little bit of stack space "in reserve", so the
function can at least do a non-local goto.  This is easier in the Ada
case, since the only such function is the run-time system's
Raise_Exception procedure, which the compiler can know about.

I realize this is irrelevant to C++, where you can't even *try* to
handle stack overflows.

>  As to this, I rememjber reading someone stating that as far as he knew
>  only TECO (yes, TECO!) of most languages around provides general clean
>  entry/exit scope functions/triggers. Ah well.

What are "entry/exit scope functions/triggers".  (I don't know much
about TECO, except that it is terse to the point of looking like line
noise.)

- Bob

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <32e9e445.163056932@library.airnews.net>,
Ronald E Jeffries <jeffries@ic.net> wrote:
>In a project I'm presently working on, the input routines try to
>handle all the errors.  Then when the application definers decided
>what kind of notifications they wanted on input errors, we had to go
>in and edit the input routines and change them all around to get the
>job done.  Had they just thrown an exception, we could have fielded
>the exception where we wanted to, and filed our notifications and gone
>on.

But this is true in Mr. Grandi's scheme, too.  Instead of raising an
exception, Mr. Grandi calls a function to handle the error.  And that
function is *dynamically scoped*, which means that the call site can
define it.  Just like the call site defines the handler code in the C++
or Ada way of doing things.

What you say above is the whole point of exceptions -- one piece of code
detects an error, and a different piece of code decides what to do about
it.  And Mr. Grandi's scheme is just as good as the C++/Ada scheme, in
this regard.  (I'm not sure why Mr. Grandi thinks his scheme is so
vastly superior, though.)

- Bob

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <yf3lo9iqzhz.fsf@sabi.demon.co.uk>,
Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:
>The obvious and correct solution is to make the name of the procedure
>dynamically scoped; then it can be redefined whenever this is needed.

How about this: The exception-handler is a procedure that is passed to
the procedure that detects the error.  So, in your sqrt example, the
sqrt function would take a Float parameter, and a function to call in
case the Float is negative.  This is essentially how Smalltalk does
things.  If you allow defaults on parameters, then you can make the
default handler be "print out a message and kill the program" or "enter
the debugger" or whatever.  So callers only have to worry about it if
they want to do something special on sqrt(negative).

Is this not pretty much equivalent to your dynamic-scoping scheme?
And it has the advantage that the relevant information is in the
specification of the procedure that wants to "raise" the exception.

- Bob

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "bertrand" == Bertrand Meyer <bertrand@eiffel.com> writes:


Chris> ISE Eiffel does give the user a degree of parameterization: a
Chris> compilation option specifies the size threshold beyond which a
Chris> routine will not be inlined.

Bertrand> Most users are happy with the
Bertrand> default, which inlines small, frequently called routines.

Chris> How on earth does the compiler know if a routine is "frequently
Chris> called"?

bertrand> Sorry, sloppy wording on my part. I meant "called from many
bertrand> different places in the code", which does tend to correlate
bertrand> with the numbers of times the routine will be called, although
bertrand> of course this is not always true (as with a routine that is
bertrand> called from just one place, but that place is in a loop). Just
bertrand> one criterion among others. Thanks for noting the incongruity
bertrand> in my original message.

So it is the number of static invocations rather than dynamic calls.

However it is often possible and actually rather easy to estimate
dynamic call frequency in a compiler; usually by propagating loop
repetition estimates across procedur boundaries, which is not that
hard. Loop repetition estimates are actually often surprisingly easy, as
a few loops have statically known repetition counts, and for the others
assuming a notional repetition count (something like 10) often gives
suprisingly good results (I remember reading this in somebody's work, I
think the author of PCCTS, but I am not sure).

Re: What is wrong with OO ?

[Sean Case]

In article <E413nz.9IA@research.att.com>,
bs@research.att.com (Bjarne Stroustrup) wrote:

>I think that if C++ was as hard to understand and use as some people claim,
>it would have failed to become popular in the first place and would have
>vanished under the continuous barrage of fair and unfair criticism - despite
>its (eventual) popularity.

and also

>I have often found myself wondering if the C++ wouldn't have been much better
>for all concered had there (just) been two dozen good C++ books instead of
>the 400+ books that mostly fail to teach the basic principles and mostly
>lead students and programmers astray.

So, C++ must be easy to learn, or else there wouldn't be hundreds of books
about it by people who don't understand it properly.

Or, to put it another way, C++ looks easy to learn, but has hidden pitfalls
that bedevil even those who write books on the subject.

Sean Case


---------------------------------------------
Sean Case                  gscase@tpgi.com.au

Code is an illusion. Only assertions are real.

Re: What is wrong with OO ?

[William Grosso]

On Sun, 26 Jan 1997 16:09:42 +1100, gscase@tpgi.com.au (Sean Case)
wrote:
>
>So, C++ must be easy to learn, or else there wouldn't be hundreds of books
>about it by people who don't understand it properly.
>
>Or, to put it another way, C++ looks easy to learn, but has hidden pitfalls
>that bedevil even those who write books on the subject.
>

Or, to put it another way, lots of crappy books have been written on 
C++ because people who don't know much about it have decided
to demonstrate their ignorance (and make a quick buck or two). 

Why this reflects on C++ rather than the authors is pretty much a 
mystery to me. 


Cheers,

Andy
"In the beginning, everything was even money"
       --Mike Caro

Re: OO, C++, and something much better!

[Richard Riehle]

On Thu, 9 Jan 1997, Bertrand Meyer wrote:

> To the four properties listed in my original I should also add two
> just as essential requirements: true multiple inheritance, for combining
> different abstractions (and with the right mechanisms to avoid any
> ambiguity or conflict); and, most importantly, Design by Contract
> and the rules on how assertions combine with inheritance. As someone
> remarked, it is really impossible to understand inheritance without
> understanding Design by Contract.

  Bertrand,

  I understand that the notion of "design by contract" was probably
  your original contribution to the literature, and I also realize
  that your concept of it is inextricably linked to the Eiffel 
  model for assertions.  However, I would like to suggest another
  view of the same idea.

  Assertions, as I understand them are predominately a run-time
  check on the software entities.  If I may oversimply, Preconditions
  "require" that certain propositions are true for a feature to begin
  executing, Postconditions "ensure" the other propositions are true upon
  leaving a routine, and Invariants guarantee that certain 
  entities remain intact during execution. While this description does
  seem to oversimplify the Eiffel design of assertions, I hope it will not
  offend you.  

  The Eiffel assertion model contains all of the elements of an Ada
  type, though an Ada data type does not contain all the elements of
  an Eiffel assertion.  When I say, 

            type T is ... ;

  I am saying for T that there is a set of assertions which are post-,
  pre-, and invariant.  These assertions, implied to be sure, are also
  checked at run-time.  I am saying by the declaration for T, that
  there is a minimum value for T, a maximum value, and any routine
  that uses T must not let it stray from that range.  Also, in Ada 95,
  I can check the validity of that value at any time using the 
  expression,

            if T1'Valid then ... end if;

  where T1 is a value of type T.  

  My question is, can one write an invalid assertion in Eiffel?  That is,
  can the expression  for an assertion be some complex that it contains
  the very kind of error that we are trying to avoid with procedural
  code?

  If I define an assertion,


              require
                   some complex mathematical expression
              ensure
                   another complex expression
  
  is there some mechnism inherent in Eiffel that can evaluate my
  assertions for correctness?

  The Ada model for pre-, post- and invariant conditions is, to be sure,
  more conservative and less sophisticated than designed into Eiffel. But
  that very conservatism contributes to the simplicity of the process of
  creating specifications. 

  Although Ada software developers do not customarily use the expression,
  "design by contract," that is exactly what they are doing whenever they
  design their own data types and specify the acceptable ranges and
  boundaries acceptable for those types.  

  As for the assertion mechanism, itself, there is probably no reason
  why a compiler publisher could not add to an implementation three
  pragmas,

          pragma Precondition  ( expression )
          pragma Postcondition ( expression )
          pragma Invariant     ( expression )

  but in so doing we must ask whether the addition of such pragmas would
  really make the resulting program more reliable than it was using 
  the more conservative model of simple type definition.

  Bertrand, on a personal note, I am glad to see you engaged in this
  dialogue.  We need more of this level of discussion here. Thanks.


  Richard

Re: OO, C++, and something much better!

[Nick Leaton]

Roy Phillips wrote:
> ... More problematical is
> the
> accidental substitution, for example of an operation with same name but
> an
> entirely differant meaning (for example, the terms 'interest' (financial
> domain) and 'interest' (marketing domain)) - blame the English language
> if
> you will, but without semantic specification (i.e., Eiffel assertions)
> the
> whole thing is a can of worms.
> 

If we take two classes, car and array. We have an array of cars and car
is comparable. We can then have a sort implemented in array and sort
cars. But if we wish to sort cars by size or price, then it becomes a
little more difficult. You have two meanings to comparable for a car.
Personally, I'm not sure of the best way to approach this problem but I
suspect it would involve a sorter class, with price_sorter and
size_sorter classes derived from the base class sorter.
-- 

Nick

Re: What is wrong with OO ?

[Robert C. Martin]

In article <5bub0e$jfc@uni.library.ucla.edu>, jmartin@cs.ucla.edu (Jay
Martin) wrote:

> Since C
> programmers are notorously ignorant of computer language design, the
> audience is not too discerning. 

This is a an unworthy, biased, and biggotted statement.  The only common
attribute shared by the class of people called "C programmers" is that they
write programs in C.  They do not share any form of common ignorance. Any
notoriety to that effect comes from those who erroneously take such notice.  
They form another class of people whose sole common characteristic is that they
think C programmers are ignorant.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Paul Keister]

William Grosso <apuleius@ix.netcom.com> wrote in article
<32ebdcca.1653858@nntp.ix.netcom.com>...
: On Sun, 26 Jan 1997 16:09:42 +1100, gscase@tpgi.com.au (Sean Case)
: wrote:
: >
: >So, C++ must be easy to learn, or else there wouldn't be hundreds of
books
: >about it by people who don't understand it properly.
: >
: >Or, to put it another way, C++ looks easy to learn, but has hidden
pitfalls
: >that bedevil even those who write books on the subject.
Everything involving computers has hidden pitfalls.

: Or, to put it another way, lots of crappy books have been written on 
: C++ because people who don't know much about it have decided
: to demonstrate their ignorance (and make a quick buck or two). 
: 
: Why this reflects on C++ rather than the authors is pretty much a 
: mystery to me. 
C++ was designed so that it could be learned in stages, to that experienced
programmers (particularly C programmers) could use individual features of
the language as they are ready.  Unfortunatley, many people choose to write
books while they are in the beginning stages of learning C++.

For some of us, the love affair with C++ begins with the perception that
just by using member functions and inheritance in our procedural code,
things get clearer, and code gets easier to maintain.  Some people never
get past this stage(look at the Microsoft Foundation Classes, for
instance).  I my case, it took years for me to reach a level of
understanding where I was able to realize my ignorance.

I consider this to be a real strength of C++ and a key factor in its
overwhelming popularity.  But it does have a downside, which is that
beginner C++ programmers tend to be overconfident.

Writing a book with a title "Learn C++ in 29 Days" is the result of
calculating deception on the part of the author and/or publisher.  But when
someone buys the book, reads it in 29 days, and then has enough confidence
to consider themselves a C++ expert, you have to at least partly blame the
accessibility of the languges.

I don't think this is a bad thing, just a fact of life, and a natural
consequence of a language that is so woderfully accessible.

-- 
Paul Keister
        "opinions express are generally the
          exact opposite of my employer"
   http://www.crl.com/~diyall/husband

Re: What is wrong with OO ?

[Dann Corbit]

Following that line of reasoning:
There are thousands of books on elementary arithmetic.  Many times as many
as the number of C++ books.  That must mean that leaning elementary
arithmetic is only for Ph.D. candidates.  Certainly not for young children.

Your argument is NULL.

Try reading one of Steve Heller's books on C++.  They are designed so that
absolutely anyone can understand.  I am not saying that C++ is the easiest
thing on earth to learn.  Sometimes, there is difficulty associated with
learning (even elementary arithmetic has perils for those who have not yet
grasped all nuances).  Learning C++ is not so difficult that a capable high
school student cannot learn it.

Sean Case <gscase@tpgi.com.au> wrote in article
<AF1132469668D5B8@rd-ppp-072.tpgi.com.au>...
> In article <E413nz.9IA@research.att.com>,
> bs@research.att.com (Bjarne Stroustrup) wrote:
> 
> >I think that if C++ was as hard to understand and use as some people
claim,
> >it would have failed to become popular in the first place and would have
> >vanished under the continuous barrage of fair and unfair criticism -
despite
> >its (eventual) popularity.
> 
> and also
> 
> >I have often found myself wondering if the C++ wouldn't have been much
better
> >for all concered had there (just) been two dozen good C++ books instead
of
> >the 400+ books that mostly fail to teach the basic principles and mostly
> >lead students and programmers astray.
> 
> So, C++ must be easy to learn, or else there wouldn't be hundreds of
books
> about it by people who don't understand it properly.
> 
> Or, to put it another way, C++ looks easy to learn, but has hidden
pitfalls
> that bedevil even those who write books on the subject.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "jeffries" == Ronald E Jeffries <jeffries@ic.net> writes:

jeffries> On 25 Jan 1997 02:07:04 +0000, piercarl@sabi.demon.co.uk (Piercarlo
jeffries> Grandi) wrote:

piercarl> Let's start with the nature of exceptions. The first point is
piercarl> that if a procedure implements a total function then it will
piercarl> never have an exception.

piercarl> Therefore exceptions arise only and only if a procedure
piercarl> implements a partial function, and arise only and only when
piercarl> the inputs to a procedure are outside its domain.

jeffries> Yes ... and then you go on to make the function more robust,
jeffries> which would be a good thing when it's practical.  But as you
jeffries> point out, the exceptions arise when the inputs are out of the
jeffries> range contemplated by the function as written.

jeffries> Exceptions, however, whether represented as objects or long
jeffries> jumps, are about handling the unexpected.

Not quite -- they are precisely about handling the *expected*, but
*undefined*. By definition you cannot handle the unexpected, I would
say.

[ ... ]

jeffries> In a project I'm presently working on, the input routines try
jeffries> to handle all the errors.  Then when the application definers
jeffries> decided what kind of notifications they wanted on input
jeffries> errors, we had to go in and edit the input routines and change
jeffries> them all around to get the job done.  Had they just thrown an
jeffries> exception, we could have fielded the exception where we wanted
jeffries> to, and filed our notifications and gone on.

Ah, but that's precisely a good example that shows that exception
handling (a terrible misnomer) is about dealing with the expected, but
undefined. It is expected that the ``user'' will do strange things, but
since it is as yet undefined what strange things will happen, one punts
to an handler define by a dynamic-context, and this is the very reasons
for having dynamically scoped identifiers.

Put another way exception handling is when the required precondition of
a procedure is weaker than that of the procedure one actually is in a
position to write. The difference is then filled in by calling
dynamic-context dependent ``handlers''.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "bobduff" == Robert A Duff <bobduff@world.std.com> writes:

bobduff> In article <yf3lo9iqzhz.fsf@sabi.demon.co.uk>,
bobduff> Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:

piercarl> The obvious and correct solution is to make the name of the
piercarl> procedure dynamically scoped; then it can be redefined
piercarl> whenever this is needed.

bobduff> How about this: The exception-handler is a procedure that is
bobduff> passed to the procedure that detects the error.  So, in your
bobduff> sqrt example, the sqrt function would take a Float parameter,
bobduff> and a function to call in case the Float is negative.  This is
bobduff> essentially how Smalltalk does things.  If you allow defaults
bobduff> on parameters, then you can make the default handler be "print
bobduff> out a message and kill the program" or "enter the debugger" or
bobduff> whatever.  So callers only have to worry about it if they want
bobduff> to do something special on sqrt(negative).

bobduff> Is this not pretty much equivalent to your dynamic-scoping
bobduff> scheme?

It is indeed entirely equivalent for that is a (xxx-reduction it the
technical term, I don't remember offhand which greek letter stands for
xxx), a way to transform global (dynamically scoped) variables into
procedure parameters.

If one does not like global variables, dynamically scoped or not, one
can transform them into parameters to all procedures that access
them. But then for all their awfulness global variables, and even
dynamically scoped global variables, are useful, in the sense they are
merely convenient, for the xxx-reduction involves a bit more verbiage.

With non-too-clever implementations adding defaulted extra arguments can
also result in distinctly inferior code, because it involves passing an
extra argument for each potential ``exception'' one wants to handle.

Consider for example floating division: it would require at least three
extra ``implicit'' arguments/parameters (overflow, underflow, illegal
divisor).

bobduff> And it has the advantage that the relevant information is in
bobduff> the specification of the procedure that wants to "raise" the
bobduff> exception.

This is not a big advantage; one can achieve the same effect by
requiring, as some languages do, a procedure/module to ``import''
explicitly any global (or fluid) variables it will make use of.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "bobduff" == Robert A Duff <bobduff@world.std.com> writes:

[ ... ]

bobduff> What you say above is the whole point of exceptions -- one
bobduff> piece of code detects an error, and a different piece of code
bobduff> decides what to do about it.  And Mr. Grandi's scheme is just
bobduff> as good as the C++/Ada scheme, in this regard.  (I'm not sure
bobduff> why Mr. Grandi thinks his scheme is so vastly superior,
bobduff> though.)

Actually, it's not *my* scheme, it has been known for thirty years or
so; and then it is not quite "vastly superior", it is just the right
thing to do; my point is that:

  piercarl> So, basically *everything* is wrong (and clumsily so) with
  piercarl> the ``C++'' exception-as-object system:

  piercarl> * the name of the exception class should be that of a
  piercarl>   dynamically scoped procedure.

  piercarl> * an exception object is really just a clumsy and silly way of
  piercarl>   specifying an argument list to that dynamically scoped
  piercarl>   procedure.

  piercarl> * non local control transfers are then mandatory.

These things are wrong because they involve a clumsy and limited
mechanism. Dynamically scoped identifiers are usuful for a number of
cases where actions must depend on the program context; dynamically
scoped variables, not just procedures, are very useful too. Non local
control transfers are also very useful in their own right.

Now, ``exception handling'' presents as an ad hoc, and often pretty
ungainly mechanism, a particular, and restrictive, combination of the
fundamental concepts of dynamic coping and non-local control transfers.

It is much better to provide the two things separatley, for this allows
for example ``exception handling'' _without_ forcing control transfers,
and control transfers without necessarily involving dynamically scoped
identifiers. And then runtime parametrization via dynamically scoped
variables...

But really the biggest problem of the mechanism is that it presents as
something complicated and special, to the point of requiring its own
control structure, chapter in the book, papers, and so on, what is an
entirely simple thing, as long as one presents it as: dynamic scope
+optional control transfer.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "bobduff" == Robert A Duff <bobduff@world.std.com> writes:

bobduff> In article <yf3lo9iqzhz.fsf@sabi.demon.co.uk>,
bobduff> Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:

piercarl> The obvious and correct solution is to make the name of the
piercarl> procedure dynamically scoped; then it can be redefined
piercarl> whenever this is needed.

bobduff> How about this: The exception-handler is a procedure that is
bobduff> passed to the procedure that detects the error.  So, in your
bobduff> sqrt example, the sqrt function would take a Float parameter,
bobduff> and a function to call in case the Float is negative.  This is
bobduff> essentially how Smalltalk does things.  If you allow defaults
bobduff> on parameters, then you can make the default handler be "print
bobduff> out a message and kill the program" or "enter the debugger" or
bobduff> whatever.  So callers only have to worry about it if they want
bobduff> to do something special on sqrt(negative).

bobduff> Is this not pretty much equivalent to your dynamic-scoping
bobduff> scheme?

It is indeed entirely equivalent for that is a (xxx-reduction it the
technical term, I don't remember offhand which greek letter stands for
xxx), a way to transform global (dynamically scoped) variables into
procedure parameters.

If one does not like global variables, dynamically scoped or not, one
can transform them into parameters to all procedures that access
them. But then for all their awfulness global variables, and even
dynamically scoped global variables, are useful, in the sense they are
merely convenient, for the xxx-reduction involves a bit more verbiage.

With non-too-clever implementations adding defaulted extra arguments can
also result in distinctly inferior code, because it involves passing an
extra argument for each potential ``exception'' one wants to handle.

Consider for example floating division: it would require at least three
extra ``implicit'' arguments/parameters (overflow, underflow, illegal
divisor).

bobduff> And it has the advantage that the relevant information is in
bobduff> the specification of the procedure that wants to "raise" the
bobduff> exception.

This is not a big advantage; one can achieve the same effect by
requiring, as some languages do, a procedure/module to ``import''
explicitly any global (or fluid) variables it will make use of.

Re: OO, C++, and something much better!

[matthew mclellan]

Nick Leaton (nickle@calfp.co.uk) wrote:
: Roy Phillips wrote:
: > ... More problematical is
: > the
: > accidental substitution, for example of an operation with same name but
: > an
: > entirely differant meaning (for example, the terms 'interest' (financial
: > domain) and 'interest' (marketing domain)) - blame the English language
: > if
: > you will, but without semantic specification (i.e., Eiffel assertions)
: > the
: > whole thing is a can of worms.
: > 

: If we take two classes, car and array. We have an array of cars and car
: is comparable. We can then have a sort implemented in array and sort
: cars. But if we wish to sort cars by size or price, then it becomes a
: little more difficult. You have two meanings to comparable for a car.
: Personally, I'm not sure of the best way to approach this problem but I
: suspect it would involve a sorter class, with price_sorter and
: size_sorter classes derived from the base class sorter.
: -- 

: Nick

What about deriving car_array from array, and overriding the sort method?

Matt
Raytheon E-Systems

--The opinion(s) expressed above are mine, and not at all related to Raytheon
	E-Systems

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <yf3wwsxqw1z.fsf@sabi.demon.co.uk>,
Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:
>Actually, it's not *my* scheme, it has been known for thirty years or

Yes, I realize you didn't invent it.  ;-)

>...Dynamically scoped identifiers are usuful for a number of
>cases where actions must depend on the program context; dynamically
>scoped variables, not just procedures, are very useful too. Non local
>control transfers are also very useful in their own right.

OK, I'll buy that much.

But how do you write an ``exception handler'' that catches a whole class
of related exceptions.  (E.g. division by zero might raise
"Divide_Error", and the caller can choose to handle "Divide_Error" or
"Arithmetic_Error" (which includes Divide_Error), or "Any_Exception", or
whatever.)

- Bob

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[John W. Sarkela]

Piercarlo Grandi wrote:
[...]
> But really the biggest problem of the mechanism is that it presents as
> something complicated and special, to the point of requiring its own
> control structure, chapter in the book, papers, and so on, what is an
> entirely simple thing, as long as one presents it as: dynamic scope
> +optional control transfer.
I would advance the argument that the nature of the most appropriate
exception mechanism will vary as one adopts procedural, functional or
object oriented points of view. 

As an example of why I think objects modeling exceptions are right, I
would use the point of view first expressed to me by Bertrand Meyer,
programming by contract. Using the exception mechanism with which I
am most familiar, Visual Smalltalk's.

In human interaction, a contract is a document that describes a promise
of service to a client. A contract has three important qualities.
  1. It is observable by client and supplier.
  2. It is verifiable by client and supplier.
  3. It is enforcable by client or supplier.
When either the client or supplier detects that the terms of the
contract
have been violated, the situation is sent into arbitration for
resolution.

In my programs exactly the same holds true. When assertions about the
state
of execution have been violated, I create an instance of an exception
that
models as carefully as possible all of the information about the
observed
violation of specification. Thus, from an object modeling perspective,
the
exception object serves as the court of arbitration for disputes between
clients
and servers.  Handlers may be set associated with method activation
records.
Each handler serves as a local arbitrator for the signaled exception. If 
recovery is not possible, the dispute may be passed to the next higher
authority.
If none are found, default rules may be handled by the exception object
itself.

I have found this model of exceptions and their handling to be both
intuitive
and effective. The fact that non-local control transfers occur is not
really
a problem conceptually, because the control unwinds the chain of
activations
that led to the exceptional situation in the first place.

This is a rational, structured, normal handling of exceptions in an
object
model. If I were using a functional language, then total functions would
be a more appropriate point of view. However, for an object oriented
language
exceptions as objects provide a rich implementation mechanism for
supporting
the design notion of programming by contract.

John Sarkela
jsarkela@enfish.com

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[John (Max) Skaller]

On Sat, 25 Jan 1997 20:52:41 GMT, bobduff@world.std.com (Robert A
Duff) wrote:

>I'm not sure why Mr. Grandi thinks his scheme is so
>vastly superior, though.

	The reasons are plain enough: 

	First, the scheme permits retry, C++ style exceptions do not.

	Second, the scheme does not require any special
	constructions. No exception handling constructions.

	It is implemented using dynamically scoped functions,
	which are useful for other things.

	Summary: the scheme subsumes the C++ scheme
	because it can do everything the C++ scheme can do,
	with no more complexity, using other facilities --
	which are also useful in other contexts.

This would be totally convincing were it true: a language
should not introduce new special constructions when
a library component or technique would suffice.

In the example of a dynamically scoped function, there
is a direct correspondence between the "throw"
function and the "catch" function. (They're
both called the same name).

Question: What is the functional equivalent to the ability
of C++ to provide "matching"?

Re: What is wrong with OO ?

[Damon Feldman]

In article <rmartin-2701971103140001@pool10-006.wwa.com>, rmartin@oma.com (Robert C. Martin) wrote:
>In article <5bub0e$jfc@uni.library.ucla.edu>, jmartin@cs.ucla.edu (Jay
>Martin) wrote:
>
>> Since C
>> programmers are notorously ignorant of computer language design, the
>> audience is not too discerning. 
>
>This is a an unworthy, biased, and biggotted statement.  The only common
>attribute shared by the class of people called "C programmers" is that they
>write programs in C. 

While technichally true, I hope this doesn't mean that I have to stop 
insulting COBOL programmers when I see them on the street :-).

Perhaps the original poster meant to say that programmers who *advocate C
as a superior language* are ignorant of language design.  This would have
some logic behind it.

Damon

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Lawrence G. Mayka]

piercarl@sabi.demon.co.uk (Piercarlo Grandi) wrote:

>It is much better to provide the two things separatley, for this allows
>for example ``exception handling'' _without_ forcing control transfers,
>and control transfers without necessarily involving dynamically scoped
>identifiers. And then runtime parametrization via dynamically scoped
>variables...

Ironically, though, your first posting in this thread was a response
to =my= posting, pointing out to Mr. Stroustrup that his design for
exception handling was implemented years earlier in Common Lisp.  As
you may know, Common Lisp has long had both nonlocal control transfers
(THROW and CATCH--perhaps Bjarne even borrowed his keywords from
Lisp!) and dynamically scoped variables (as an option, along with the
default behavior of lexical scoping).  Indeed, some implementations of
ANSI Common Lisp exception handling do indeed employ these earlier
constructs.  Just as you suggest, dynamically scoped functions are
easily simulated via dynamically scoped variables whose values are
function objects, or via syntax extension (the Common Lisp
macroization system).

But what your scheme lacks is a classification or "matching"
mechanism.  Common Lisp was well-prepared to provide this because,
even before the standardization of CLOS, it offered the
single-inheritance capability of DEFSTRUCT and the type-testing
operator TYPEP; and so the Pittman Condition System was implementable
entirely on top of 1985-vintage Common Lisp constructs, yet easily
extendible to CLOS later.

One other very useful element both your scheme and that of C++ lacks
is that of closures as handlers.  Very often, an exception handler is
more comfortably and easily written as a lexically scoped function
that manipulates the variables of an outer function.  Again, Common
Lisp already had full-power lexical closures by 1985, whereas C++
still doesn't.

You may ask, if a language such as Common Lisp already has all the
necessary base capabilities, why provide the "syntactic sugar" of
exception handling constructs?  To clarify, standardize, and perhaps
optimize conventional usages.  Since Common Lisp supports syntax
extension (a powerful macroization system), programmers would probably
be writing such syntactic encapsulations anyway; we may as well
standardize them to enhance portability of programs, skills,
knowledge, etc.


Lawrence G. Mayka
lgmayka@sprynet.com

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert Dewar]

Lawrence said

"Ironically, though, your first posting in this thread was a response
to =my= posting, pointing out to Mr. Stroustrup that his design for
exception handling was implemented years earlier in Common Lisp."

It is just conceivably possible that Mr Stroustrup is indeed familiar
with Common Lisp and quite a few other languages :-) :-) :-)

(is three smileys enough to make it quite clear to people that an element
of sarcasm is intended :-)

If you really think that Common Lisp invented the idea of exceptions, then
you need to do some more history reading yourself!

Really, everyone should realize that language design does not happen in
a vacuum. Of course good ideas are borrowed from one language to another.
For example, many of the most important contributions that Algol-68 has
been made are in the form of ideas exported to other languages (e.g.
serial elaboration of declarations and the notion of subunits -- copied
from A68 into Ada). 

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <5d93d3$nhs$1@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>ka@socrates.hr.lucent.com (Kenneth Almquist) writes:
>>Dynamic scoping is not a particularly good candidate for inclusion in
>>a language because the programmer can implement it by hand (at least in
>>C++ and Ada) and with good program design it should be rarely used.

But it is *always* used (in C++ and Ada) when you raise exceptions.
I admit that it is rarely needed in any other contexts.

>>...  The
>>same goes for nonlocal gotos; these can be simulated using Ada/C++ style
>>exceptions and with good program design they should be rarely used.

This seems like abstraction inversion, to me.  It makes more sense to me
to say that exceptions are implemented in terms of non-local gotos,
rather than the other way 'round.

I don't understand why gotos are considered evil, whereas exceptions are
OK.  Raising an exception has at least as bad an effect on readability
as a goto -- it's like a goto, but you can't tell (statically) where
it's going to.  Nonetheless, exceptions are a Good Thing (whether they
are done like Ada or like Piercarlo Grandi wants).

>Without wanting to argue either for or against dynamic scoping (some of
>my favourite languages have it and some haven't), the claim that "the
>programmer can implement it by hand" is true only in the sense that the
>programmer can implement most control structures using "if ... goto".
>You can in this sense implement almost _anything_ by hand, but you'd be
>mad to, and you wouldn't put up with a language designer using that
>excuse to omit while loops from the language.

Well, in Smalltalk, while loops are not exactly part of the core
language -- they're part of the predefined library.  And I think that's
a pretty elegant way to do it.

>In fact, the programmer can _not_ implement dynamic scoping easily by
>hand in Ada and thanks to the arcane scope rules of C++ (from time to
>time I reread the draft C++ standard trying to find out what the scope
>rules _are_, does _anyone_ know?) it is even less true there.
>
>There are a number of points about dynamic scoping:
>(a) it dilutes the "ownership" of a name.
>    For this reason I don't think it would be appropriate for Ada.
>(b) dynamically scoped variables are automatically unwound whenever
>    a contour rebinding them is exited for whatever reason.
>(c) binding and unbinding dynamically scoped variables is expected
>    to be CHEAP.
>Simulating dynamically scoped variables in Ada or C++ would seem to require
>- introducing a *visible* shadow variable to hold the outer value
>- setting up an exception handler to unwind and resignal
>- remembering to unwind at _every_ return point.
>This is a heavy burden on the programmer, worse in my view than having
>to use "if ... goto .." instead of "while".  It is also likely to be
>seriously less efficient than a reasonable mechanism implemented by the
>compiler.

The above can simulated in Ada using controlled types.  It's possible to
implement controlled types efficiently, but it's not easy in the general
case, and I don't know of any Ada compilers that do so.

- Bob

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Patrick Doyle]

In article <01bc14ab$3ce476e0$752d54c7@vbykov.hip.cam.org>,
Vassili Bykov <vbykov@cam.org> wrote:
>
>Control constructs cannot *in principle* be a part of the standard library.
>(Unless you take Lisp or Scheme and consider macros as part of the
>library--which, strictly speaking, they are not).

  Why is that?

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "jmartin" == Jay Martin <jmartin@cs.ucla.edu> writes:

jmartin> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

piercarl> Well, yes and no. Not quite. It can be kludged, and I have
piercarl> provided one such kludge, but adding to a language is easy but
piercarl> non trivial. Since it is needed regardless of whether a
piercarl> language provides it or not, it's better to have it done
piercarl> cleanly and efficiently rather than as a kludge.

piercarl> This is actually a general principle of system/language
piercarl> design; there are a number of features which are essential,
piercarl> and cannot simply be omitted; omitting them from the
piercarl> primitives of the languages will simply mena that the
piercarl> implementation burden shifts on the programmer. My two
piercarl> favourite examples are spooling for operating systems and
piercarl> generators for programming languages. There are OSes that
piercarl> don't have spooling, and then it must be done by the user, by
piercarl> multitasking her/imself; there are languages that don't have
piercarl> generators, and then they must be simulated by the programmer,
piercarl> usually via global variables or ``control blocks''. In either
piercarl> case it is a waste. Dynamic scoping is another good example.

jmartin> It seems to me you are assuming that dynamic scoping is necessary and
jmartin> that a programmer will have to simulate it.  It seems more prudent to
jmartin> me to recognize the limitations and paradigm of your tool and just
jmartin> implement it in the tedious and boring "normal" way.

Ahhh, but what I have been arguing is merely the obvious: runtime
customization of imlementations is a fact of life, whether one like sit
or not, and dynamically scoped identifiers are the most
direct/obvious/``simplest'' way to do it, e.g. environment variables in
UNIX and similar facilities in most other systems/languages.

It is well true that once can always perform a reduction from a program
with statically or dynamically scoped global/fluid variables to one that
does not have them, only parameters and local variables (and the latter
can further be transformed into parameters):

jmartin> Which in this instance is by passing parameters

but this does not necessarily mean that it is desirable... In effect it
is not very desirable, as long as the global/fluid variables left in teh
program are clearly encapsulated.

jmartin> or having different functions.

This is in the general case unfeasible (there can be any number of
procedures that one would want to do)...

jmartin> [ ... strong preference for the bondage&discipline school of
jmartin> programmign language design :-) ... ]

jmartin> When you are in a room filled criminally insane programmers,
jmartin> straightjackets nstart sounding like a cool idea.

I must confess that this approach actually strikes a chord with me,
except that I'd rather have a BFG-9000 than a set of straitjackets :-).

But then on balance, emotions set aside, I tend to prefer tools that can
be used nicely by the non criminally insane (the merely insane probably)
programmers to do nifty things, than those designed for damage
limitation. Perhaps I am an incurable optimist.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Vassili Bykov]

Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote in article
<5def36$rjd@mulga.cs.mu.OZ.AU>...
> "Vassili Bykov" <vbykov@cam.org> writes:
> > [...]
> >Control constructs cannot *in principle* be a part of the standard
library.
> 
> Sure they can.  Consider tcl, for example.

Oops, sorry I jumped it--in the post I replied to, Kenneth Almquist was
talking about Ada and C++ so I assumed "regular" languages with
applicative-order evaluation.  In these, they cannot because functions
always evaluate arguments.  For control constructs you would either need
lazy as in Haskell or syntactially transparent delayed as in Smalltalk
evaluation.  (Or... hmm... weird? as in Tcl. :-)

> >(Unless you take Lisp or Scheme and consider macros as part of the
> >library--which, strictly speaking, they are not).
> 
> Why aren't they?  What *in principle* reason is there why they can't be?

Because macros are AST (or token stream, in lesser languages)
transformation rules known to the compiler. Libraries are collections of
machine (or virtual machine) code blocks to be called by the application
program.  In other words, macros extend the compiler while library routines
extend the apllication program.  That's the "strictly speaking" reason I
meant.  

I didn't mean to be dense--I said that only because if we extend the
meaning of "standard library" to include standard macros always known to
the compiler then what is the difference between "part of the library" and
"part of the language"?

--Vassili

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Bill Gooch]

Vassili Bykov wrote:
> 
> ....
> I didn't mean to be dense--I said that only because if we extend the
> meaning of "standard library" to include standard macros always known to
> the compiler then what is the difference between "part of the library" and
> "part of the language"?

Why should there be such a difference in practice, 
regardless of the nature of the extension?

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Vassili Bykov]

Bill Gooch <bill@iconcomp.com> wrote:
> Vassili Bykov wrote:
> > I didn't mean to be dense--I said that only because if we extend the
> > meaning of "standard library" to include standard macros always known
to
> > the compiler then what is the difference between "part of the library"
and
> > "part of the language"?
> 
> Why should there be such a difference in practice, 
> regardless of the nature of the extension?

I don't say there should be.  I was referring to the part of the original
Fergus Henderson's <fjh@murlibobo.cs.mu.OZ.AU> message:

> Actually I'd be quite happy with a language in which while loops
> were part of the standard library, rather than part of the language.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <01bc14ab$3ce476e0$752d54c7@vbykov.hip.cam.org>,
Vassili Bykov <vbykov@cam.org> wrote:
>Control constructs cannot *in principle* be a part of the standard library.

Control constructs *are* part of the standard library in Smalltalk.  And
it's an elegant way to do things.  I'm not sure what you mean by "*in
principle*" in this case.

Probably (I suspect) the whileTrue:do: thing (or whatever it's called)
in Smalltalk is implemented as a "built in" thing in most
implementations, but that's not semantically necessary.  If Smalltalk
had a goto primitive, one could write the while loop primitive in
Smalltalk.  (Actually, I guess you can do it via recursion, if you're
willing to count on tail recursion elimination.)  In any case, the fact
that it's "built in" to the compiler does not imply that it's "built in"
to the semantics -- I mean, a C compiler is well within its rights to
"build in" the printf function (i.e. special case it in some way that
might get better efficiency).

>(Unless you take Lisp or Scheme and consider macros as part of the
>library--which, strictly speaking, they are not).

No, they're not macros, they're "normal" messages/methods (that is,
procedure calls), with "blocks" as parameters.  (I'm not sure why macros
are considered out of bounds here, but in any case, macros aren't needed
in this case.)

- Bob

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Jay Martin]

pcg@aber.ac.uk (Piercarlo Grandi) writes:

>>>> "jmartin" == Jay Martin <jmartin@cs.ucla.edu> writes:

>Ahhh, but what I have been arguing is merely the obvious: runtime
>customization of imlementations is a fact of life, whether one like sit
>or not, and dynamically scoped identifiers are the most
>direct/obvious/``simplest'' way to do it, e.g. environment variables in
>UNIX and similar facilities in most other systems/languages.

Yeah but sometimes you have to go that extra mile for good software.

>jmartin> Which in this instance is by passing parameters

>but this does not necessarily mean that it is desirable... In effect it
>is not very desirable, as long as the global/fluid variables left in teh
>program are clearly encapsulated.

I basically always pass data and almost never use variables from a
larger scope (globals). Doesn't seem much of burden to me. Explicit
data flow seems clearer and to not do so is conceptually using
"side-effects".  Ick!

>jmartin> or having different functions.

>This is in the general case unfeasible (there can be any number of
>procedures that one would want to do)...

But in specific cases it works fine.  Generality can have many downsides.
  

Jay

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Fergus Henderson]

"Vassili Bykov" <vbykov@cam.org> writes:

>I didn't mean to be dense--I said that only because if we extend the
>meaning of "standard library" to include standard macros always known to
>the compiler then what is the difference between "part of the library" and
>"part of the language"?

The difference is that things that are part of the library are things
that a user can program user-defined alternatives.  For example,
in C, printf() is part of the standard library, and you can write a
my_printf() function that does similar things to printf() (and
is perhaps implemented as a layer on top of printf()).  On the
other hand, it's not possible to do the equivalent for Pascal's
write statement or for C's for loops, because these are part of
the language proper, not the standard library.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "fjh" == Fergus Henderson <fjh@murlibobo.cs.mu.OZ.AU> writes:

[ ... ]

fjh> The difference is that things that are part of the library are things
fjh> that a user can program user-defined alternatives.  For example,
fjh> in C, printf() is part of the standard library, and you can write a
fjh> my_printf() function that does similar things to printf() (and
fjh> is perhaps implemented as a layer on top of printf()).  On the
fjh> other hand, it's not possible to do the equivalent for Pascal's
fjh> write statement or for C's for loops, because these are part of
fjh> the language proper, not the standard library.

Well, even if 'printf' were syntactically a statement and not a
procedure call, you could still write your 'my_printf' as a procedure;
similarly that 'if then else' is not a procedure call in ``Pascal'' does
not forbid you from writing a procedure like
'myif(condition,thenPart,elsePart)'.

The real reason why/why not is rather different from being alanguage
primitive or not; it is whether one has the reflective abilities to
implement one's own verion of 'printf' or 'myif'.

In ``C'' one has the reflective facilities for writing one's own
'printf' (such facilities are '#include <stdarg>', which allow a
procedure to ``reflect'' on its parameter list), but not for writing
control structures (except for some very limited ability using
preprocessor macros). Pascal does not offer reflective
abilities/primitives for parameter lists or control structures.

There are languages that offer user-visible primitives that allow
building ad-hoc control structures, by way of ``reflection''; usually
such facilities, as a bit of overkill, are based on that extremely
powerful reflective ability, the one to reflect on program state via
continuations/closures, and the associated one, the ability to reflect
on program fragments; for example Scheme and Smalltalk-80 allow
definitions of control structures using either/both reflection on
continuation/closures and code fragments. Neither are avalable in ``C''
or ``Pascal'', and thus control abstraction is not possible; the issue
is not thus quite related to having some reserved syntax or not.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "fjh" == Fergus Henderson <fjh@murlibobo.cs.mu.OZ.AU> writes:

[ ... ]

fjh> The difference is that things that are part of the library are things
fjh> that a user can program user-defined alternatives.  For example,
fjh> in C, printf() is part of the standard library, and you can write a
fjh> my_printf() function that does similar things to printf() (and
fjh> is perhaps implemented as a layer on top of printf()).  On the
fjh> other hand, it's not possible to do the equivalent for Pascal's
fjh> write statement or for C's for loops, because these are part of
fjh> the language proper, not the standard library.

Well, even if 'printf' were syntactically a statement and not a
procedure call, you could still write your 'my_printf' as a procedure;
similarly that 'if then else' is not a procedure call in ``Pascal'' does
not forbid you from writing a procedure like
'myif(condition,thenPart,elsePart)'.

The real reason why/why not is rather different from being alanguage
primitive or not; it is whether one has the reflective abilities to
implement one's own verion of 'printf' or 'myif'.

In ``C'' one has the reflective facilities for writing one's own
'printf' (such facilities are '#include <stdarg>', which allow a
procedure to ``reflect'' on its parameter list), but not for writing
control structures (except for some very limited ability using
preprocessor macros). Pascal does not offer reflective
abilities/primitives for parameter lists or control structures.

There are languages that offer user-visible primitives that allow
building ad-hoc control structures, by way of reflection; usually such
facilities, as a bit of overkill, are based on that extremely powerful
reflective ability, the one to reflect on program state via
continuations/closures, and the associated one, the ability to reflect
on program fragments; for example Scheme and Smalltalk-80 allow
definitions of control structures using either/both reflection on
continuation/closures and code fragments. Neither are avalable in ``C''
or ``Pascal'', and thus control abstraction is not possible.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Fergus Henderson]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

>I wrote:
>>>In fact, the programmer can _not_ implement dynamic scoping easily by
>>>hand in Ada and thanks to the arcane scope rules of C++ (from time to
>>>time I reread the draft C++ standard trying to find out what the scope
>>>rules _are_, does _anyone_ know?) it is even less true there.
>
>fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) replied fliply:
>>To answer your parenthetical question, the scope rules are defined in
>>sections 3.3 [basic.scope] and 3.4 [basic.lookup] of the draft.
>
>Get real!

OK, that _was_ a bit flip.  You're right that the scope rules of C++
can be rather arcane.

>fjh proposes the following sketch of implementing a dynamically
>scoped variable in C++:
>
>>	#include "dynamic_scope.h"
>>	
>>	dynamically_scoped<int> x;
>
>>	void foo() {
>>		rebind<x> local_x;	// or something like that
>>	}
>
>Close, but not quite.  (This approach is also applicable in Ada 95.)
>
>What's wrong with it?  x has the wrong type.

You can give `x' an implicit conversion to type "reference to int".

	operator int & ();

Now, due to C++'s arcane overloading rules ;-), this is not
exactly the same in all circumstances, but it usually does
the trick.  Sometimes you may have to insert a few additional
explicit conversions.

(My compiler seems to think that you need an assignment operator
as well.  Maybe it's right.)

>In languages that have them, dynamically scoped variables follow different
>_scope_ rules from other variables, but there is nothing special about
>their _contents_.  It would be necessary to do something like
>
>	int x;
>
>	void foo() {
>	    rebind< &x > preserved_x;
>	    ...
>	}

You could do that too, and it would work fine in the case of `int'.
However, for other types that has some disadvantages.
It won't work if type of `x' doesn't allow copying.
Even if `x' can be copied, you will most likely have to do a deep copy,
which may be slow.  That's why I went for the approach with
the implicit conversion-to-reference instead.

>An "implementation" of
>dynamically scoped variables which depends on giving them the wrong
>type (your approach) _does_ impose a heavy burden on the programmer,
>because then every reference that would have been a reference to x
>has to become x.contents() or whatever you want to call it.

No, that's not correct, because you can use an implicit conversion.

>>>It is also likely to be
>>>seriously less efficient than a reasonable mechanism implemented by the
>>>compiler.
>
>>I'm not convinced.
>
>Why not.  Do you actually know any C++ compilers which make your approach
>run as fast as a good Lisp system (Harlequin, Franz, CMUCL)?  The obvious
>mechanism is essentially a Prolog-style trail.

Well, with the implementation I was thinking of, block entry and block
exit are likely to quite cheap.  The main cost of my C++ implementation
is that you have an extra indirection for each access to the variable.
But I think it will be at least competitive.

	template <class T> class dynamically_scoped;

	template <class T, dynamically_scoped<T> & ds_var> class rebind;

	template <class T>
	class dynamically_scoped {
		template <dynamically_scoped<T> & ds_var>
		friend class rebind<T, ds_var>;
		T* current_var;
		T original_var;
	public:
		dynamically_scoped() {
			current_var = &original_var;
		}
		dynamically_scoped<T>& operator = (const T &val) {
			*current_var = val;
			return *this;
		}
		operator T& () {
			return *current_var;
		}
	};

	template <class T, dynamically_scoped<T> & ds_var>
	class rebind {
		T new_var;
		T* prev_var;
	public:
		rebind() {
			prev_var = ds_var.current_var;
			ds_var.current_var = &new_var;
		}
		~rebind() {
			ds_var.current_var = prev_var;
		}
	private:
		// prevent copying
		rebind(const rebind<T, ds_var>&);
		void operator =(const rebind<T, ds_var>&);
	};

If you're willing to assume that the variable can be cheaply copied,
you can do better.  Here's an alternate implementation that has
performance characteristics that are more similar to your suggested
implementation:

	template <class T> class dynamically_scoped;

	template <class T, dynamically_scoped<T> & ds_var> class rebind;

	template <class T>
	class dynamically_scoped {
		template <dynamically_scoped<T> & ds_var>
		friend class rebind<T, ds_var>;

		T current_value;
	public:
		dynamically_scoped<T>& operator = (const T & x) {
			current_value = x;
			return *this;
		}
		operator T& () {
			return current_value;
		}
	};

	template <class T, dynamically_scoped<T> & ds_var>
	class rebind {
		T old_value;
	public:
		rebind() {
			old_value = ds_var.current_value;
		}
		~rebind() {
			ds_var.current_value = old_value;
		}
	private:
		// prevent copying
		rebind(const rebind<T, ds_var>&);
		void operator =(const rebind<T, ds_var>&);
	};

>Block entry:
>	for each dynamic variable x
>	    push contents of x onto Trail
>	push block descriptor onto Trail
>
>Block exit:
>	discard block descriptor from Trail
>	for each dynamic variable x in reverse order
>	    pop contents of x from Trail

With the second implementation above, block entry and exit are
in fact slightly cheaper:

  Block entry:
	for each dynamic variable x
	   copy (not push) contents of x onto stack

  Block exit:
	for each dynamic variable x
	   copy (not push) contents of x from stack

I tried a simple test of dynamically_scoped<int>.  My compiler (SGI
C++) generated one instruction to put the address of x in a register,
and then a load/store pair for block entry and a load/store pair for
block exit.

By storing the trail on the stack, you save having to increment the
trail pointer (the stack pointer increment is usually free, since you
normally have to increment it anyway).  You also reduce the danger
of cache collisions, although that's probably not a noticable effect.
Furthermore, unlike say Prolog, you pay the cost of trailing and
untrailing only when you're actually using it (you don't have
any untrail loops).  The downside is that you can't get tail recursion
optimization.

Most modern Unix C++ implementations use separate code address tables for
exception handling, so there's no need to push any descriptors.
(PC implementations are another matter, though -- they do normally
push and pop stuff.  I think that's mostly Microsoft's fault.)

>There are three things to be said about this:
>
>(1) it is hard to see how to do _substantially_ better than this.

Yes, but as shown above you can do slightly better, and in any case all
you really need is to not do substantially worse.

>(2) the exception unwinder uses block descriptors, it is hard to
>    see how such a _global_ mechanism can be efficiently simulated
>    by _local_ classes.

Well, the local C++ classes are making use of the underlying C++
exception handling mechanism, which could use a global block descriptor
stack or separate code address tables or some other global mechanism.

>(3) Lisp systems enforce certain _global_ restrictions on the use
>    of dynamic binding.  fjh's mechanism can simulate to some degree
>    what Lisp _allows_ but not what it _forbids_.

Could you be more specific about the restrictions that Lisp systems
enforce?

You can enforce quite a bit in C++.

>None of this should be taken as endorsing the addition of dynamic binding
>to any specific language.

Yes, and the fact that you *can* implement dynamically scoped variables
in C++ does not mean that you necessarily *should* ;-)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Charles A. Jolley]

> Well, who am I to judge.. but in my view C++ is basically C with the 
> capability to add functions to structs. Before I tried C++, I would
> bundle pointers to functions in my C-structs to fake some kind of
> OO-like bundling of similar functions ;)   C++ take this a major
> step further by actually bundling data and functions together
> in a struct. But that is what classes are in C++: just enhanced
> structs!

C++ actually does not bundle code with the structs. If a member function
is not virtual, the compiler will just binds a obj.foo() reference to its
obj::foo() counterpart.  On the other hand, if a member function is
virtual, then function pointers, like you mentioned above, are used. 
Anyway, just a minor detail; they're still just glorified structs. ;)

-Charles

-Charles Jolley
cjolley@oz.sunflower.org
-------------------------------
       HACS Design Group
 "...there is a better way..."
-------------------------------

Re: What is wrong with OO ?

[richard]

In <01bc0269$3fd55b20$ca61e426@DCorbit.solutionsiq.com>, "Dann Corbit" <dcorbit@solutionsiq.com> writes:

>I remember hearing similar arguments about PL/1 many years ago.  The line
>of reasoning went something like this, "It is such a complex language, that
>the average programmer can never become proficient in it."  This is, of
>course, pure bologna.  With an advanced language you can be proficient
>right away.  You don't **have** to use the advanced features.  Start with
>the simple things and work forward.  Classes, for instance, are simple. 
>There are some advanced features of classes like whether a member should be
>virtual or pure virtual to create an abstract class.  But you don't need to
>know that to learn the language and actively use it as a productive tool.

I doubt that a lot of people know everything about C++, even when they
have been using it for years. Most programmers don't use a lot of 
features of a language simply because they don't *need* them. What
is interesting for one leaves someone else totally cold.

>And as to why virtual/non-virtual (IMO):
>Something that is virtual can be replaced and/or shared.  If you need these
>capabilities, then make it virtual.  A pure virtual member will cause a
>class to be abstract.  This is valuable if you have a class that is really
>not able to exist as a useful entity until it has been specialized by a
>class that inherits from it (in other words, you don't want to create a
>stand-alone instance of the abstract class).
>

Virtual functions are also a kind of documentation. When declaring a 
function virtual, the programmer is more or less saying "go ahead,
override this function if you like."

Greetz,

RS

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Vassili Bykov]

Robert A Duff <bobduff@world.std.com> wrote in article
<E59AsK.5LC@world.std.com>...
> Control constructs *are* part of the standard library in Smalltalk.  And
> it's an elegant way to do things.  I'm not sure what you mean by "*in
> principle*" in this case.
> >(Unless you take Lisp or Scheme and consider macros as part of the
> >library--which, strictly speaking, they are not).
> No, they're not macros, they're "normal" messages/methods (that is,
> procedure calls), with "blocks" as parameters.  (I'm not sure why macros
> are considered out of bounds here, but in any case, macros aren't needed
> in this case.)

Sorry, but the post I replied to discussed Ada and C. Your Smalltalk points
are correct but Smalltalk is unique (again :-).  Unlike most other
"mainstream" languages it provides delayed evaluation ("blocks")--something
without which you *cannot* build control constructs for languages with
applicative-order evaluation, while unlike Scheme and CL's closures the
syntax of blocks is extremely brief. This is why you can build control
constructs as functions without the need for syntactic sugar for usability.

If you disagree with the first statement, try to write "while as a
function" in C or similar language. If you disagree with the second,
imagine a bare-bones Scheme-like system with only "lambda", "define" and
"if": it is *all* you need to have any control construct and write any
program, but it will be unreadable without syntactic abstraction a macro
system gives. (Macros are out of bounds because they extend the compiler,
not the program.)

--Vassili

Re: What is wrong with OO ?

[richard]

In <E3uK9F.CzG@research.att.com>, bs@research.att.com (Bjarne Stroustrup) writes:

>
>Why is any of this relevant now? Why do I bother with this debate on
>"innovation?" Because some of what is said related directly to what C++
>is and should be, and that again affects where it is reasonable to use
>it and how it is best used. If you misunderstand some of the fundamentals
>of a language, the code you write in it is going to be suboptimal in several
>ways.
>	

Well, who am I to judge.. but in my view C++ is basically C with the 
capability to add functions to structs. Before I tried C++, I would
bundle pointers to functions in my C-structs to fake some kind of
OO-like bundling of similar functions ;)   C++ take this a major
step further by actually bundling data and functions together
in a struct. But that is what classes are in C++: just enhanced
structs!

I find that many of the OO-capabilities of C++ are just "crammed in"
to overcome the static nature of the language. C++ is by far not 
elegant in this respect. I get the idea that a lot of features 
have been braught in on the fly ("hey, multiple inhertiance
would be neat. And while we're at it, let's try templates too").

That C++ still works as a OO-language is mostly due to the strengths of
the language C itself... it appears to still work even under the
weirdest circumstances. In that respect Stroustup made an excellent
chouce by using C as a base ;)

Greetz,

RS

Re: What is wrong with OO ?

[Nick Leaton]

richard@highrise.nl wrote:
> 
> Virtual functions are also a kind of documentation. When declaring a
> function virtual, the programmer is more or less saying "go ahead,
> override this function if you like."
> 

The decision to make a function virtual assumes a knowledge of what
users of your class are going to do. It akin to predicting the future.
One of the problems with C++ is this very point. Should you, as a
designer of a class restrict what someone else does with your class?
If you provide the class to someone else without source code, and they
find a bug. One solution to fixing the bug is to produce a new class
that inherits the original, and redefines the offending routine. However
your decision about declaring or not declaring the routine virtual in
the first place affects what can be done.

-- 

Nick

Re: What is wrong with OO ?

[Robert Dewar]

RS says

<<I doubt that a lot of people know everything about C++, even when they
have been using it for years. Most programmers don't use a lot of
features of a language simply because they don't *need* them. What
is interesting for one leaves someone else totally cold.>>

Indeed, and in practice it seems that a lot of "C++" programmers know
little more than the C subset with a very minimum of additional features.
However, I think this is probably best ascribed to ignorance rather than
careful consideration of what people find interesting!

Re: What is wrong with OO ?

[Vlastimil Adamovsky]

richard@highrise.nl wrote:

>................................. but in my view C++ is basically C with the 
>capability to add functions to structs. Before I tried C++, I would
>bundle pointers to functions in my C-structs to fake some kind of
>OO-like bundling of similar functions ;)   C++ take this a major
>step further by actually bundling data and functions together
>in a struct. But that is what classes are in C++: just enhanced
>structs!

Whow! Then you really don't need C++. Use C instead. 
There is nothing keeping you from using member functions in C structures.
It is completely legal.

>I find that many of the OO-capabilities of C++ are just "crammed in"
>to overcome the static nature of the language. C++ is by far not 
>elegant in this respect. I get the idea that a lot of features 
>have been braught in on the fly ("hey, multiple inhertiance
>would be neat. And while we're at it, let's try templates too").

Multiple inheritance is great. Templates are very useful in generic programming.

>That C++ still works as a OO-language is mostly due to the strengths of
>the language C itself... it appears to still work even under the
>weirdest circumstances. In that respect Stroustup made an excellent
>chouce by using C as a base ;)

It was a smart choice.











 Vlastimil Adamovsky
 ** C++ and Smalltalk consultant **
 * http://www.stepweb.com *

Re: Worse is better, was: Language marketing question

[Bob Haugen]

Piercarlo Grandi wrote:

> Richard Gabriel has written a classic "Worse is Better" paper on all
> this, which discusses some of the issues (even if I really disagree with
> some of the analysis and most importantly with the recommendations).

I recently read and am currently thinking about that same paper, and 
so would be interested in your disagreements.

Bob Haugen
Nexgen Software

Re: Worse is better, was: Language marketing question

[Donald M. MacQueen]

Bob Haugen wrote:
> 
> Piercarlo Grandi wrote:
> 
> > Richard Gabriel has written a classic "Worse is Better" paper on all
> > this, which discusses some of the issues (even if I really disagree with
> > some of the analysis and most importantly with the recommendations).
> 
> I recently read and am currently thinking about that same paper, and
> so would be interested in your disagreements.
> 
> Bob Haugen
> Nexgen Software




Is this paper available on the Web?

I'd like to read it too.

Thanks in advance.



Donald

Re: What is wrong with OO ?

[Robert Dewar]

Charles said

<<C++ actually does not bundle code with the structs. If a member function
is not virtual, the compiler will just binds a obj.foo() reference to its
obj::foo() counterpart.  On the other hand, if a member function is
virtual, then function pointers, like you mentioned above, are used.
Anyway, just a minor detail; they're still just glorified structs. ;)>>

YOu should better say "typical C++ implementations" rather than C++, I see
nothing in the draft standard that would support your claim that this is
implied by the language definition.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Vassili Bykov]

Fergus Henderson <fjh@murlibobo.cs.mu.OZ.AU> wrote:
> ...   On the
> other hand, it's not possible to do the equivalent for Pascal's
> write statement or for C's for loops, because these are part of
> the language proper, not the standard library.

Of course it's not possible.  So we came to what it started with: it is in
principle impossible to have, for example, "for" loop in the standard
library instead of the language proper in a C/Pascal/Ada/Java-like language
even if it were up to us to move it there, because these languages lack the
necessary expressive facilities.  It is possible in Smalltalk, CL, or
Scheme--even Tcl weird as it is.
[But I'm not going into a second round on that, SICP explains it all]

Re: Worse is better, was: Language marketing question

[Lee Willis]

Donald M. MacQueen wrote:
> Bob Haugen wrote:
> > Piercarlo Grandi wrote:
> > > Richard Gabriel has written a classic "Worse is Better" paper on all
> > > this, which discusses some of the issues (even if I really disagree with
> > > some of the analysis and most importantly with the recommendations).

> Is this paper available on the Web?

http://rembrandt.erols.com/mon/SoftwareEngineering/WorseIsBetter.html

-- 
Lee Willis	MultiGen Inc. 550 S Winchester Blvd. Suite 500
		San Jose, CA 95128 		(408) 261-4100
"Sure, everyone knows [software] reusability is wonderful for the 
consumer side of the reuse transaction.  But what makes it wonderful 
for the producers?"  -- Brad Cox, _Superdistribution_

Re: What is wrong with OO ?

[Ell]

Nick Leaton (nickle@calfp.co.uk) wrote:
: richard@highrise.nl wrote:
: > 
: > Virtual functions are also a kind of documentation. When declaring a
: > function virtual, the programmer is more or less saying "go ahead,
: > override this function if you like."
: > 
 
: The decision to make a function virtual assumes a knowledge of what
: users of your class are going to do. It akin to predicting the future.
: One of the problems with C++ is this very point. Should you, as a
: designer of a class restrict what someone else does with your class?

How does making inherited classes able to override a parent function
"restrict"ing "what someone else does with" that class"?

Elliott

Re: What is wrong with OO ?

[Matt McClellan]

Ell wrote:
> 
> Nick Leaton (nickle@calfp.co.uk) wrote:
> : richard@highrise.nl wrote:
> : >
> : > Virtual functions are also a kind of documentation. When declaring a
> : > function virtual, the programmer is more or less saying "go ahead,
> : > override this function if you like."
> : >
> 
> : The decision to make a function virtual assumes a knowledge of what
> : users of your class are going to do. It akin to predicting the future.
> : One of the problems with C++ is this very point. Should you, as a
> : designer of a class restrict what someone else does with your class?
> 
> How does making inherited classes able to override a parent function
> "restrict"ing "what someone else does with" that class"?
> 
> Elliott

You aren't restricting what someone does with the class, *if* you make it 
virtual.  Not doing so prevents someone from overriding the function in a 
child class, which is restrictive.

Matt
--
The above are most certainly my opinions, and not necessarily those of my 
employeer, Raytheon E-Systems 
 _____  __
|  ___|/__|  Matt McClellan                  | Raytheon E-Systems
| |____/__|  mmcclellan@fallschurch.esys.com | Falls Church Div.
| |____/__|  Ph:  703.560.5000 x2980         | 7700 Arlington Blvd.
|______/     Fax: 703.849.1674               | Falls Church, VA 22046

Re: What is wrong with OO ?

[John Brady]

Ell <ell@access5.digex.net> wrote in article
<5dopri$dei@news4.digex.net>...
> Nick Leaton (nickle@calfp.co.uk) wrote:
> : richard@highrise.nl wrote:
> : > 
> : > Virtual functions are also a kind of documentation. When declaring a
> : > function virtual, the programmer is more or less saying "go ahead,
> : > override this function if you like."
> : > 
>  
> : The decision to make a function virtual assumes a knowledge of what
> : users of your class are going to do. It akin to predicting the future.
> : One of the problems with C++ is this very point. Should you, as a
> : designer of a class restrict what someone else does with your class?
> 
> How does making inherited classes able to override a parent function
> "restrict"ing "what someone else does with" that class"?
> 

I think the point he is making is that if you DON'T make the function
virtual, then other programmers CAN'T override it.  Therefore, C++
programmers are forced to commit early to making a class overrideable or
not.  (I program in Delphi, and the same problem arises).  The C++
critique, at http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3, goes into
this point in some depth.


-- 
John Brady
john.brady@gecmf.capital.ge.com

Re: C++ Class

[William Ying]

Loc Minh Phan Van wrote:
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.

Two solutions:
1)	Make the base class as Abstract Base Class (or Absolute Base Class in
some books) by setting a virtual function to be zero.  It is well
documented in any C++ books.
2)	Put the base class constructors in protected field.

- Bill -

Re: C++ Class

[Aaron J Margosis]

Make it an abstract class, using pure virtual functions.


Loc Minh Phan Van wrote:
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.

-- Aaron

---------------------------------
Aaron J Margosis
Work e-mail:  margosis@lccinc.com
Work phone:  703-516-6727
Personal:  Aaron_Margosis@compuserve.com

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "jsarkela" == John W Sarkela <jsarkela@enfish.com> writes:

[ ... much omitted ... ]

jsarkela> My experience suggests that my designs have higher degrees of
jsarkela> reusability if I do indeed consider that objects may express
jsarkela> free will. You may consider this fuzzy thinking, yet I tend to
jsarkela> create more concise collaborations with better factoring of
jsarkela> responsibility if I do think of my objects as expressing an
jsarkela> individual will and as a locus of responsibility.

Well, ain't you lucky? :-)

[ ... much omitted ... ]

Re: C++ Class

[Ron Smith]

Please watch your crossposting.  I don't know why this is in any of the
newsgroups except comp.lang.c++.

I didn't bring my asbesteos underwear so please don't flame me for
pointing this out.

Loc Minh Phan Van wrote:
> 
> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

Re: C++ Class

[John Kapson [C]]

In article <33018394.1718@scf.usc.edu>, Loc Minh Phan Van <locphan@scf.usc.edu> writes:
> Hi,
> 	Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class. 
> 
> 	If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

Shame, shame, shame.  If you want me to do your homework,
you'll have to pay my hourly rate.  8-)

John

Re: C++ Class

[Vlastimil Adamovsky]

Keith P. Boruff wrote:
> 
> Loc Minh Phan Van wrote:
> >
> > Hi,
> >         Is there anyway that we can Define a class that can not be instantiated
> > in any way by the user (that is, you can not have objects of that type),
> > but it can be used as a base class.
> >
> 
> Read about polymorphism and virtual functions.
> 

Read about "Abstract classes" and pure virtual functions.

Vlastimil Adamovsky


       The contents of this message express only the sender's opinion.
       This message does not necessarily reflect the policy or views of
       my employer, Merck & Co., Inc.  All responsibility for the statements
       made in this Usenet posting resides solely and completely with the
       sender.

Re: C++ Class

[Jason Shankel]

Loc Minh Phan Van wrote:
> 
> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

In C++, you're talking about an abstract base class.
An abstract class in C++ is a class which has at least one
pure virtual function, which must be overridden by a child class.
Pure virtual functions are designated by the "=0" idiom.
Abstract base classes cannot be instantiated:


class IFoo
{
	public:
		virtual void Method() = 0; //Pure virtual function
};

class CFoo : public IFoo
{
	public:
		virtual void Method(){}; //Overridden
};

void main()
{
	IFoo *object;

	object = new IFoo(); //ERROR, cannot instantiate abstract class
	object = new CFoo(); //Legal
};

C++ Class

[Loc Minh Phan Van]

Hi,
	Is there anyway that we can Define a class that can not be instantiated
in any way by the user (that is, you can not have objects of that type),
but it can be used as a base class. 

	If so please give me a little example.

Thanks

Fr, Loc Phan

Re: C++ Class

[Keith P. Boruff]

Loc Minh Phan Van wrote:
> 
> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

Read about polymorphism and virtual functions. 
 
--------------------------------------------------------
Keith P. Boruff			Email:
West Babylon			kboruff@village.ios.com
Long Island, NY			boruffk@sunysuffolk.edu

Re: C++ Class

[Kevin J. Hopps]

Loc Minh Phan Van wrote:
> 
> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

If a class has a "pure virtual function" it cannot be instantiated
directly, but only as a base class of a derivative that implements the
function.  For example:

class Cloneable
{
public:
	virtual Cloneable* clone() = 0;
};

class Thing : public Cloneable
{
public:
	virtual Thing* clone();
};

int main()
{
	Cloneable c;	// error
	Thing t;	// ok
	return 0;
}
-- 
Kevin J. Hopps, Imation          kjhopps@imation.com

My opinions are my own.  I speak neither for Imation nor 3M.



Opinions expressed herein are my own and may not represent those of my employer.

Re: C++ Class

[Kent Tong]

Loc Minh Phan Van <locphan@scf.usc.edu> wrote:

>Hi,
>	Is there anyway that we can Define a class that can not be instantiated
>in any way by the user (that is, you can not have objects of that type),
>but it can be used as a base class. 
>
>	If so please give me a little example.

deferred class Foo
feature
   IWillNeverCrossPostAgain 
   is 
      deferred 
   end;   


---
Kent Tong
v3 is out!!!
Freeman Installer ==> http://www.netnet.net/users/freeman/

Re: C++ Class

[Paul Kenneth Egell-Johnsen]

Loc Minh Phan Van wrote:

> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.

That would be an abstract base class, with pure virtual members.

class base
{
	virtual method() = 0; // this is not defined in the base,
                              // derived objects must define this.
                              // Don't think a user can instanciate
                              // this, take a look in the faq.
}

Paul K Egell-Johnsen

mailto:paulken4@afrodite.hibu.no
http://afrodite.hibu.no:8001/paulken4/

Re: What is wrong with OO ?

[David B. Shapcott [C]]

In article <JSA.97Feb11200125@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:
>[...] If you decide
>you need a new "friend" you have to go back and _change_ the source
>(which you may not even have accesss to!)

But you do have access to the `part' of the source you need: the header file,
where friendship declarations are made.  Friendship has no runtime implications
and so classes do not need to be recompiled.  (Virtual fns, on the other hand,
do have runtime implications, and polymorphism cannot be changed without
recompilation.  Code linked with different polymorhism models would likely
die or at least behave unpredictably the first time it tried to call through
the vtable).

C++ access control occurs at compile-time, and is therefore easily defeated.
It's certainly not good practise, however.



-- 
D. Brad Shapcott [C] Contractor, Motorola Cellular Infrastructure Group

"Theory changes the reality it describes."

Re: What is wrong with OO ?

[Jon S Anthony]

In article <5dopri$dei@news4.digex.net> ell@access5.digex.net (Ell) writes:

> Nick Leaton (nickle@calfp.co.uk) wrote:
> : richard@highrise.nl wrote:
> : > 
> : > Virtual functions are also a kind of documentation. When declaring a
> : > function virtual, the programmer is more or less saying "go ahead,
> : > override this function if you like."
> : > 
>  
> : The decision to make a function virtual assumes a knowledge of what
> : users of your class are going to do. It akin to predicting the future.
> : One of the problems with C++ is this very point. Should you, as a
> : designer of a class restrict what someone else does with your class?
> 
> How does making inherited classes able to override a parent function
> "restrict"ing "what someone else does with" that class"?

This seems really confused.  How are the _inherited_ classes
overriding a _parent's_ function?  I suppose you meant subclasses.
Anyway, you got it backwards.  The point is that if you don't make the
things virtual, you can't do the overrides (and other attendant
stuff).  So, there is this problem of either making everything
virtual, and possibly providing misleading, inappropriate or possibly
simply inefficient aspects, or not and then risking the mentioned
problems.

Nick is correct here.  This is a problem in C++ (along with
friendship) as it requires prescience on the part of the developer
and/or various maintenance problems: if you later decide it should be
virtual, you have to go back and _change_ the source of the parent
thereby changing the semantics in various other places.  If you decide
you need a new "friend" you have to go back and _change_ the source
(which you may not even have accesss to!)

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Hamilton, Robert Bryan]

On Wed, 12 Feb 1997 01:01:25 GMT, Jon S Anthony <jsa@alexandria> wrote:
>This seems really confused.  How are the _inherited_ classes
>overriding a _parent's_ function?  I suppose you meant subclasses.
>Anyway, you got it backwards.  The point is that if you don't make the
>things virtual, you can't do the overrides (and other attendant
>stuff).  

??? You can override any method in C++, virtual or no.
The difference is that virtual function _must_ be overridden if
you plan to use it.  

The _real_ point is that you have access to a virtual method even if
the object is referenced by a pointer cast to its parent/higher
class. This can be of great advantage to routines taking a reference
to the parent class as an argument.

>So, there is this problem of either making everything
>virtual, and possibly providing misleading, inappropriate or possibly
>simply inefficient aspects, or not and then risking the mentioned
>problems.

This is no problem unless one makes it one through bad practice.
Just don't use virtual functions _unless_ doing so enhances the clarity
of the program!  Otherwise there's no point to it.

Regards, Robert.

Re: What is wrong with OO ?

[Ketil Z Malde]

jsa@alexandria (Jon S Anthony) writes:

> Nick is correct here.  This is a problem in C++ (along with
> friendship) as it requires prescience on the part of the developer
> and/or various maintenance problems: if you later decide it should be
> virtual, you have to go back and _change_ the source of the parent
> thereby changing the semantics in various other places.  If you decide
> you need a new "friend" you have to go back and _change_ the source
> (which you may not even have accesss to!)

Yes, I agree, the developer of a class needs to think about how the
class is going to be used in the future.  Usually, I don't think this is
a great problem.

E.g. if you wish to provide an interface only, you go with a virtual
abstract method, if you wish to provide interface with a default (but
not absolute) implementation, you go with virtual, and if you want to
provide both interface and implementation (which usually means that the
method is closely tied to the attributes of the (base) class) you submit
a plain non-virtual method.  Simple!

Should the default case therefore be ``virtual''?

There is of course also an issue with MI, but we'll look at that next
period.  :-)

~kzm
-- 
If I haven't seen further, it is by standing in the footprints of giants

Re: What is wrong with OO ?

[Kevin J. Hopps]

Jon S Anthony wrote:
> 
> In article <5dopri$dei@news4.digex.net> ell@access5.digex.net (Ell) writes:
> 
> > Nick Leaton (nickle@calfp.co.uk) wrote:
> > : richard@highrise.nl wrote:
> > : >
> > : > Virtual functions are also a kind of documentation. When declaring a
> > : > function virtual, the programmer is more or less saying "go ahead,
> > : > override this function if you like."
> > : >
> >
> > : The decision to make a function virtual assumes a knowledge of what
> > : users of your class are going to do. It akin to predicting the future.
> > : One of the problems with C++ is this very point. Should you, as a
> > : designer of a class restrict what someone else does with your class?
> >
> > How does making inherited classes able to override a parent function
> > "restrict"ing "what someone else does with" that class"?
> 
> This seems really confused.  How are the _inherited_ classes
> overriding a _parent's_ function?  I suppose you meant subclasses.
> Anyway, you got it backwards.  The point is that if you don't make the
> things virtual, you can't do the overrides (and other attendant
> stuff).  So, there is this problem of either making everything
> virtual, and possibly providing misleading, inappropriate or possibly
> simply inefficient aspects, or not and then risking the mentioned
> problems.
> 
> Nick is correct here.  This is a problem in C++ (along with
> friendship) as it requires prescience on the part of the developer
> and/or various maintenance problems: if you later decide it should be
> virtual, you have to go back and _change_ the source of the parent
> thereby changing the semantics in various other places.  If you decide
> you need a new "friend" you have to go back and _change_ the source
> (which you may not even have accesss to!)

This problem is one which arises naturally in any OO design.  For any
class operation, the author of that class must make decisions about its
semantics, and trust that subclasses adhere to those semantics. 
Regardless of the language used, there are times when the author may
wish certain operations to remain fixed, while allowing others to be
modified by a subclass.  (Example folows.)

If you later decide the semantics should be changed (i.e. the fixed
operation should not be fixed), the semantics have changed.  And
changing semantics has a tendency to break things, even if you don't
need to modify any code.  For example, code may exist which depends upon
the operation being fixed, and allowing a new class to alter the
previously fixed behavior violates an assumption previously made.

In languages that do not provide a choice between making functions
overridable, documentation may be the only mechanism for making this
distinction.  C++ gives the author a way to state this explicitly so
that the compiler can enforce it.  This makes possible, in many cases,
for the comiler to detect problems that occur when semantic changes are
made.
-- 
Kevin J. Hopps, Imation          kjhopps@imation.com

My opinions are my own.  I speak neither for Imation nor 3M.



Opinions expressed herein are my own and may not represent those of my employer.

Re: What is wrong with OO ?

[Russ McClelland]

> : The decision to make a function virtual assumes a knowledge of what
> : users of your class are going to do. It akin to predicting the future.
> : One of the problems with C++ is this very point. Should you, as a
> : designer of a class restrict what someone else does with your class?
> 
> How does making inherited classes able to override a parent function
> "restrict"ing "what someone else does with" that class"?
> 
> Elliott

It doesn't and that is not what he's pointing out.  Here's what he's
saying:

To override a parents method, that method must be declared as virtual.  If
it isn't declared as virtual, you can never get polymorphic behavior for
that method.  The reason this could potentially cause problems is that
this:  As the designer of a class, I don't always know how subclasses will
be created and used, ie.  I don't know which methods to make virtual.  What
if someone wants to override a method that I didn't declare virtual?

-- 
Persistence is futile.
You will be aggregated...

Re: What is wrong with OO ?

[Bob Jarvis]

Ell <ell@access5.digex.net> wrote in article <5dopri$dei@news4.digex.net>...
> Nick Leaton (nickle@calfp.co.uk) wrote:
> : richard@highrise.nl wrote:
> : > 
> : > Virtual functions are also a kind of documentation. When declaring a
> : > function virtual, the programmer is more or less saying "go ahead,
> : > override this function if you like."
> : > 
>  
> : The decision to make a function virtual assumes a knowledge of what
> : users of your class are going to do. It akin to predicting the future.
> : One of the problems with C++ is this very point. Should you, as a
> : designer of a class restrict what someone else does with your class?
> 
> How does making inherited classes able to override a parent function
> "restrict"ing "what someone else does with" that class"?

It's true that in C++ you can override a non-virtual base class member function in
a derived class, and that this will work as intended as long as you are referring to the
derived class instance through a reference or pointer to the derived type.  However,
if you're referring to the derived class instance through a base class reference or 
pointer you will invoke the base class version of all non-virtual functions.  For example

	class A {
	     public:
		int a_func(void);
		};

	class B : public A
		{
	     public:
		int a_func(void);
		}

	...

	A::a_func(void) { printf("A::a_func\n"); }
	B::a_func(void) { printf("B::a_func\n"); }

	...

	B b_instance;
	A *a_pointer;

	a_pointer = &b_instance;

	b_instance.a_func();
	a_pointer->a_func();

In this case the output you should receive would be

	B::a_func
	A::a_func

This is a limitation on the possible use of classes derived from A.
a_func is not declared virtual in the base class and thus overrides of
a_func in derived classes will not resolve properly when derived class
instances are referred to through base class references or pointers.
In this case the designer of the original class should have made a_func
virtual but failed to do so, thus limiting how the class can be used later.
This might be intentional, but in the real-world cases I've seen it's usually
been the case that the eventual needs of re-users of the base class were
not considered by the original class designer.
-- 
Bob Jarvis
Mail addresses hacked to foil automailers!
Send replies to jarvisb@timken.com

Re: C++ Class

[Lee, Shih Hao]

Loc Minh Phan Van <locphan@scf.usc.edu> wrote in article
<33018394.1718@scf.usc.edu>...
> Hi,
> 	Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class. 
> 

Declare the constructor of that class to be protected.

class B {
protected:
	B() { /*...*/}
};

class D : public B {
public:
	D() : B() { /*...*/}
};

main()
{
	D d;		// OK!
	B b;		// Error!
}

tony
-- 
class Signature { static char *name, *belief, *URL, *eMail; };
char *Signature::name = "Lee, Shih Hao (Anthony Lee)";
char *Signature::belief = "Long live of Borland C++/OWL";
char *Signature::URL = "http://necta.nec.com.tw/~tony";
char *Signature::eMail = "mailto:tony@necta.nec.com.tw";

Re: language marketing question, was Re: What is wrong with OO ?

[Robert Dewar]

John said

<<Hmm.  Its more likely that the majority of people who do doctorates stay in
academia, rather than joining the corporate rat-race.  The latter offers
better money.>>

Why guess at something like this and, not surprisingly guess wrong. It is
certainly NOT the case that the majority of people who do doctorates stay
in academia!

Re: What is wrong with OO ?

[Jon S Anthony]

In article <slrn5g1u19.g3mged.FEYNMAN@VMS1.TAMU.EDU> FEYNMAN@acs.tamu.edu (Hamilton, Robert Bryan       ) writes:

> On Wed, 12 Feb 1997 01:01:25 GMT, Jon S Anthony <jsa@alexandria> wrote:
> >This seems really confused.  How are the _inherited_ classes
> >overriding a _parent's_ function?  I suppose you meant subclasses.
> >Anyway, you got it backwards.  The point is that if you don't make the
> >things virtual, you can't do the overrides (and other attendant
> >stuff).  
> 
> ??? You can override any method in C++, virtual or no.
> The difference is that virtual function _must_ be overridden if
> you plan to use it.  

No, we're not talking "override" as in "overloading" or "hiding".  The
context _is_ the case of overriding dispatchable methods.


> The _real_ point is that you have access to a virtual method even if

Actually, given the context, this is irrelevant.


> >So, there is this problem of either making everything
> >virtual, and possibly providing misleading, inappropriate or possibly
> >simply inefficient aspects, or not and then risking the mentioned
> >problems.
> 
> This is no problem unless one makes it one through bad practice.
> Just don't use virtual functions _unless_ doing so enhances the clarity
> of the program!  Otherwise there's no point to it.

You've completely missed the point of the whole discussion...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Jon S Anthony]

In article <KETIL-ytq20ammnxd.fsf@imr.no> Ketil Z Malde <ketil@imr.no> writes:

> jsa@alexandria (Jon S Anthony) writes:
> 
> > Nick is correct here.  This is a problem in C++ (along with
> > friendship) as it requires prescience on the part of the developer
> > and/or various maintenance problems: if you later decide it should be
> > virtual, you have to go back and _change_ the source of the parent
> > thereby changing the semantics in various other places.  If you decide
> > you need a new "friend" you have to go back and _change_ the source
> > (which you may not even have accesss to!)
> 
> Yes, I agree, the developer of a class needs to think about how the
> class is going to be used in the future.  Usually, I don't think this is
> a great problem.

Fair enough.  How bad this is is going to be relative to a lot of
other things (is it a library class?, does it define a well known and
understood thing which is not likely to change, ...)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Hamilton, Robert Bryan]

On Thu, 13 Feb 1997 01:06:58 GMT, Jon S Anthony <jsa@alexandria> wrote:
>In article <slrn5g1u19.g3mged.FEYNMAN@VMS1.TAMU.EDU> FEYNMAN@acs.tamu.edu (Hamil
> ton, Robert Bryan       ) writes:
>
>> ??? You can override any method in C++, virtual or no.

>No, we're not talking "override" as in "overloading" or "hiding".  The
>context _is_ the case of overriding dispatchable methods.
>
>> The _real_ point is that you have access to a virtual method even if
>
>Actually, given the context, this is irrelevant.

Sorry, I was describing the very real intent of virtual methods in C++,
and not the real point of the "context", which I apparantly missed
entirely.

>
>You've completely missed the point of the whole discussion...
>

Probably so, since I came in late. Should have realized that there must
be a broader context seeing the cross-posting to eiffel and back.
I'm going to bow out.  A context which spans this many groups is way
beyond me.

Regards, Robert

Re: What is wrong with OO ?

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <01bc183a$831b3760$1544db03@gecmf-pc-eddjab.gecmf.capital.ge.com> "John Brady" <john.brady@gecmf.capital.ge.com> writes:

   Ell <ell@access5.digex.net> wrote in article
   <5dopri$dei@news4.digex.net>...
   > Nick Leaton (nickle@calfp.co.uk) wrote:
   > : richard@highrise.nl wrote:
   > : > 
   > : > Virtual functions are also a kind of documentation. When declaring a
   > : > function virtual, the programmer is more or less saying "go ahead,
   > : > override this function if you like."
   > : > 
   >  
   > : The decision to make a function virtual assumes a knowledge of what
   > : users of your class are going to do. It akin to predicting the future.
   > : One of the problems with C++ is this very point. Should you, as a
   > : designer of a class restrict what someone else does with your class?
   > 
   > How does making inherited classes able to override a parent function
   > "restrict"ing "what someone else does with" that class"?
   > 

   I think the point he is making is that if you DON'T make the function
   virtual, then other programmers CAN'T override it.  Therefore, C++

This is patently wrong. You can override it as much as you like
whether the function is virtual or not. What you don't get if it's not
defined to be virtual in the base class is run time dispatching.
If the function is not virtual, and you have a pointer to the base
class which is actually pointing to an object of the derived class,
the function of the *base* class will be called. If the function is
defined as virtual in the base class, the actual object being pointed
to will decide which method will be called. 

   programmers are forced to commit early to making a class overrideable or
   not.  (I program in Delphi, and the same problem arises).  The C++
   critique, at http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3, goes into
   this point in some depth.


   -- 
   John Brady
   john.brady@gecmf.capital.ge.com

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "cjolley" == Charles A Jolley <cjolley@oz.sunflower.org> writes:

>> Well, who am I to judge.. but in my view C++ is basically C with the 
>> capability to add functions to structs. Before I tried C++, I would
>> bundle pointers to functions in my C-structs to fake some kind of
>> OO-like bundling of similar functions ;)   C++ take this a major
>> step further by actually bundling data and functions together
>> in a struct. But that is what classes are in C++: just enhanced
>> structs!

cjolley> C++ actually does not bundle code with the structs. If a member
cjolley> function is not virtual, the compiler will just binds a
cjolley> obj.foo() reference to its obj::foo() counterpart.  On the
cjolley> other hand, if a member function is virtual, then function
cjolley> pointers, like you mentioned above, are used.  Anyway, just a
cjolley> minor detail; they're still just glorified structs. ;)

But this is an implementation detail, and even in the implementation
vtables of function pointers are not part of any instance of any
'struct'.

In ``C++'' in no way data and functions are bundled together; the only
bundling is of function declarations/definitions with data
declarations/definitions. There is an immense amount of difference
between:

  struct complex
  {
    float re,im;
    struct complex (*add)(struct complex,struct complex);
    ....
  };

  struct complex c = { .... };
  c = (*c.add)(c,c);

which is reminiscent of prototype systems and:

  class complex
  {
    float re,im;
  public:
    complex add(complex);
    ....
  };

  complex complex::add(complex b) { ... };

  complex c(....);
  c = c.add(c);

which isn't.

The difference is that in ``C++'' a 'class'/'struct' definition also
doubles up as a module, which contains the definition of a single
'struct' and of a bunch of related functions. In fact a ``C++'' 'class'
can be used as a mere module if it does not contains any data member
definitions. The above ``C++'' example should really be read as:

  class complex
  {
    struct complex { float re,im; };
  public:
    complex add(complex,complex);
    ....
  };

  complex::complex complex::add(complex::complex a,b) { ... };

  complex::complex c(....);
  c = complex::add(c,c);

If ``C++'' were based on the latter syntax scheme, admittedly more
verbose, fewer people would get the wrong impression that there is
anything magic/special about the affix syntax and the other syntactic
shortcuts. Too bad.

Naturally the same observation applies to the other languages with
similar syntax, like ``Smalltalk'' and ``Eiffel''; in all of these the
affix syntax and the syntactic conflation of the type definition with
that of the module can result in confusion, which is made worse in the
case of ``Smalltalk'' by the use of actor-like terms... In Ada 95 the
more verbose but clearer syntax is required, but then the compiler is
not requried to support or enforce the OO paradigm, and allows more than
one type definition in a module regardless (also in ``C++'', but only if
one uses the more verbose syntax).

Re: What is wrong with OO ?

[Jon S Anthony]

In article <5dtc5n$554@trotsky.cig.mot.com> shapcott@wallaby.cig.mot.com (David B. Shapcott [C]) writes:

> In article <JSA.97Feb11200125@alexandria>,
> Jon S Anthony <jsa@alexandria> wrote:
> >[...] If you decide
> >you need a new "friend" you have to go back and _change_ the source
> >(which you may not even have accesss to!)
> 
> But you do have access to the `part' of the source you need: the
> header file, where friendship declarations are made.  Friendship has
> no runtime implications and so classes do not need to be recompiled.

First, it may not be in a header file (of course that may be poor
design, but...)  Second, the point is you have to change existing
source in order to effect friendship, i.e., you are changing source to
effect something _outside the context_ of what that source represents.
That's always a dodgy thing to do.


> (Virtual fns, on the other hand, do have runtime implications, and
> polymorphism cannot be changed without recompilation.  Code linked
> with different polymorhism models would likely die or at least
> behave unpredictably the first time it tried to call through the
> vtable).

Agreed.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Jon S Anthony]

In article <33049C7C.41C6@wi.leidenuniv.nl> Bart Samwel <bsamwel@wi.leidenuniv.nl> writes:

[various points about why C++ "virtual" tagging is "upside down"]

> by renaming one of the functions. When you make it the default that
> overridden functions are dynamically bound ('virtual') and that
> non-overridden functions are statically bound, you don't have to
> bother the programmer with 'virtual' keywords at all - in this
> situation, the keyword becomes obsolete.

You can do better than this.  Let the choice between static binding to
the specific type vs dynamic binding to the runtime type be determined
by the user (client) at the point of invocation.  This makes runtime
polymorphism a local thing instead of a global thing.  Which helps in
future maintenance and is somewhat more flexible.  In particular, the
class designer does not have to worry about making the "wrong choice"
up front.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Sam Inala]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.855671030@merv>...
> Charles said
> <<C++ actually does not bundle code with the structs. If a member
function
> is not virtual, the compiler will just binds a obj.foo() reference to its
> obj::foo() counterpart.  On the other hand, if a member function is
> virtual, then function pointers, like you mentioned above, are used.
> Anyway, just a minor detail; they're still just glorified structs. ;)>>
> 
> YOu should better say "typical C++ implementations" rather than C++, I
see
> nothing in the draft standard that would support your claim that this is
> implied by the language definition.

Just for clarification: even typical C++ implementations differ from
structs
containing function pointers. Consider the following:

#include <stdio.h>

struct One {
   int x;
};

struct Two {
   int x;
   void foo() {}
};

struct Three {
   int x;
   virtual void foo() {}
};

struct Four {
   int x;
   virtual void foo() {}
   virtual void bar() {}
};

int
main() {
   printf( "sizes = %d %d %d %d\n", sizeof( One ), sizeof( Two ),
	sizeof( Three ), sizeof( Four ) );
   return 0;
}

Output from gcc:
sizes = 4 4 8 8

With an implementation of class Four like this:

struct Four {
	int x;
	void (*foo)();
	void (*bar)();
};

...we would expect the sizeof( Four ) to be 12. Instead, it most
likely contains a single pointer to a table of function pointers,
which are shared by all the instances of the class:

struct Four {
	void* vtbl;
	int x;
};

<return type> (*Four::function[ cMethods ])(...);

I only mention this because I perceive people thinking
that object instances carry around their own virtual 
function tables.

Re: What is wrong with OO ?

[Robert Dewar]

Sam said

<<...we would expect the sizeof( Four ) to be 12. Instead, it most
likely contains a single pointer to a table of function pointers,
which are shared by all the instances of the class:>>

I don't know who "we" is here, but I can't see anyone expecting this,
your "instead" is the obvious implementation, and it would surprise
me (though certainly not be invalid) if a C++ implementation did
anything else!

Re: What is wrong with OO ?

[Kevin J. Hopps]

Bart Samwel wrote:

> C++ does not have a 'final' keyword, so there is no way of checking that
> functions will not be overridden. Omitting 'virtual' just means that a
> function will not be dynamically bound. You can override non-virtual
> functions, and that usually leads to very unpleasant surprises, like
> mixed
> use of the overridden and overriding functions on the same object.
> 
> The C++ designer's choice of making 'virtual' explicit and 'final'
> implicit
> (read: not implemented) does not seem wise to me.
> 
> The C++ use of 'virtual' is because static binding is the default for
> all
> functions, including functions that are redefined in descendants. But
> there are almost no situations where you want to use static binding for
> redefined
> functions, and when you do find such a situation, you can solve the
> problem
> by renaming one of the functions. When you make it the default that
> overridden functions are dynamically bound ('virtual') and that
> non-overridden functions are statically bound, you don't have to bother
> the
> programmer with 'virtual' keywords at all - in this situation, the
> keyword
> becomes obsolete.

Whether a function is statically or dynamically bound must be known at
compile time.  How could a compiler know whether there was somewhere
some module that defined a derived class that overrides a given
function?

In C++ I have a choice of making functions dynamically bound or not. 
Whether I exercise this choice by "saying virtual" or by "not saying
final" really doesn't matter to me much (except then I'd have to say
"final" on all constructors, which seems like unnecessary typing).

The only real difference in the two mechanisms (if I understand how
"final" works) is that the absence of "virtual" does not prevent the
overriding of a function in a derived class.  This is a feature I might
use if I had it available to me.



Opinions expressed herein are my own and may not represent those of my employer.

Re: What is wrong with OO ?

[phil]

Pardon me for jumping in but, 

Kevin J. Hopps <kjhopps@mmm.com> wrote in article
<33088196.68A0@mmm.com>...
> 
	[previous discussion of virtual versus final deleted]

> In C++ I have a choice of making functions dynamically bound or not. 
> Whether I exercise this choice by "saying virtual" or by "not saying
> final" really doesn't matter to me much (except then I'd have to say
> "final" on all constructors, which seems like unnecessary typing).
>

Actually, the "final" keyword can be applied to classes, member data,
and methods (member functions).  Instead of having to say "final" on
all constructors, as you suggest above which would be laborious, you
can specify that the class itself is final and therefore you cannot
derive a class from it.  But, you can also mark a constructor as 
"final" too which might be useful in a slightly different way.

Just for your information, if you were not aware of it, "final" applied
to member data is the method of creating constants.  It is one of the
over-loaded uses of the word "final" in Java that I do not agree with.
 
> The only real difference in the two mechanisms (if I understand how
> "final" works) is that the absence of "virtual" does not prevent the
> overriding of a function in a derived class.  This is a feature I might
> use if I had it available to me.
>

As a long time C++ programmer who now also programs in Java, I prefer the
"final" method but I do not use it to somehow provide efficiency in
function calling (after all, I think all method calls in Java use a
dispatch table, aka vtbl, whether they are "final" or not).  I prefer
final as a means of achieving a "tighter" design over my classes.  That
is, once behaviour has been established for a particular class, I use
"final" to freeze the behaviour.

The ability in C++ to "hide" a base class function by "overloading" the
signature without using the virtual keyword is indeed more of a flaw
than a feature in my opinion.  I have programmed in C++ for about 9
years and most of the time that I have seen this overloading type of
hiding, it has been a mistake rather than an intent of design.
 
Well, just my 2-bits...isn't dialoging on opinions fun..

    phil

Re: What is wrong with OO ?

[Simon Willcocks]

In article <3301D875.188B@mmm.com>, kjhopps@mmm.com (Kevin J. Hopps) says:

>Jon S Anthony wrote:
>> [...]

>> Nick is correct here.  This is a problem in C++ (along with
>> friendship) as it requires prescience on the part of the developer
>> and/or various maintenance problems: if you later decide it should be
>> virtual, you have to go back and _change_ the source of the parent
>> thereby changing the semantics in various other places.  If you decide
>> you need a new "friend" you have to go back and _change_ the source
>> (which you may not even have accesss to!)
>
>This problem is one which arises naturally in any OO design.  For any
>class operation, the author of that class must make decisions about its
>semantics, and trust that subclasses adhere to those semantics. 

In Eiffel the semantics of a method are defined by its pre- and post-
conditions, and the class invariant.  All subclasses _have_ to comply
with those semantics, otherwise runtime checks will fail.  There is no
"trust" required, at least not until the checks are turned off.

Additionally, the authors of a subclass have a much easier time because it
is made clear what the original class' author had in mind when defining
the interface to the class.

Simon

Re: What is wrong with OO ?

[Nick Leaton]

> Nick Leaton wrote:
> >
> > richard@highrise.nl wrote:
> > >
> > > Virtual functions are also a kind of documentation. When declaring a
> > > function virtual, the programmer is more or less saying "go ahead,
> > > override this function if you like."
> >
> > The decision to make a function virtual assumes a knowledge of what
> > users of your class are going to do. It akin to predicting the future.
> 
> No. If it make sense to override, make it virtual; if it doesn't,
> don't make it virtual.

I think you might have missed the start of the thread. If you buy third
party libraries, you don't always get source. With no source, you cannot
make the function virtual.

-- 

Nick

Re: What is wrong with OO ?

[Nick Leaton]

Valentin Bonnard wrote:
> 
> Nick Leaton wrote:
> >
> > richard@highrise.nl wrote:
> > >
> > > Virtual functions are also a kind of documentation. When declaring a
> > > function virtual, the programmer is more or less saying "go ahead,
> > > override this function if you like."
> >
> > The decision to make a function virtual assumes a knowledge of what
> > users of your class are going to do. It akin to predicting the future.
> 
> No. If it make sense to override, make it virtual; if it doesn't,
> don't make it virtual.

If you can forsee the future!

> > One of the problems with C++ is this very point. Should you, as a
> > designer of a class restrict what someone else does with your class?
> 
> Yes; even the fact that you have private members restrict what
> can be done with your class; does it mean that you should
> only use public data members (ie expose all your implementation
> details) ?

We are only talking about classes that inherit, not classes that
use. Why shouldn't a class that inherits another get access to 
implementation details?

> > If you provide the class to someone else without source code, and they
> > find a bug. One solution to fixing the bug is to produce a new class
> > that inherits the original, and redefines the offending routine. However
> > your decision about declaring or not declaring the routine virtual in
> > the first place affects what can be done.
> 
> You don't inherit from a class to fix it in C++ (nor to reuse it);
> you specialize it. You don't patch a class like you apply a diff
> file to a system to patch it !

OK, Microsoft release a duff library with a duff class. You
have no source. Will Microsoft give you the source? No. You
have to inherit and overide. It is ugly, it is not ideal, but 
you have no choice.

> [For Mac programmers: overriding != SetTrapAddress]
> 
> One must never forget that inheritance is not the only way to
> use a class; composition is often the only sensible way.
> 
> If there is a bug in one member function in a class, then if
> you don't have the source code it's difficult to be sure
> that the cause of this bug (or a similar bug) is not in
> another function.
> 
> Even if you are sure that you only need to correct one
> function, public [normal] inherintance is not the way to go.
> 
> You might use private inheritance and redefine the buggy
> function:
> 
> class BuggyClass {
> public:
>     void BuggyFunction (); // need not to be virtual
>     void OtherFunction ();
> };
> 
> class CorrectedClass : private BuggyClass {
> public:
>     void BuggyFunction ();
>     using OtherFunction;
> };
> 
> void CorrectedClass::BuggyFunction ()
> {
>     // corrected function
> }

It won't work. A user that has a pointer to a BuggyClass, which
is an instance of CorrectedClass. The user calls ptr->BuggyFunction()
The buggy code will be run, not the CorrectedClass::BuggyFunction.
However if BuggyFunction is declared as virtual, it will work.

> With private inheritance it's not possible (except for
> CorrectedClass members) to convert a CorrectedClass to
> a BuggyClass; it means that only CorrectedClass know that
> CorrectedClass IS-A BuggyClass.
> 
> You can also use composition by reimplementing all the
> functions of BuggyClass; all these implementation just
> call the corresponding function in BuggyClass; only
> BuggyFunction is really rewritten.

This won't work. The corrected class will not inherit BuggyClass,
and so cannot be reffered to using a pointer to its base class.

> And anyway I feel that's a very special case. You
> should ask the BuggyClass writer to correct its class.

Agreed. But you have to be realistic. Lets say Microsoft release some
buggy code. Nothing suprising there. How long are you prepared to
wait for them to fix the code?


> Valentin Bonnard
> mailto:bonnardv@pratique.fr
> http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)

-- 

Nick

Re: What is wrong with OO ?

[Fergus Henderson]

Nick Leaton <nickle@calfp.co.uk> writes:

>Valentin Bonnard wrote:
>> 
>> Nick Leaton wrote:
>> >
>> > richard@highrise.nl wrote:
>> > >
>> > > Virtual functions are also a kind of documentation. When declaring a
>> > > function virtual, the programmer is more or less saying "go ahead,
>> > > override this function if you like."
>> >
>> > The decision to make a function virtual assumes a knowledge of what
>> > users of your class are going to do. It akin to predicting the future.
>> 
>> No. If it make sense to override, make it virtual; if it doesn't,
>> don't make it virtual.
>
>If you can forsee the future!

It's not about forseeing the future, it's about programming by contract
and making appropriate design decisions.

>We are only talking about classes that inherit, not classes that
>use. Why shouldn't a class that inherits another get access to 
>implementation details?

Because those implementation details may change!

>OK, Microsoft release a duff library with a duff class. You
>have no source. Will Microsoft give you the source? No. You
>have to inherit and overide. It is ugly, it is not ideal, but 
>you have no choice.

That is a perfect example of why you should *not* do this,
because if you do, then Microsoft will screw you when they
release the next version.  In the next version, they will
have declared what you thought was a bug to be a feature,
and they will have lots of code that depends on it.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: C++ Class [ not a good answer ]

[Luis Espinal]

> Read about polymorphism and virtual functions.
> 

This is a better answer to the original question.

Lock Minh, what you need is a class that has at least one pure virtual 
function in it. That way, nobody can instantiate an object from it and
still use it as a base class.
.ie.

class MyBase
{
	MyBase(){...}
	virtual ~MyBase(){ ... }
	virtual void SomeFunction() = 0; // a pure virtual function.
};

// you still need to implement the pure virtual func.
void MyBase::SomeFunction(){}

class AChild : public MyBase
{
	... here goes the constructors, destructors, etc.
	// you need to implement the pure virtual function
	// defined in MyBase; otherwise, you won't be 
	// able to instantiate a AChild object either.
	virtual void SomeFunction();
};

void AChild::SomeFunction()
{
// some code in here.
}

AChild someChild; // ok...

MyBase someBase; // eeek! can't compile.
		 // can't instantiate a class with 
		 // a pure virtual function in it.

Hope it helps.

Luis Espinal

p.s. cryptic answers don't help.
-- 
Luis++ lespin03@solix.fiu.edu
What does not kill us, makes us stronger...
What does not break us, makes us...
That which does not break, must bend...

Re: C++ Class [ not a good answer ]

[Tom Plunket]

On Mon, 03 Mar 1997 13:42:16 -0500, Luis Espinal
<lespin03@solix.fiu.edu> wrote:

> Lock Minh, what you need is a class that has at least one pure virtual 
> function in it. That way, nobody can instantiate an object from it and
> still use it as a base class.
> .ie.
> 
> class MyBase
> {
> 	MyBase(){...}
> 	virtual ~MyBase(){ ... }
> 	virtual void SomeFunction() = 0; // a pure virtual function.
> };
> 
> // you still need to implement the pure virtual func.
> void MyBase::SomeFunction(){}

Can't you just create a pure-virtual class, that doesn't
have pure-virtual member functions (if indeed you don't want
that)?  I thought that that was what class ios did.
Something along the lines of:

class CSomeVirtual
{
    CSomeVirtual();
    ~CSomeVirtual();

    MemberFunction();
    AnotherMemberFunc();
} = 0;

???

Then you're forced to derive from it, but everything is
implemented, too.

-Tom