Gentle Reader:

I regret the length of this response but I have left far more out
than I have put in.  If the following reads like a rank then I
crave your forgiveness in advance. It was not meant as such.

On 13 Feb 2001, at 14:00, Boris Kortiak wrote:

>  I pointed out that a number of things which make C++ an OO
> (data hiding (I forget the correct term) and others) were part
> of my COBOL tool box for a long long time.  He was quite
> flabbergasted that this was possible.

In the preface to one of Kent Beck's books he writes about a
conversation that he had with a participant of one of his
seminars on OO design and programming.  Paraphrased and
abbreviated it boiled down to the statement by the participant
that "... objects are just a fancy name for a procedure call ...".
 Kent, who is a recognized authority in the smalltalk world,
then goes on to write that he had to think about that
statement for a time but eventually came to the conclusion
that OO programming and design was different.

I thought about it and came to a different conclusion.  Of
course, like that participant, I had about 15 more years of
design work than Mr. Beck. More importantly in my view, for a
number of years I was designing programs for multiple users
on machines that had the memory and processing power of
the chip that now runs my alarm clock.  I was designing with
others in teams where the management of resources and risk
was greater than the effort put into the programs themselves. I
was designing when the cost of hardware still exceeded that
of labour by a large margin.

I won't go so far as to relegate the trendy concept of OO to the
dustbin, but there is a lot of history that is conveniently
glossed over by the proponents of OO everything. There is
absolutely nothing new about OO, save the terminology.
Specialization has been an essential part of all large projects
from the beginning of time.

To build a skyscraper one does not start by laying bricks and
figuring out where to go on a day by day basis.  What one
does have is a construction plan, a structural plan, an
architectural plan, a wiring plan, an HVAC plan, a lighting
plan, etc.  Are these not conceptual objects? Is not one
mostly independent of the other, save where they must inter-
connect? Does the HVAC plan need to know of the wiring on
the 70th floor, or just about the wiring that runs the plants?
Does lighting have to know about the unions in the steel
structure, or just where in the structure the conduits must
run?  Are these not interfaces by any other name?

What has changed is that the programmers, who grew up
having to do everything for themselves on primitive machines
writing programs that performed trivial tasks, have discovered
anew that building complex things can be an even more
complex undertaking..

The OO concept of binary re-use and code sharing were all
well established parts of the HP3000 world long before dll and
com+ was even thought about.   I remember when the
philosophy of HP programming, in any language, was the
separation of data from code.  The one was private and could
change and expand/contract dynamically; the other was static
and could be shared simultaneously by many users on the
same machine.

The OO idea of black-box development and implementation is
nothing new either.  HP intrinsics and the SL are perfect
examples of black-box programming.  Who needs to know
HOW a 'dbput' or an 'fopen' works, so long as each new
implementation always takes the same arguments,
accomplishes the same task, and returns the same values.
Yet I have noted that, despite their relevance, discussion of
Re-locatable Binary OBJECTS (note the name) in prior
programming art is conspicuous by its absence in any writing
about OO that I have read, and I have read a lot.

COBOL stays around not because of the inherent worthiness
of COBOL.  COBOL remains because of the quality of the
designs that are implemented in COBOL.  Designs that have
stood the test of twenty years of use and refinement while the
world of computing has changed beyond all recognition.

In the main these are designs that used structure and
modularization from the beginning. Designs that do make re-
use of binary code. Designs that are essentially OO in all but
name.  Designs that COBOL was capable of implementing
well; even if the language did have a GOTO statement, even if
it did permit a programmer to reach into a procedure and
meddle about.  Such things were frowned on then as they are
frowned on now. OO programming hasn't changed any of this.
C and C++ don't do that much of a better job preventing such
practices.

In my opinion OO Design is in the same boat as OO
Programming; old wine, new bottle.  I have in my possession
a 1980-something reprint of the proceedings of the Seldom
Met Users Group (SMUG) dating from ~1979. One of the
articles therein is titled; "Design To Throw Away", or
something very similar.  In that article the author, (David
Greer?, somebody from Robelle anyway) writes of the
necessity to keep programs and procedures small and
disposable. By doing so the design/programming team never
has such an investment in a piece of work that they would
rather salvage what they have than scrap it all and start anew.

Is this not in essence OO design, put much more simply and
in a form that nearly anyone can understand?  Here we have in
concrete terms the exact purpose of OO design.  To break
things down into the bits that do one thing well, and that can
be freely discarded, replaced, and reworked; without impacting
any other portion of a system.

The only thing that has to be rigorously controlled for this to
work are the interfaces between the bits, the calls and returns,
and the results accomplished by each bit. Well guess what
OO Design/Programming is mainly about? Interfaces, and the
need to keep them inviolate.  OO design is mostly about
systematically identifying and describing those interfaces.
What goes on inside an object, just as for a COBOL
procedure or an SL intrinsic, is of no concern to the calling
process. This is hardly a revolution in thought or practice for
the profession of Computer Science.

Yes there have been significant advances in design
techniques, methodologies, and tools.  Languages that
enforce programming practices that were always recognizable
as desirable are a tremendous advance. Yet overall there has
been even more that has stayed the same or has changed
very little. It seems to me that after a twenty year journey the
programmers of the IBM PC and its descendants have finally
met the past, and find out that is is their future.

Regards,
Jim

---   *** e-mail is not a secure channel ***
James B. Byrne                Harte & Lyne Limited
vox: +1 905 561 1241          9 Brockley Drive
fax: +1 905 561 0757          Hamilton, Ontario
mailto:[log in to unmask]  Canada L8E 3C3