jonathan@pitt.UUCP (Jonathan Eunice) (02/12/88)
The Truth is that "object-oriented" is a bad name. A really,
really bad name. A horrible name. It's far too long to say or
write naturally. So we look to shortcuts, especially in speech, where
using the "object-oriented" adjective (eg, in every fourth sentence as
most OOPSLA attendees do for 3-5 days running) has been medically
proven to cause brain damage. So we end up speaking in gobbledyguck
like OOP, OOD, OODB, OODBMS, etc. This makes you sound as though you
just finished an extended tour of duty with DARPA. The situation is
not much better in writing, where a reference to object-oriented
programming or object-oriented databases can take a huge chunk of a
printed line, and looks really ugly. (If you haven't tried writing
about your favorite object-oriented database system yet, trust me in
this.) Using numerous acronyms in your paper isn't any more elegant
than it is in speech.
A Modest Proposal:
'Oriented' is a tepid word; I don't know who decided that it is a
necessary adjunct to 'object', but it seems to have stuck. We don't
need it. Drop it wherever you see it. Cut it out. Say and write
'object' instead of 'object-oriented'. There's no loss in effect or
meaning, because the 'orientation' didn't mean much it the first place.
Either you're using objects or you're not. Compare:
object programming object-oriented programming
object systems object-oriented systems
object databases object-oriented databases
object design object-oriented design
See how much better that is? If not, try saying the phrases a few
times. I can pretty well promise you'll be a happier, more fulfilled
person for the loss in dead weight.
------------------------------------------------------------------------------
Jonathan Eunice ARPA: jonathan%pitt@relay.cs.net
University of Pittsburgh jonathan%pitt@cadre.dsl.pittsburgh.edu
Dept of Computer Science UUCP: jonathan@pitt.UUCP
(412) 682-0574 {allegra,bellcore,cadre,idis,psuvax1}
!pitt!jonathan
BITNET: jonathan@pittvms.BITNETjss@hector.UUCP (Jerry Schwarz) (02/16/88)
In article <2792@pitt.UUCP> jonathan@pitt.UUCP (Jonathan Eunice) writes: >The Truth is that "object-oriented" is a bad name. A really, >really bad name. A horrible name. It's far too long to say or >write naturally. I agree with Eunice's distaste for the phrase "object-oriented". (Although "truth" isn't a concept I would apply to tastes.) But for different reasons. The thing that distinguishes "object-oriented" approaches from others is not the presence or emphasis of objects (modifiable data structures), but the use of inheritance. Inheritance is just about the only major feature that Smalltalk and C++ have in common. CLU (for example) provides extensive support for "objects", but does not have inheritance, and so it is not usually regarded as "object oriented". Thus the phrase "object-oriented" is misleading. Jerry Schwarz Bell Labs
mjl@ritcv.UUCP (Mike Lutz) (02/16/88)
In article <10077@ulysses.homer.nj.att.com> jss@hector (Jerry Schwarz) writes: > >Inheritance is just about the only major feature that Smalltalk and >C++ have in common. Not true -- unless you consider data encapsulation and multiple objects of the same abstract type as "minor" (I certainly don't). Ada and Modula provide the former, but few languages provide the latter. In any event, these are orthogonal to (and as important as) inheritance. For the record: Peter Wegner presented a paper at OOPSLA 87 which gave a taxonomy of various forms of "objectness". Worth a read, as it does try to provide consistent terminology. May be quickly dated, however, given the current interest in OOP, OOD, OODBMS, and all the other OO thingys around. Mike Lutz rochester!ritcv!mjl -- Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {allegra,seismo}!rochester!ritcv!mjl CSNET: mjl%rit@csnet-relay.ARPA
jss@hector.UUCP (Jerry Schwarz) (02/17/88)
In article <209@ritcv.UUCP> mjl@ritcv.UUCP (Michael Lutz) writes: >In article <10077@ulysses.homer.nj.att.com> jss@hector (Jerry Schwarz) writes: >> >>Inheritance is just about the only major feature that Smalltalk and >>C++ have in common. > >Not true -- unless you consider data encapsulation and multiple objects >of the same abstract type as "minor" (I certainly don't). Ada and >Modula provide the former, but few languages provide the latter. In >any event, these are orthogonal to (and as important as) inheritance. > I will rephrase my observation: Inheritance is the major feature that distinguishes "object-oriented" Smalltalk and C++ from other languages such as CLU, ML, Ada, Modula-2, ... that support notions of user defined types. I consider data encapsulation a very important aspect of programming, and both languages support it to some extent. But the static types of C++ are so different from the dynamic types of Smalltalk that I don't believe it is fair to say that they share data encapsulation features. As for "multiple objects of the same abstract type" I can't imagine a language that has a notion of user defined type that doesn't support multiple things (objects or values) of a type. In C++ the "assignment operator" does value copy, while the assignment of Smalltalk is pointer copy. While, each of these can be used to simulate the other, they are so different that it is hard for me to say that C++ and Smalltalk even share a notion of abstract type. >For the record: Peter Wegner presented a paper at OOPSLA 87 which gave >a taxonomy of various forms of "objectness". Worth a read, as it >does try to provide consistent terminology. Thanks for the pointer. He certainly supports my observation. I quote An object-based language is object-oriented if its objects belong to classes and class hierarchies may be incrementally defined by an inheritance mechanism. That is: object-oriented = objects + classes + inheritance I think he's wrong in one respect. If there were an applicative language that supported inheritance, I would bet that "object-oriented" enthusiasts would call it one of theirs. Jerry Schwarz
mjl@ritcv.UUCP (Mike Lutz) (02/17/88)
In article <10085@ulysses.homer.nj.att.com> jss@hector (Jerry Schwarz) writes: > >I will rephrase my observation: Inheritance is the major feature >that distinguishes "object-oriented" Smalltalk and C++ from other >languages such as CLU, ML, Ada, Modula-2, ... that support notions of >user defined types. > >I consider data encapsulation a very important aspect of programming, >and both languages support it to some extent. But the static types >of C++ are so different from the dynamic types of Smalltalk that I >don't believe it is fair to say that they share data encapsulation >features. "Sharing" is a relative term. Compared to Ada, Modula-2, etc., I'd say C++ & Smalltalk have a lot in common. [enter JJ Starbuck mode] "But then, as my pappy used to tell me, a difference of opinion is what makes a horse race." [end JJS mode]. >As for "multiple objects of the same abstract type" I can't imagine >a language that has a notion of user defined type that doesn't >support multiple things (objects or values) of a type. All depends on what you man by "type". Back in the early days of Pascal, when it was the language that was going to save the world, A. N. Haberman wrote a short paper which basically said that Pascal's "types" were simply syntactic sugar for good ole' data structures. His definition of "type" was one where the internal state of an element of the type (read: object of the class) could only be altered by operations defined on the type (read: encapsulation). Now Ada and Modula provide encapsulation, but do not provide "types" in this sense, as you can't create multiple instances of the package/module that provides the encapsulation. (You might be able to cobble something up using Ada tasks, but then you deserve the trouble you'll create for yourself). If Pascal has "types", then you agree with Jerry (I think); if you think "types" should meet this more restrictive interpretation, you agree with me (and Haberman - appealing to authority). It's also possible, of course, to provide such types without inheritance, or with other mechanisms such as parametric types (a weak form of which is provided by Ada generics). >>For the record: Peter Wegner presented a paper at OOPSLA 87 which gave >>a taxonomy of various forms of "objectness". Worth a read, as it >>does try to provide consistent terminology. > >Thanks for the pointer. He certainly supports my observation. I >quote > > An object-based language is object-oriented if its objects > belong to classes and class hierarchies may be incrementally > defined by an inheritance mechanism. That is: > > object-oriented = objects + classes + inheritance No problem here (and no conflict either). My point was that objects + classes (or instances + types) are interesting in their own right, even without inheritance. I applaud Wegner's effort to bring some order out of terminological chaos. But as Jerry has already shown in his "applicative language" example, there are holes in this classification scheme already. [I'm not a fan of applicative languages, so I'd probably consider such a language with inheritance a platypus - an interesting genetic experiment, but well out of the main stream :-)]. Mike Lutz rochester!ritcv!mjl -- Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {allegra,seismo}!rochester!ritcv!mjl CSNET: mjl%rit@csnet-relay.ARPA
johnson@uiucdcsp.cs.uiuc.edu (02/17/88)
/* Written 10:02 am Feb 16, 1988 by jss@hector.UUCP in uiucdcsp:comp.lang.smalltalk */ >I will rephrase my observation: Inheritance is the major feature >that distinguishes "object-oriented" Smalltalk and C++ from other >languages such as CLU, ML, Ada, Modula-2, ... that support notions of >user defined types. A few days ago I was asked which feature of o-o programming was most important, message sending or inheritance. I instantly replied "message sending". I have thought about this question a lot, so I knew the answer. By message sending, I mean run-time binding of procedure calls based on the class of the arguments, or, more usually, the first argument. Inheritance can be simulated (with a bit of work) by delegation. O-o programming is data hiding carried to an extreme, not only does the programmer not know an object's implementation, but the compiler doesn't, either. ML, Ada, and Modula-2 do not have this kind of polymorphism. In these languages, each procedure call can be bound to the target procedure at compile time. (I leave off CLU because I don't know enough about it.) Late bound procedure calls ensure that the only thing a programmer has to know about an object is its behaviour, its class is irrelevant. >I consider data encapsulation a very important aspect of programming, >and both languages support it to some extent. But the static types >of C++ are so different from the dynamic types of Smalltalk that I >don't believe it is fair to say that they share data encapsulation >features. This seems a very odd comment. I program in both languages. Virtual functions in C++ let you do 99% of what you want to do in Smalltalk. Now that C++ has multiple inheritance, you can simulate the complete lack of type checking in Smalltalk with abstract classes. There is little practical difference between the way one uses classes in the two languages. (Note the word "practical", almost nobody makes use of the fact that classes are objects in Smalltalk.) >As for "multiple objects of the same abstract type" I can't imagine >a language that has a notion of user defined type that doesn't >support multiple things (objects or values) of a type. "Abstract type" means something different from "type". It means that the user of an object is only concerned with the operations possible on the object, not on its class. Try having an array of numbers in Ada, where one number is an integer, another a float, another a user defined type like a polynomial, etc. This is easy in Smalltalk, and doable in C++ if you create classes for integers and floats. >In C++ the "assignment operator" does value copy, while the assignment of >Smalltalk is pointer copy. While, each of these can be used to >simulate the other, they are so different that it is hard for me to >say that C++ and Smalltalk even share a notion of abstract type. I suppose it is because I am an unconverted Smalltalk programmer, but I always use pointers to objects, never variables that contain objects. Thus, my way of programming in C++ is isomorphic to programming in Smalltalk. Smalltalk is better than C++ because it has garbage collection, closures as first class objects, classes as objects (the tricks one can do!), an outstanding programming environment, and a huge library of mostly well designed classes. None of these have anything to do with its position as an object-oriented language. To forstall arguments, C++ is better than Smalltalk because it is faster, you can make standalone executables with it, and it is more portable, since it doesn't need graphics. I am writing an operating system in C++. Otherwise I use Smalltalk.
gvcormack@watdragon.waterloo.edu (Gordon V. Cormack) (02/18/88)
> > object-oriented = objects + classes + inheritance > > > I think he's wrong in one respect. If there were an applicative > language that supported inheritance, I would bet that > "object-oriented" enthusiasts would call it one of theirs. > > Jerry Schwarz I think not. The whole idea behind object oriented programming is that objects are entities that have a state, and that state is altered only by "sending messages" to the object. Please do not take this as an endorsement of OOP -- regardless of how you care to define it, I still believe it is largely a case of "Emperor's new clothes". -- Gordon V. Cormack CS Dept, University of Waterloo, Canada N2L 3G1 gvcormack@waterloo { .CSNET or .CDN or .EDU } gvcormack@water { UUCP or BITNET }
db@its63b.ed.ac.uk (D Berry) (02/22/88)
In article <10085@ulysses.homer.nj.att.com> jss@hector (Jerry Schwarz) writes: >In article <209@ritcv.UUCP> mjl@ritcv.UUCP (Michael Lutz) writes: >>For the record: Peter Wegner presented a paper at OOPSLA 87 which gave >>a taxonomy of various forms of "objectness". Worth a read, as it >>does try to provide consistent terminology. > >Thanks for the pointer. He certainly supports my observation. I >quote > An object-based language is object-oriented if its objects > belong to classes and class hierarchies may be incrementally > defined by an inheritance mechanism. That is: > > object-oriented = objects + classes + inheritance > >I think he's wrong in one respect. If there were an applicative >language that supported inheritance, I would bet that >"object-oriented" enthusiasts would call it one of theirs. > >Jerry Schwarz Sorry, I don't understand this. Why isn't it possible to have an object-oriented applicative language using this definition of object-oriented? Or are you referring to another part of the article?
jans@tekcrl.TEK.COM (Jan Steinman) (02/24/88)
(Quoted sections from johnson@uiucdcsp.cs.uiuc.edu are enclosed in "<>".) <...almost nobody makes use of the fact that classes are objects in Smalltalk...> An evolving style of programming here at Tek (best summarized as "Class Variables Considered Harmful To Inheritance"), involves making heavy use of class instance variables for encapsulating information common to all instances of a class. For instance, individual Strings need to know how to concatenate themselves with each other, find Characters in themselves, and other things that are unique to individual Strings. But if one considers that the state of being a String involves some knowledge of line termination conventions on a particular system, then it becomes obvious that String class (which is where the information concerning the state-of-being-a-String, or "Stringedness", is stored) should maintain that information. In the past, we would have stuffed a line terminator in a class variable and been happy -- Strings and their subclasses could access it directly -- very efficient. But what about an application that needs to cross boundaries -- have Unix Strings and MS-DOS Strings at the same time? Class variables are shared among subclasses. By forcing Strings to treat their class as an object by asking it for line termination information, subclassing easily handles the situation. The subclass, say "PcString", is a bona-fide object, with its own instance variables, one of which contains the line termination sequence unique to MSDOS. Inherited methods that deal with lines work with either Strings or PcStrings. <Smalltalk is better than C++ because it has... classes as objects (the tricks one can do!)...> This has gotten a bit long-winded, but to summarize: classes-as-objects is an under-utilized, under-appreciated concept in Smalltalk, that has practical, intuitive applications. It is also misunderstood and misused, and people exploring "the tricks one can do" with it have tended to give it a bad rap by writing obscure, "tricky" code. <To forstall arguments, C++ is better than Smalltalk because it is faster, you can make standalone executables with it, and it is more portable... I am writing an operating system in C++. Otherwise I use Smalltalk.> Here, here! When you need a screwdriver, don't try to make do with a hammer! And if you pound nails with that screwdriver, you deserve the results! :::::: Software Productivity Technologies --- Smalltalk Project :::::: :::::: Jan Steinman N7JDB Box 500, MS 50-470 (w)503/627-5881 :::::: :::::: jans@tekcrl.TEK.COM Beaverton, OR 97077 (h)503/657-7703 ::::::