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 AlanFrom: 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