Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mcnc!unc!rentsch From: rentsch@unc.UUCP (Tim Rentsch) Newsgroups: comp.lang.misc Subject: Re: Teaching object-oriented paradigm to beginners? Message-ID: <632@unc.unc.UUCP> Date: Sun, 18-Jan-87 19:39:10 EST Article-I.D.: unc.632 Posted: Sun Jan 18 19:39:10 1987 Date-Received: Wed, 21-Jan-87 03:35:30 EST References: <4000001@nucsrl.UUCP> <3288@milano.UUCP> <147@m10ux.UUCP> <624@unc.unc.UUCP> <4176@utah-cs.UUCP> Reply-To: rentsch@unc.UUCP (Tim Rentsch) Organization: CS Dept, U. of N. Carolina, Chapel Hill Lines: 346 Stan, I don't mean to be rude, but your posting completely misses the point. Normally I prefer not to respond point-by-point when replying, but your article contains so much confusion and misinformation that I do not see any reasonable alternative. The original article is here reproduced (in pieces) in entirety, excepting signatures. This was done in the interest of fair presentation -- my apologies to those of you who dislike wading through this kind of quagmire (I dislike it myself). To begin: In article <4176@utah-cs.UUCP> shebs@utah-cs.UUCP (Stanley Shebs) writes: > 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. You take the (implicitly stated) point of view that OBJ2 is synonymous with ADTs. Well, that is a point of view, but it is not the general point of view. Smalltalk is generally considered to be the archetypal OOP language. OBJ2 is not generally considered to be the archetypal ADT language. Furthermore, Smalltalk predates the term "OOP", whereas OBJ2 was introduced long after the term "ADT". It seems to me that you are redefining the term to suit your argument. (Remember, the original poster refered to the "ten year old idea of abstract data types". This idea does not include OBJ2, since OBJ2 did not then exist.) Also, your last sentence starts the trend of your article to argue that OBJ2 is "better" than Smalltalk (and by implication that ADT's are "better" than OOP). If you want to believe that ADT's are better than OOP (or that OBJ2 is better than Smalltalk), fine, but that is not the issue; the issue is how are they different. More generally, your tone is one of debate. My tone is one of explanation. The original poster asked if someone could explain how OOP is different from ADT's; this explanation is what I set out to give. Your debate style attitude does not contribute to explaining your point of view. > >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". On the contrary, the phrase "compile time" is not misleading, nor is it irrelevant. Languages which are strongly typed (i.e., type is determined and checked by compiler) are RESTRICTED as to what programs are legal (i.e., "what can be expressed") when compared to languages which are "typeless". I confess to not being familiar enough with OBJ2 to know this, but I assume that in OBJ2 the "type" (OBJ2 may call it something different) of a variable is known and checked by the compiler. If so, then what can be expressed is different that what could be expressed if the language were "typeless", (i.e., in the sense that Smalltalk is typeless). If not, then how does the language represent ADT's, since variables are "typeless"? Contrary to what you assume, I said what I meant, and was making a statement about variables, not values of variables. The difference is significant, and non-trivial. I did not claim that polymorphism is unique to Smalltalk, or even that it is unique to OOP. I accept that OBJ2 supports polymorphism, under the guise of "parameterized objects" (are these like parameterized types?) and "subsorts" (are these like subclasses?). But, Smalltalk's polymorphism does not come "under the guise" of some special mechanism -- EVERY procedure is polymorphic, in the sense that no special mechanisms or constructs (such as "parameterized objects" or "subsorts") must be used to allow fully polymorphic use of the procedure. This flexibility is the clearest and most identifiable distinction between OOP and ADT's. The last three sentences, when read in conjunction with your earlier claim that "OBJ2 has everything Smalltalk has", raise an interesting question. In OBJ2, can the value of a variable be an object of any type at any time? If so, then why is polymorphism available (only) under the guise of parameterized objects and subsorts? If not, then how can OBJ2 have everything that Smalltalk has? > >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. It is true that Smalltalk supports incremental compilation, but that fact had nothing to do with my statement. The point is, when writing a method (procedure) in Smalltalk, the operations provided by the variables and parameters are not known, and, even in theory, *unknowable*. It is true that, IF they exist at all, those operations will exist in the set of ALL operations, from any class. But, the previous statement is a tautology -- it must be true in ANY programming language. Since it must be true in any programming language, saying it is also true in Smalltalk is a rather weak statement. From your statement about "a Unix Smalltalk compiler" I can only conclude that you have a severe misunderstanding both of Smalltalk and of the the point I was making. Yes, it is true that compiler would have to know what operations to include -- and, from my previous paragraph, we know that that set would be ALL operations. That does not affect what the programmer knows when writing a Smalltalk method, nor could it without changing the Smalltalk language. > >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. Again, you misunderstand. My statement had nothing to do with incremental compilation -- the point is that even in a statically compiled OOP language we do not (in general, cannot) know the "type" (e.g., operations) of variables and parameters. And, although OOP does not require incremental compilation, OOP as typified by Smalltalk does *provide* incremental compilation, and this provision might be an argument in favor of Smalltalk over OBJ2. (Again, I confess not knowing enough OBJ2 to be definite -- which is why I said "might".) While not germane to a discussion of the differences between OOP and ADT's, this observation is certainly germane to a discussion of which of Smalltalk and OBJ2 is "better"; once you start down the path, you had better be prepared for someone else to follow it. > > ... 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! :-) :-) :-) There EXIST specifications which do describe a methods behavior. But, any such specifications are NOT present within Smalltalk. ADT languages have specifications explicitly provided as part of the program. Smalltalk programs do not. Yes, all programs fit at least one specification. Whether that specification is given along with the program is another matter. > >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. [This excerpt is so elliptic that I had to go back to a copy of my original posting to understand it. The issue at hand is that Smalltalk does not have specifications or type declarations, whereas ADT's do.] It is not clear what "concepts" you intend being compared here, but there is clearly a (large) conceptual difference. The central point in OOP is that we don't know (and don't want to know) how an object will behave in response to some message. Contrast this with ADT's where specification of behavior is required (and, by implication, desireable). Opposite points of view always constitute conceptual difference, in my book. > >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. (Here we go again on "OBJ2 is the one true ADT language" kick. Sorry, that just isn't the general opinion.) Certainly other languages support polymorphism, but A is independent of B iff A can exist without B *and* B can exist without A. A language which supports OOP will support polymorphism, so the statement "Polymorphism is independent of OOP ..." is just wrong. As to my point, it is not the polymorphism but the EASE of writing VERY polymorphic code (emphasis added for clarity) which separates OOP from ADT's. Lots of languages are polymorphic -- few are as polymorphic as Smalltalk. No ADT language with which I am familiar is as polymorphic as Smalltalk. Is OBJ2 as polymorphic as Smalltalk? You offer no evidence, one way or the other. Even if OBJ2 is as polymorphic as Smalltalk, does that mean ADT's (as generally understood) are as polymorphic as OOP? No, it does not. > >(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. (The repetition of my "vague" characterization is the kind of inflammatory statement that does nothing to contribute to the discussion. Vague statements can be useful in explaining concepts. By giving warning of the vagueness, I had hoped to clarify the explanation following, while avoiding the kind of childish response exhibited by the posting. I see my hope was in vain.) Denotational semantics is only one formal model of describing programs; there are others. Whether the distinction between program and data is really there, or is "artificial", denotational semantics cannot tell us, for it is only one point of view, not THE point of view. Furthermore, the discussion is of ADT's, not denotational semantics; apparently you have them confused. "Once again", the sentence begins, and says something for the first and only time. Is this an inflammatory tactic, or just sloppy language? And, not to put too fine a point on it, I did not say "equivalence" of data and operation, I said inseparability. Binding together of operation and data is supported by many languages, including both ADT's and OOP -- I never said OOP was "unique" in this. What makes OOP different *from ADT's* is the degree to which the operations are thought to be intrinsic rather than extrinsic. As to whether "equivalence of data and operation ... is an essential of any halfway-decent programming" -- well, the question is not whether it is a good thing, but to what degree and extent it is present in each of OOP and ADT's. > 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? Oh, if you understand OOP in terms of actors, I can see why you're confused. (half :-) Afterthought: I wonder if the etymology of OBJ2 is "object oriented extension to abstract data types"? If so, that would explain a lot. ---------------------------------------------------------------- Finally, a parable (true story): Once upon a time there was a scientific researcher who used rats in experiments. He needed some rats for some new experiments, and got them from a local rat supply house. Now, these rats just did not behave as he expected. So, he ran some control experiments, duplicating experiments he had done years previously. Sure enough, the results came out different. Even though he had been using the same rat supply all these years, he suspected that the rats of the present were different in some way from the rats of the past. So, he called up the rat supply house to inquire. "Those rats you sent over last week. Are they the same kind of rats as you sent me five years ago?" "Yes, sir. Those rats are identical to the previous rats." "No chance there could be even a small difference?" "No, sir. Absolutely identical." At this point the researcher was at a loss for explanation. Something had to be different, and he couldn't figure out what it was. In desperation, he asked again: "Are you absolutely sure that the rats I just got are EXACTLY the same as the rats I got five years ago." "Yes, sir. Those rats are absolutely identical to the ones you got before. In fact, they're better!" "So, they *are* different." "No, absolutely identical." "Well, then they can't be better." "Yes, they ARE better." (End of parable. I leave it to your imagination as to whether the rats were identical, or were instead "better". I will say that they were only one or the other, as indeed they could not have been both.) The point is that we are discussing the DIFFERENCE between ADT's and OOP. If ADT's are better than OOP, as you seem to imply, then they must also be different. How are they different? That is the question we are trying to answer, and about which you say very little. cheers, Tim