daemon@cornell.UUCP (05/31/84)
From: Pavel.pa@XEROX.ARPA Nessus, In reference to your `brash statement', ``If in an introductory programming course, you teach anything other than an object oriented programming language, such as Lisp, CLU, or Smalltalk (sorry folks, Pascal does not count), you are brain-damaging your students almost as much as if you taught them Basic,'' 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 personally favor the first definition, but don't see how CLU gets in there at all (by LISP I'll assume you mean the Flavors-enhanced variety). Could you please explain? 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. Pavel Curtis Computer Science Laboratory Xerox Palo Alto Research Center decvax!cornell!pavel Pavel.pa@Xerox.ARPA
mwm@ea.UUCP (06/01/84)
#R:mit-eddi:-197900:ea:5400005:000:2033 ea!mwm Jun 1 15:42:00 1984 /***** ea:net.lang / mit-eddi!nessus / 8:29 am May 30, 1984 */ And for a final brash statement: If in an introductory programming course, you teach anything other than an object oriented programming language, such as Lisp, CLU, or Smalltalk (sorry folks, Pascal does not count), you are brain-damaging your students almost as much as if you taught them Basic. -- -Doug Alan /* ---------- */ Depends on what you mean by "object-oriented" (aren't buzz words wonderful?). I intend to use the terminology laid down in a SNot paper (I don't have it handy - I'll post the reference later (I promise!)), like so: Data Encapsulation: Programming constructs that allow you to hide the insides of data structures and user routines from the outside world. Example: Modula II. Data Abstraction: Data encapsulation with the added ability to use the encapsulated object with different types. Example: CLU. Object-oriented Language: A language where all functions and structures have to be encapsulated. Example: Smalltalk is to strong. Concurrent Euclid is about right. [Disclaimer: The above are being quoted from memory, and any errors or deficiencies are solely my fault.] By these definitions, LISP isn't object-oriented, and CLU allows you to write as if it were object-oriented. LISP is a problem because it isn't a single language. What variant were you refering to in the above? Surely not LISP 1.5? To comment on the statement: If you meant that teaching languages that don't support data abstraction (such as C), then I agree. Data encapsulation just isn't sufficient. If you mean truly object-oriented, then I disagree. Having free-standing (non-encapsulated) functions is like goto's: If the language has all the right constructs, then you don't need them; if it doesn't, then there are occasionally times when you do. Since I don't know what "all the right constructs" are in this case, I still want free-standing functions. If you know what the right constructs are, please let the rest of us in on it! <mike
@MIT-MC:NESSUS@MIT-EECS (06/03/84)
From: Doug Alan <NESSUS%MIT-EECS@MIT-MC.ARPA>
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-MCnessus@mit-eddie.UUCP (Doug Alan) (06/06/84)
Actually, gotos in a programming language (with labels) are winning as long as the language only allows one to goto in a forward direction. They're even better if the language provides for the passing of arguments to the goto destination. If you can only goto in a forward direction, then you can't get spaghetti. Both Lisp and CLU have these gotos. In Lisp, they are called "throw"s and in CLU they are called "exit"s. Both allow you to pass arguments. What do people think about tail recursion? For those who don't already know, tail recursion occurs when the interpreter or the compiler realizes that the result of calling a procedure is merely going to be be returned, and therefore it doesn't have to save any state on the stack for the current procedure. Thus one can recurse infinitely without ever getting a stack overflow. Both Scheme and Logo support this. A tail recursive procedure call is in effect a generalization of a goto (though it looks like a procedure call), because you never have to return from a tail recursive procedure call if you don't want to. It is a goto that allows the passing of arguments. Is this a good thing? Or should it be shunned like gotos? And for a final brash statement: If in an introductory programming course, you teach anything other than an object oriented programming language, such as Lisp, CLU, or Smalltalk (sorry folks, Pascal does not count), you are brain-damaging your students almost as much as if you taught them Basic. -- -Doug Alan mit-eddie!nessus Nessus@MIT-MC "What does 'I' mean"?
mwm@ea.UUCP (06/07/84)
#R:mit-eddi:-197900:ea:5400007:000:1000 ea!mwm Jun 6 22:20:00 1984 As promised, here is info from the SNot paper on data abstraction, encapsulation and object oriented programming. The paper is: 'Data Abstraction, Data Encapsulation and Object-Oriented Programming,' by A.T. Cohen (are you out there, A.T.?), Sigplan Notices Vol 19, No 1, pg 31. His definitions: "An object is a data structure together with a set of procedures that operate on it." Data encapsulation "localizes (and conceals) the details of an object." To get data abstraction, "extend the idea of user-defined types to allow user-defined capsule types." "Programs in which all (logical) data structures are encapsulated are called object-oriented." He (?) then goes on to point out that support for object-oriented programming is orthogonal to support for data abstraction, but languages that support object-oriented programming usually support data abstraction, since they complement each other. As usual, any typos, mistakes, and problems with the above are undoubtedly my fault. <mike
brad@umcp-cs.UUCP (06/15/84)
>1)"An object is a data structure together with a set of procedures that >operate on it." >2)Data encapsulation "localizes (and conceals) the details of an object." >3)To get data abstraction, "extend the idea of user-defined types to allow >user-defined capsule types." >4)"Programs in which all (logical) data structures are encapsulated are >called object-oriented." > <mike It seems to me that this 4 point definition is fulfilled by the language Ada. I am surprised to see that no one has mentioned this before. For further references see the book "Software Engineering with Ada" by Grady Booch. (Specifically the topics of 'information hiding', 'data abstraction' and 'packages') Further discussion can also be redirected to net.lang.ada and/or the arpanet mailing list info-ada@usc-eclb. Brad Balfour arpa brad@maryland csnet brad@umcp-cs uucp ...{seismo,allegra}!umcp-cs!brad
nessus@mit-eddie.UUCP (Doug Alan) (06/15/84)
From: brad@umcp-cs.UUCP > It seems to me that this 4 point definition is fulfilled by the > language Ada. Well perhaps using these over-simplified defintions, you could construe Ada to supporting data abstraction, but not really even then. To do a good job with data abstraction, you really need heap-based allocation with automatic garbage collection. Ada doesn't support this. Also, Ada's private type system is completely messed up. "Private types" have their assignment and equality operations provided by the system. This is the wrong thing since two abstract objects may be different from the concrete view (the view that Ada's "=" operation takes), but equal from the abstract point of view. And the assignment operation is supposed to copy the object being assigned, but the system provided operation can't do that right either. You can do a little better with "limiited private types". You can then provide your own "=" operation, but you still can't provide your own ":=" operation. And even if you do define your own "=" operation for a limited private type, Ada then won't allow you to use "=" on a composite type that contains that type. Basically, Ada is just gross. Bleah! -- -Doug Alan mit-eddie!nessus Nessus@MIT-MC "What does 'I' mean"?