Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!husc6!ut-sally!utah-cs!shebs
From: shebs@utah-cs.UUCP
Newsgroups: comp.lang.misc
Subject: Re: Teaching object-oriented paradigm to beginners?
Message-ID: <4176@utah-cs.UUCP>
Date: Sat, 17-Jan-87 15:20:34 EST
Article-I.D.: utah-cs.4176
Posted: Sat Jan 17 15:20:34 1987
Date-Received: Sun, 18-Jan-87 00:20:09 EST
References: <4000001@nucsrl.UUCP> <3288@milano.UUCP> <147@m10ux.UUCP> <624@unc.unc.UUCP>
Reply-To: shebs@utah-cs.UUCP (Stanley Shebs)
Organization: PASS Research Group
Lines: 95

In article <624@unc.unc.UUCP> rentsch@unc.UUCP (Tim Rentsch) writes:

>OOP is not (in my opinion, at least!) simply a special case of
>abstract data types.

Depends on what you mean by "abstract data type".  Modula-2's view of
ADTs for instance is totally useless, since a type is equated with
syntax rather than with semantics.  CLU is better but still restrictive
on what can be done.  If you want to see an ADT language with the right
amount of power, check out Goguen et al's OBJ2 (described in POPL 85 and
elsewhere).  It has everything Smalltalk has and more, not to mention
that it's much cleaner and less arbitrary than much of Smalltalk.

>In Smalltalk, variables (and parameters) do not have a type, in the
>sense that a type is known at compile time.

Use of the phrase "compile time" is misleading.  What a compiler can
or cannot do to a program is irrelevant - the issue is what can be expressed
in the language and how.  I assume that you really mean to say "the
value of a variable can be an object of any type at any time".  This is
polymorphism, which is certainly not unique to Smalltalk.  OBJ2 has it
for instance, under the guise of "parametrized objects" and "subsorts".

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

This has to do with "incrementality" of programming environments.  If
you had a Unix Smalltalk compiler that produced an a.out file, that compiler
must definitely know what operations it will include in the executable.
There are situations in which one could construct a new method on the fly,
but this is no different than constructing and evaluating Lisp expressions;
you just have to make sure that your a.out file includes an interpreter or
compiler to use the expression once created.

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

Incremental programming environments and the ability to construct new
pieces of program are both Good Things, but they have nothing to do with
OOP directly.

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

This is mistaken.  Smalltalk operations *do* have specifications.
"Specification" covers many sins; a definition of addition that says
"takes two objects, returns an object or causes a core dump" is perfectly
valid, though perhaps vague... It's hard to imagine a program that is not
the model of at least one specification! :-) :-) :-)

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

At best a difference of words, not of concepts.

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

No, it clearly distinguishes inferior ADT systems from good ADT systems.
Polymorphism is independent of OOP and ADT - for instance, vanilla Lisp
and Prolog systems are polymorphic but are not considered object-oriented
or data-abstracted.  In my book, non-polymorphic languages are down with
assembly languages as things to avoid.

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

Pretty vague all right!  From denotational semantics we know that there
is no distinction between data and operations, only artificial distinctions
imposed by pragmatic considerations.  Once again, equivalence of data and
operation is not unique to OOP, it is an essential of any halfway-decent
programming language.

There *is* one aspect of the object-oriented paradigm that comes out better
than in other paradigms - concurrency.  Hewitt-style actors communicating
with each other make more sense to me than the bizarre concurrency formalisms
promulgated for procedural, functional, and logic paradigms... Anybody
see that differently?

>Tim

								stan shebs