GUMBY.MIT-OZ@BRL (12/05/82)
From: David Vinayak Wallace <GUMBY@Mit-Mc>
Note: This has nothing to do with the 432.
Date: 29 Nov 82 10:35:48-PST (Mon)
From: decvax!utzoo!utcsrgv!donald at Ucb-C70
To: info-micro at BRL
Re: "object-orientedness" vs "data encapsulation" and the iAPX432.
I beg to differ with Tim Rentsch.
I see very little difference between the meaning that lies behind
the recent buzz-term "object-oriented" and the fairly old concept
of data encapsulation/abstraction.
Object-orientness appears to be a buzzword promulgated by the
Smalltalk (LRG) group at Xerox PARC for the purpose of confusing
the public into the belief that they've discovered a new a
wonderful concept. After reading the rather vague descriptions in
a BYTE issue (which seems to be the only readily available
reference on Smalltalk), I've come to the conclusion the concepts
in Smalltalk are actually fairly mundane-- it's just that the
imagery and terminology used by its creators is quite strange.
Just as one example, "message passing" between objects in
Smalltalk is hailed as a novel approach to control flow, but it is
absolutely isomorphic to a procedure call, where "message" is a
fancy name for routine name + parameter list! "Multiple
Inheritance Subclassing" is merely "parameterized abstract data
types" by another name.
I disagree. The isomorphism exists only in the simplest of cases.
Message-passing is a method of abstracting one's approach to function
calling/argument passing. The chief difference between message passing
and a normal function call is that the message-passing model allows
each object to dynamically decide how to handle a given message in its
own way -- therefore, the language becomes abstracted, and more
general mechanisms are available to the user.
Multiple inheritance subclasses aren't a simple idea. You obscure the
issue by using uncommon term, "parameterized abstract data types."
Classes are hierarchical structures not only of data elements but of
functional elements too. Classes can therefore depend on handlers from
their component classes (all writing-objects can use the same DRAW
message) or redefine it (the special case of PENCIL can have a lead
that breaks).
The sum of these two concepts is a completely new, modular approach to
expressing problems. Of course, you could do most of it in a "normal"
language -- but you can write anything in assembler too. The
message-passing model frees the programmer to divide and attack a
problem in his own way.
Don't get me wrong-- I think Smalltalk is an interesting
language/system, what with its lisp-like aspects, run-time typing,
and unified view of objects, but it irks me that LRG couldn't find
a paradigm for their system that maps more naturally into the rest
of the universe. It seems that LRG had severe philosophical
problems.
I think that their paradigm (though perhaps not word choice) is a
correct one. We don't know enough about its ramifications to dismiss
it out of hand. Personally, I prefer to think about abstract objects,
and to be able to manipulate them easily. Languages like CLU try to
give this power with a more "normal" paradigm (clusters), but fall
short. Smalltalk and other object-oriented languages offer
programmers (and non-programmers) a new way of attacking problems.
Down with Object Orientedness!
On the contrary, down with close-mindedness! I'm not sure
message-passing will be the ultimate way to write programs, however I
AM sure the current way won't. We have to keep looking and exploring.donald (12/06/82)
David,
I read your comments with interest, but I fear that I'm not making myself
clear, so here's another try at it:
Message-passing is a method of abstracting one's approach to function
calling/argument passing.
I think that you're confusing specification with implementation. A Routine
invocation is itself a paragon of abstraction. When I say "sqrt(5)"
in a program I mean "compute me the square root of 5". I don't care how it's
done. I can even say that I'm passing a "five" message to the "sqrt"
object if you really want! Or do your prefer passing a "sqrt" message
to a "five" object?
I think that Smalltalk's message passing paradigm is merely a semantic
trick. I can give a "message passing" interpretation to any Pascal (or
FORTRAN) program you care to give me.
... The chief difference between message passing
and a normal function call is that the message-passing model allows
each object to dynamically decide how to handle a given message in its
own way -- therefore, the language becomes abstracted, and more
general mechanisms are available to the user.
To pick a trivial example, look at the BCPL family of languages,
which are untyped. The BCPL's are low level because routine parameters
are chunks of bits which can be interpreted in whatever way the routine
desires. Surely that's not what you mean. Sounds pretty dangerous to me.
Look at LISP. Surely you'll agree that LISP uses the usual "function-call"
paradigm, yet there is no static type checking, so anything at all may be
passed to a LISP function and it's the function's responsibility to interpret
the parameter.
All these languages do what you are describing without reference to
"message passing". Do you still think Smalltalk is new and unique?
Consider CLU, Alphard, Ada, and Simula. The only real difference between
these and Smalltalk is that the latter's LISP-like aspects repudiate
static type checking. This gives Smalltalk more "power" in that bindings
can be more dynamic, but it is also what makes Smalltalk harder to implement
efficiently, just like LISP.
Multiple inheritance subclasses aren't a simple idea. You obscure the
issue by using uncommon term, "parameterized abstract data types."
That's a matter of opinion, depending on what circles you move in. Abstract
data types are a common enough concept. Parameterization of abstract data
types follows straightforwardly. Multiple inheritance subclasses are a
simple idea, at least from the impression I get from reading the PARC paper
on "Traits" concerning the use of subclasses in programming the Xerox Star.
Classes are hierarchical structures not only of data elements but of
functional elements too. Classes can therefore depend on handlers from
their component classes (all writing-objects can use the same DRAW
message) or redefine it (the special case of PENCIL can have a lead
that breaks).
Of course. Look at CLU clusters. Alphard forms. Ada packages.
Everybody already agrees that data types must have operators associated
with them.
As for several objects using the same message, isn't that just routine
name overloading? I believe user-defined overloading dates back to
Algol 68...
The sum of these two concepts is a completely new, modular approach to
expressing problems. Of course, you could do most of it in a "normal"
language -- but you can write anything in assembler too. The
message-passing model frees the programmer to divide and attack a
problem in his own way.
Why is it completely new and modular? CLU, Alphard, Ada etc. gives you
all of that, the only difference being the static type checking (which
makes them a heck of a lot more efficient than Smalltalk...)
... Personally, I prefer to think about abstract objects,
and to be able to manipulate them easily. Languages like CLU try to
give this power with a more "normal" paradigm (clusters), but fall
short. Smalltalk and other object-oriented languages offer
programmers (and non-programmers) a new way of attacking problems.
No it doesn't. Smalltalk does not offer any NEW approach to abstraction
that I can see. Some things may be done more easily in Smalltalk because
of its dynamic nature, but that has yet to be seen. Why does CLU fall
short?
I like to think about abstract objects too. I don't need Smalltalk
to do it though.
On the contrary, down with close-mindedness! I'm not sure
message-passing will be the ultimate way to write programs, however I
AM sure the current way won't. We have to keep looking and exploring.
On the contrary, down with buzzwords and the Emperor's Old Clothes.
Nowhere have I seen a formal definition of "object oriented". Message
passing seems to contribute little conceptual leverage and no practical
leverage. What do you mean when you say object oriented?
What is your conception of the "current way" of programming
and why does it fail?
Don Chanrpk (12/06/82)
Well, the inheritance idea is not the intrinsic feature/concept in object-oriented-ness: they just make dealing with such programming easier. I'd like to say more, but this discussion does not belong on net.micro. Perhaps it should be moved to net.arch ? Not afraid to be viewed as an object, Robert P. Krajewski UUCP: ...!genradbo!mitccc!rpk ARPA: RpK@MC