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 ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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: The Impossible Project: not so funny... (Was: what's wrong)

[Tim Ottinger]

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.

I added up all of the reasons I've seen things fall apart, and put them
into a single nightmare scenario, to show how you can fail even with
great, steaming wads of cash.

After all, it's my assertion that very few projects fail for reasons of
technology.  There are so many more reasons.

Even with OO, IE, or SA/SD, or any magic bullet methodology in the
world,
the only answer to this one is to walk away and save the $M.

                              :-(  :-(

The customer has absolutely no idea how they want
to use the system, or what it should do, or how they'll run their newly
formed business.  They're inventing business processes as they go. 
Every
requirement may be changed or scrapped since they've never actually
done the work they're gearing up for.

But the software must automate all of their processes, and must be
intuitive enough that it can be operated expertly by 10th grade 
students (not honor students) with less than one day of training.

You'll be supporting three customers in three different markets,
who will use the system different ways.  These way's haven't been
decided yet.  

It must be accurate to the 9th decimal place (right side).

Your staff has never programmed in the language and environment that is
mandated by the customer.  They've also never worked in this domain
before.  You are similarly clueless.  You are not allowed to buy tools
or libraries.  Only salaries are acceptable.

The hardware acquisition cycle runs about 14 months.  The software
acquisition cycle runs 10.  Acquisition cycle for hiring is 8 months.
The company requires all applicants have a business degree.

You will not be allowed to interview the client directly.  Instead 
you will be expected to work through a  mediator.  The average 
turn-around for a question will be about three weeks.

The database you'll be using is also mandated, and doesn't work yet.

The system must control yet-unspecified equipment in realtime, but
provide online reporting which is up-to-the-second in an RDBMS that
is hosted on Windows NT box which is to be completed in two years,
and the OS will be ready in three.  Unless it doesn't work or
the client changes their mind about the platform.

			:-) :-) :-)

Okay, I'm being silly, but there is nothing a good or even an excellent
developer can do with total uncertainty and ambiguity, especially
when the customer is hostile or unapproachable.  If requirements are
not determined, and the users refuse to settle you are likewise in
a position where you probably can't make much success.

Now any small set of these problems are present in every single 
project.  Hopefully, we can educate our users and customers so that
we don't have too many at once.

In this case, it isn't OO that fails, it's the decision to try an
build a project that can't work.

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: The Impossible Project: not so funny... (Was: what's wrong)

[Robert Dewar]

Tim says

"Okay, I'm being silly, but there is nothing a good or even an excellent
developer can do with total uncertainty and ambiguity, especially
when the customer is hostile or unapproachable.  If requirements are
not determined, and the users refuse to settle you are likewise in
a position where you probably can't make much success."

Not so silly! Probably the only silly thing was imagining ALL these
things to happen on one project, but I would be willing to bet that
every single one of your imagined horrors is real in some context.

The funny thing is that when someone says "gosh, for a 100 million buckaroos
I could build anything", they are falling into the trap which we are 
discussing, namely the assumption that you can buy your way out of
disaster, when in practice money is quite often the means by which
you end up spending yourself into disaster.

Re: The Impossible Project: not so funny... (Was: what's wrong)

[John DiCamillo]

Tim Ottinger <tottinge@dave-world.net> writes:

>I added up all of the reasons I've seen things fall apart, and put them
>into a single nightmare scenario, to show how you can fail even with
>great, steaming wads of cash.

[loads of good funny stuff mercilessly snipped]

>You are not allowed to buy tools or libraries...

Or, my personal favorite:

You can buy all the libraries and tools you want.  However, they
are all mutually incompatible and at different release numbers
on different platforms.  At least one of the tools or libraries
will have a new release each month, rendering it incompatible
with anything it may have been compatible with in the past, and
introducing exciting new bugs to replace the old bugs that you
had already found work-arounds for.  The bugs you couldn't find
work-arounds for will be fixed in a future release, but only on
the platform you are not using.

(Hey, this is fun!  Let's do some more! :-)

You buy a source license to one of the tools so that you can fix
the bugs you couldn't work around, but now you must dedicate a
resource to keep re-fixing the bugs in each new release of the
tool, on each platform you need to support.

(Thanks for a pre-holiday chuckle, Tim!)

-- 
    ciao,
    milo
================================================================
    John DiCamillo                         Fiery the Angels Fell 
    milod@netcom.com       Deep thunder rode around their shores

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: The Impossible Project: not so funny... (Was: what's wrong)

[Guy Rixon]

Tim Ottinger wrote:
> 
> Kazimir Majorinc wrote:
> ...I added up all of the reasons I've seen things fall apart, and put them
> into a single nightmare scenario, to show how you can fail even with
> great, steaming wads of cash.
[Details of nightmare deleted]

Here's another one to worry about:

There is no clear customer for your product.  The nominal customer is a
collaboration of independent organizations.  After a little digging, you
find that funding, functional requirements, technical contraints, and
acceptence testing are being handled by different groups who make
conflicting demands because they are unaware of each other.  You
introduce them and they declare inter-office war on each other: nothing
is resolved.  About the time that you have something to demonstrate, the
war of words goes politically nuclear and one or more of the `customers'
gets wiped out.  You are left with no sponsors for the many dubious
decisions you were forced to make to reconcile the conflicting
requirements.
-- 
Guy Rixon,				gtr@ast.cam.ac.uk 
Software Engineering Group,		Tel: +44-1223-374000
Royal Greenwich Observatory 		Fax: +44-1223-374700

Re: The Impossible Project: not so funny... (Was: what's wrong)

[Chip Richards]

Tim Ottinger, Robert Dewar, John DiCamillo, and Guy Rixon wrote:

   > Kazimir Majorinc wrote:
   [Details of nightmare deleted]
   Here's another one to worry about:
   [etc., etc.]

Would you guys stop it!?  My boss thinks I'm posting our internal memoranda to
the net! <grin>

Seriously, I've never been on a project that has been afflicted by *all* these
problems at once, but they are each terrifyingly familiar.  And please, don't
really stop writing about it--I'm loving this stuff.

Of course, no amount of astute project management can help you if you build
your project on a platform that's discontinued by its vendor two weeks after
you release your product.  Not that such a thing would *ever* happen, noooo.

--
Chip

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 ?

[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!!!!!!!)
*************************************

What sells IT (was: What is wrong with OO ?)

[Cameron Laird]

In article <32BB2C13.A38@rase.com>, Tansel Ersavas  <tansel@rase.com> wrote:
			.
			.
			.
>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
			.
			.
			.
It motivated me.  'Still does.  I don't know
whether individual experience affects your
larger argument, but I've been a WWW enthusi-
ast from early on, and I still use lynx at
least one order of magnitude more than any
other browser.  The sights-and-sounds dimen-
sion of WWW generally leaves me cold.

I've severely trimmed follow-ups.
-- 

Cameron Laird           http://starbase.neosoft.com/~claird/home.html
claird@NeoSoft.com      +1 713 623 8000 #227
                        +1 713 996 8546 FAX

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 ?

[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]

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

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

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

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

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

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

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

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

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

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

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

Assembler most efficient??? (was Re: What is wrong with OO ?)

[Richie Bielak]

Robert Dewar 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."
> 
> 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.
> 

[...]

I agree with Robert 100%. In John Bentley's book "Programming Pearls"
there is a neat example of this. He shows a program written in BASIC
on a TRS-80 and a program written in FORTRAN on a Cray. The BASIC
program used a linear algorithm and the FORTRAN program used
a quadratic algorithm to solve the same problem. When the size
of problem got to about 10,000 the TRS-80 beat the Cray.

Part of the difficulty compilers have with generating good code
is that CPUs are being designed by people who coded in assembler
and never had to write a compiler. Niklaus Wirth's Lilith computer
was an example of a CPU designed with a compiler in mind. He has
written a bunch of articles comparing the performance of his
Modula-2 compilers on Lilith and the MC68000 (see past issues of CACM 
- about 10 years ago?). The Lilith outperformed most computers
in its class and it didn't have an assembler.

Compilers can be much smarter than programmers in generating
machine code, especially on some of these pipe-lined RISC CPUs.

...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: Assembler most efficient??? (was Re: What is wrong with OO ?)

[Robert Dewar]

Richie said

"Part of the difficulty compilers have with generating good code
is that CPUs are being designed by people who coded in assembler
and never had to write a compiler."

Do you really have evidence of this? What machines are you talking about?
I know quite a bit about the design of the common processor chips around,
and I really cannot think of one case where the scenario you present above
rings true. On the contrary, for example, the design of the MIPS chip was
done with input from compiler considerations all along the way. In some
sense the whole business of pipelined RISC architecture is intimately
wound up with compiler considerations.

I can think of some examples in the past where instruction sets have been
designed with far too much naive input from high level language and
compiler considerations, but none of them seem to have survived into the
modern RISC era.

Re: Assembler most efficient??? (was Re: What is wrong with OO ?)

[Larry Kilgallen]

In article <dewar.852989882@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Do you really have evidence of this? What machines are you talking about?
> I know quite a bit about the design of the common processor chips around,
> and I really cannot think of one case where the scenario you present above
> rings true. On the contrary, for example, the design of the MIPS chip was
> done with input from compiler considerations all along the way. In some
> sense the whole business of pipelined RISC architecture is intimately
> wound up with compiler considerations.

Compared to the operating system groups, the DEC compiler groups had
as much if not more input to the designers of the Alpha chips.

Larry Kilgallen

Re: Assembler most efficient??? (was Re: What is wrong with OO ?)

[James S. Rogers]

Robert Dewar wrote:
> 
> Richie said
> 
> "Part of the difficulty compilers have with generating good code
> is that CPUs are being designed by people who coded in assembler
> and never had to write a compiler."
> 
> On the contrary, for example, the design of the MIPS chip was
> done with input from compiler considerations all along the way. In some
> sense the whole business of pipelined RISC architecture is intimately
> wound up with compiler considerations.

Another example is the HP-PA-RISC chip.  Extensive work was done
profiling the instructions from many languages including COBOL,
Pascal and C.  In fact, this effort is what the "PA" in the name
of the architecture stands for.  "PA" is Precision Architecture.
It refers to the fact that the architecture is built upon the
very extensive and precise measurements HP made to determine
which architectural features were most important to modern
computing.

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: Assembler most efficient??? (was Re: What is wrong with OO ?)

[Joel VanLaven]

  Just to add my little bit of trivia, I read once about the CRISP
architecture designed by ATT (I think) that stood for the C Rational
Instruction Set Processor, that was designed almost solely to be better
for programs written in C.  I think they decided that optimizing the
stack was very important for the C programs they were working with and
so designed a special "stack cache."  Actually, much of UNIX is written
in C anyway, so optimizing for the compiler IS optimizing for the OS,
at least indirectly.

Larry Kilgallen (kilgallen@eisner.decus.org) wrote:
: In article <dewar.852989882@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

: > Do you really have evidence of this? What machines are you talking about?
: > I know quite a bit about the design of the common processor chips around,
: > and I really cannot think of one case where the scenario you present above
: > rings true. On the contrary, for example, the design of the MIPS chip was
: > done with input from compiler considerations all along the way. In some
: > sense the whole business of pipelined RISC architecture is intimately
: > wound up with compiler considerations.

: Compared to the operating system groups, the DEC compiler groups had
: as much if not more input to the designers of the Alpha chips.

: Larry Kilgallen
-- 
-- Joel VanLaven

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 ?

[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: Assembler most efficient??? (was Re: What is wrong with OO ?)

[Richie Bielak]

Robert Dewar wrote:
> 
> Richie said
> 
> "Part of the difficulty compilers have with generating good code
> is that CPUs are being designed by people who coded in assembler
> and never had to write a compiler."
> 
> Do you really have evidence of this? 

[...]

> 
> I can think of some examples in the past where instruction sets have been
> designed with far too much naive input from high level language and
> compiler considerations, but none of them seem to have survived into the
> modern RISC era.

My comments were mostly based on what I read about Wirth's work on
Modula-2,
Oberon, Lilith etc., which I realize I somewhat outdated.

I know that many of the RISC processors are designed more with the
compiler
in mind. 

My favorite example of a compiler going wrong with the instruction
set provided, was DEC's old COBOL compiler on the VAX. As you must know,
VAX provided many instructions specifically aimed at making code
generation
easier (eg. INDEX, LOCC, SCAN etc). In one case the COBOL compiler
generated exponential algorithm for a linear problem using those fancy
instructions. 

Finally, to get back to the orignal topic, I think that on the modern
RISC 
processors it is more likely for a compiler to generate faster code 
than what could be hand written in assembler.

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

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

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