Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site cornell.UUCP
Path: utzoo!linus!vaxine!wjh12!genrad!decvax!harpo!floyd!vax135!cornell!daemon
From: @MIT-MC:NESSUS@MIT-EECS
Newsgroups: net.lang
Subject: Gotos in programming languages
Message-ID: <287@cornell.UUCP>
Date: Sat, 2-Jun-84 17:42:47 EDT
Article-I.D.: cornell.287
Posted: Sat Jun  2 17:42:47 1984
Date-Received: Wed, 6-Jun-84 02:40:44 EDT
Sender: daemon@cornell.UUCP
Organization: Cornell Univ. CS Dept.
Lines: 81

From: Doug Alan 
     From: Pavel.pa at XEROX.ARPA
		. . .

     I must admit to being completely in the dark as to your
     definition of `object oriented'.  If it means the late-binding of
     procedures on the basis of the type of one or more of their
     arguments, then neither CLU nor LISP (in general, unless you were
     referring to Flavors) support this style.  If you just mean an
     ability to cluster the operations of an abstract type into a
     black box, then Smalltalk and CLU get in, but LISP still remains
     in the cold.

I think that the idea of generic operations is extremely important,
but I don't see why the term "object oriented" should imply that a
language supports generic operations for all objects -- though I know
Smalltalk people use the term that way.  To me, "object oriented"
means that the semantics of a language are such that a variable does
not represent a unique piece of storage, but instead names an "object"
that lives along with an infinite number of other objects in object
space.  Every object is associated with a set of operations that can
be used to operate on the object, and every object belongs to a class
of objects with the same operations.  Each object can have many names,
and each object exists forever -- at least conceptually.  All objects
are made up of other objects, except for primitive objects.  The set
of primitive objects is specified by the language.  All objects can be
returned from procedures, without being turned into garbage by a
stack-based allocator, because in an object oriented language there
aren't any second class objects.

Lisp, CLU, and Smalltalk are all object oriented, by this definition.
An object that cannot be operated on by the operations of the object
that it is made of, is an abstract object.  In Smalltalk and CLU, all
objects are abstract objects.  In Lisp, only primitive objects are
abstract objects.  The practice of using only the operations that are
directly associated with an object and not using the operations of the
object it is made of is usually called "data abstraction".  In
Smalltalk and CLU, data abstraction is enforced by the language.  In
Lisp, data abstraction is possible, it is just not enforced by the
language.  The programmer has to promise not to cheat.

Perhaps, I should have said, "If in an introductory programming
course, you teach anything other than a programming language that can
foster data abstraction, you are brain-damaging your students almost
as much as if you taught them Basic."  I'll admit that I could
probably invent an object oriented language that is not conducive to
data abstraction, but this would be pretty obscure, so I don't think
it requires a whole lot of discussion.

     Also, I would be very interested in a more complete description
     of your views regarding this `brain-damage' you speak of.  Two
     major questions come to mind immediately: What bad habits and
     wrong thinking are being forced onto these students by
     non-object-oriented languages and what are the important
     attributes of the languages that fit your definition of
     object-oriented that prevent this damage?  I have my own answers
     to these questions but would be interested in seeing yours.

I think that the most useful concept a programmer can ever learn is
data abstraction.  It is clean, simple, and powerful, encourages
modularity, makes clear the difference between behavior and
implementation, allows the easy construction of powerful, general
tools, results in a smooth, beatiful, consistent view of the universe
where things already in the programming language are not significantly
different from what one can add himself, and becomes a wide and clear
doorway to many other important concepts, such as generic abstraction,
control abstraction, etc.

But if someone starts off learning Pascal, he probably thinks he is
learning a learning a structured language because he learned how to
program without gotos.  But so what?  It's not the microscopic
structure that's most important, it's the macroscopic structure.  And
Pascal brain-damages people, because they think they've learned how to
write structured programs, and they haven't.  And now that they're
convinced that they're writing structured programs, they'll probably
probably never learn how to.

				-Doug Alan
				 mit-eddie!nessus
				 Nessus@MIT-MC