Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!utah-cs!shebs From: shebs@utah-cs.UUCP (Stanley Shebs) Newsgroups: comp.lang.misc Subject: Re: Teaching object-oriented paradigm to beginners? Message-ID: <4196@utah-cs.UUCP> Date: Wed, 21-Jan-87 14:32:06 EST Article-I.D.: utah-cs.4196 Posted: Wed Jan 21 14:32:06 1987 Date-Received: Thu, 22-Jan-87 00:21:56 EST References: <4000001@nucsrl.UUCP> <3288@milano.UUCP> <147@m10ux.UUCP> <624@unc.unc.UUCP> <4176@utah-cs.UUCP> <632@unc.unc.UUCP> Reply-To: shebs@utah-cs.UUCP (Stanley Shebs) Organization: PASS Research Group Lines: 204 In article <632@unc.unc.UUCP> rentsch@unc.UUCP (Tim Rentsch) writes: >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. And here I thought *I* was clearing up confusion and misinformation! I'm not trying to debate, but to clarify that there are multiple points of view on OOP and ADTs. There were statements with which I disagreed, and the nature of the net is that controversial things will be challenged. Saying that a controversial statement is an "explanation" is not going to save one from that challenge! >>>OOP is not (in my opinion, at least!) simply a special case of >>>abstract data types. I tend to view them as being more alike than different, but that is probably because I see similarities between things rather than differences. There are good reasons to see similarities in a field (CS) which is prone to reinventing wheels on the basis of trivial distinctions. Unfortunately, there is a lot of disagreement on what is "trivial" and what is not... >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. OK then, I'm ignorant. What are ADTs, and what is the archetypal ADT language? Some of the points made subsequently (but not reproduced here) seem to assume particular limitations, but it was not at all clear what those limitations are supposed to be. For instance, an ADT without subtypes ("subsorts") is worthless as far as I'm concerned. I like OBJ2 because it has abstract data types without being crippled by them... >Smalltalk is generally considered to be the archetypal OOP language. Perhaps, but let's not confuse details of Smalltalk with the definition of object-oriented programming. Any definition of OOP should encompass Simula, C++, the assorted Lisp object systems, and actors. Older folks seem to consider Simula as the archetypal OOP language, by the way, while Scheme fans (and Abelson/Sussman's textbook) equate objects with functional closures, and suggest that specialized OOP systems are unnecessary. >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". There are a lot more kinds of language implementations than most people realize. Lisp alone has a gamut from pure interpretation to pure compilation, including some strange combined approaches. There are Pascal interpreters too, but that doesn't mean Pascal is not strongly typed. A Common Lisp program with declarations probably will not compile if there are type mismatches - does that mean that Lisp is strongly typed? References to "compile time" when discussing language semantics are mistakes. The meaning of programs is at issue, not language implementation strategies... >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. For openers, OBJ2 is based on term rewriting, and doesn't have a compiler at all! The word "sort" is used instead of "type", because "type" is not a particularly precise term, and has undesirable connotations. The only variables are logical variables bound in environments, and their type is always known, although perhaps not very accurately. By "not very accurately", I mean that because in both Smalltalk and OBJ2, types live in a hierarchy, one always knows that the type of something is whatever is at the top of hierarchy. In Smalltalk, you know that everything is of class "object", for instance. OBJ2 proposes a "universal sort" U, which includes all types as subtypes. This is also like Common Lisp's type "t". I recommend the paper on OBJ2 in POPL 85; it is quite readable, and avoids most of the category theory and logic that makes much modern ADT work incomprehensible to ordinary mortals. As a Lisp/Prolog hacker, I generally abhor any notion of strong typing, but OBJ2's type system is so high-powered that it does seem not restrictive at all. (I hope I'm not overstating OBJ2's capabilities - not having used it, I may be projecting features that I would incorporate in an "ideal" language!) >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. If you don't know what subsorts or parametrized objects are, then how do you know they're "special constructs" and not something available by default? In fact they're declaration mechanisms, and don't affect the rewrite rules directly. >In OBJ2, can the value of a variable be an object of any >type at any time? Yes, to the extent that OBJ2 has variables. But variables in a rewriting system are not locations that you get data from and store data into - they are more like mathematical variables that serve only to connect two places together. To find out more, read any Prolog textbook. >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. Yes, I must admit to having confused optimization with necessity, and only partly saved myself by talking about construction of code and interpreters etc. In the total absence of information, a Smalltalk object must be prepared to do something with any operation whatsoever, which means that the method lookup process might have to go through all sorts of tables trying to match names. You couldn't even have a fixed-shape table, because the system might dynamically create new types (classes) and everybody must augment their lookup tables to accommodate the new classes. The performance of this sort of thing is inherently dismal, but that's the price of flexibility. I don't know if OBJ2 supports dynamic definition of new types, but this particular issue touches on some of the deepest issues in type theory. You can hack out systems like Smalltalk to do it, but key aspects of behavior will be operationally-defined at best. I suppose most people don't care whether the system will crash if you redefine class Class, because they're not going to do it anyway, but there is a fair amount of current research directed at the question of what *should* happen. >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. In OBJ2, the only "specifications" are the rewrite rules, which, as it happens, are also the program. Perhaps this means OBJ2 is not an ADT language... >> >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.) It's not at all clear to me how the assertion that polymorphism is a good thing leads to the assertion that OBJ2 is the one true ADT language. As I mentioned earlier, I am a Lisp and Prolog person. I've never used OBJ2, and probably never will, because I like to write real programs, and OBJ2 just doesn't have the performance. I do like to think about the next generation of languages, and OBJ2 seems closer to that next generation... >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. Read the POPL paper - I don't plan to type it all in myself. >What makes OOP different *from ADT's* is the degree to which the operations >are thought to be intrinsic rather than extrinsic. Defining a concept by an attitude doesn't seem very precise? >> 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 :-) Sigh, a frivolous response to a serious question... >Afterthought: I wonder if the etymology of OBJ2 is "object oriented >extension to abstract data types"? If so, that would explain a lot. Ask Goguen, not me. >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. I don't think I ever claimed that ADTs are "better" than OOP. Seems unlikely, since I believe them to be basically equivalent. I wonder if you were offended by my disparaging Smalltalk with respect to OBJ2. Don't get me wrong - I think Smalltalk is a great language, I have all the Smalltalk books, I'm putting a section on Smalltalk internals in my thesis. But let's not try to equate Smalltalk with objects; it will only confuse some and disenchant others. Rather, let us identify the important concepts of languages and define them precisely, so that future languages can incorporate those concepts both elegantly and efficiently. >Tim stan