🚀 go-pugleaf

In article <147@m10ux.UUCP> mnc@m10ux.UUCP writes:

> Why is it so hard for O-O programming advocates to explain the advantages
> of their programming methodology without slipping into obscure, specialized
> O-O jargon, or invoking the religious argument, "well you can't under-
> stand why it is better until you've done a large amount of O-O programming
> yourself"?

I would say this differently.  It is not that you can't understand
it, but that it is difficult for me to *explain* it until you have
done some (not necessarily large) amount of O-O programming yourself.
This difficulty seems to happen in spite of my best efforts, witness
my paper "Object Oriented Programming", SIGPLAN Notices, Sept 1982.
[Incidentally, the paper was written for just that reason -- to
explain what OOP is to someone who had not done any -- and it did
not succeed.]

As to why explaining OOP is so hard:  I suspect an understanding of
OOP requires a paradigm shift, and paradigm shifts are just
inherently difficult, especially without the experience of trying
them.  Remember the difficulty the quantum mechanics people had in
the 1920's and 30's?  Even Einstein, a brilliant physicist, was
reluctant to see things from the QM point of view, but now QM is an
accepted part of physics.  The difficulty there was the (radical)
paradigm shift that QM required before it could be understood.  



> What is the difference (other than a rather contrived, anthropomorphic
> view of the relationship between functions and values), between O-O
> programming and the ten (?) year old theory and practice called "abstract
> data types"?  The fundamental belief with technical importance in
> both methods (with which I completely agree) is that pieces of programs
> should be divided into chunks that have a precisely documented interaction
> with other chunks, but the internals of which are completely unknown (or
> irrelevant to) other chunks.  Put more concisely, "separate WHAT it does,
> from HOW it does it, so that the HOW can be changed without affecting the
> WHAT".  Isn't O-O programming simply a special case of, i.e. one particular
> method for achieving, abstract data types?  It seems to lie completely
> under the definition of an abstract data type as a collection of types
> and functions on those types, together with the notion that we can have
> multiple objects of the abstract data type.

OOP is not (in my opinion, at least!) simply a special case of
abstract data types.  Here are several reasons, ranging from
specific and particular to more general (which you may feel are
vague and contrived -- even so I present them).  I only hope that
among the various reasons presented, some point will strike home.
[I use Smalltalk as the archetypal OOP language.]

In Smalltalk, variables (and parameters) do not have a type, in the
sense that a type is known at compile time.  With abstract data
types this is not so -- even though we don't know how the operations
work, with ADT's we at least know what the operations *are*.  In
Smalltalk we don't even know that.  Now, you can argue about whether
this difference is good or bad, but it is certainly a difference,
and I claim a significant and useful one.

Second, classes in Smalltalk do not have "precisely documented
interactions" in the sense that even if you know the class of some
variable, you don't know anything about the operations except their
names (and so how many parameters each operation expects).  In
particular, there is no specification of what function the operation
will perform, or even of what "type" of arguments are required.
Again, contrast this to ADT's, which do have specifications.  You
might believe that this makes ADT's superior to OOP -- on which point
I disagree -- but even so you must admit this is a difference.  (Why
that difference makes OOP better is another matter.)  

Most ADT's cannot express very polymorphic operations, for example
stacks of mixed types (not to be confused with type parameterized
stacks, which can be instantiated multiple times for different
types).  In Smalltalk, it is trivial to write a class definition for
a stack which can mix integers, floats, rectangles, and even other
stacks within a single stack.  The ease of writing very polymorphic
code clearly distinguishes OOP from ADT's.

"Separate WHAT it does, from HOW it does it" certainly characterizes
ADT's.  But "this is what should be done" is not what I think of as
OOP; rather it is more like "what I WANT is blah", but leave the
decision of what is to be done (more than just how to do it) up to
the object.  I realize this may seem like a fine distinction (or
perhaps no distinction at all), but I assert that the distinction is
real and significant.

(The vaguest explanation of all, but still, I hope, useful.)  An ADT
is, indeed, a "collection of types and functions ON those types"
[emphasis mine].  In OOP, on the other hand, data and function are
inextricably linked -- rather than functions operating on data,
operations are intrinsic to the object just as much as data is
intrinsic to the object.  Data and operations cannot be separated in
OOP;  they are separate in ADT's, only collected together for the
purpose of presenting the data type to the "outside world", but
internally they are still separate.

Just as I believe your questions were asked sincerely, so I have
tried to give sincere and informative answers.  Hope they helped.
(See also the paper reference earlier.)

cheers,

Tim