Xref: utzoo comp.lang.c++:3043 comp.lang.lisp:1663 comp.lang.modula2:1429 comp.lang.prolog:1674 comp.lang.smalltalk:998 comp.lang.misc:2835 Path: utzoo!attcan!uunet!seismo!sundc!pitstop!male!sun-arpa!ames!mailrus!bbn!bbn.com!mthome From: mthome@bbn.com (Mike Thome) Newsgroups: comp.lang.c++,comp.lang.lisp,comp.lang.modula2,comp.lang.prolog,comp.lang.smalltalk,comp.lang.misc Subject: Re: C++ vs. Other OOLs Message-ID: <38836@bbn.COM> Date: 19 Apr 89 04:58:14 GMT References: <2602@ssc-vax.UUCP> <5947@pdn.paradyne.com> Sender: news@bbn.COM Reply-To: mthome@vax.bbn.com (Mike Thome) Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 135 In article <5947@pdn.paradyne.com> alan@rnms1.paradyne.com (Alan Lovejoy) writes: >In article <2602@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes: >>I would like to start a discussion concerning C++ and ool's. I would >>like to see comparisons of C++ vs. other object oriented languages such as: >>C++ vs. Lisp >> I'd like to know how C++ stacks up against the others as far as: Just to add to an otherwise complete (from my personal knowledge) synopsis of object oriented languages: I assume that the previous message's discussion of Lisp's "object orientedness" was based solely on the "defstruct" construct covered in CommonLisp The Language. It is certainly worth mentioning that a true object-oriented Lisp system has been accepted into the "official" CommonLisp set by the CL cleanup committee. I'll try covering a few of the original message's points with regards to CLOS (CommonLisp Object System), but a more complete discussion is available in a book by Sonya Keene entitled "Object Oriented Programming in CommonLisp" (or somesuch - Addison Wellesly, I believe)... >-- Portability -- >1) Language portability is a function of how similar the compilers for different >systems are and the breadth and depth of STANDARD functions that are provided >via STANDARD interfaces. This is largely an extra-linguistic issue that >has more to do with the history and culture of different language communities >than it has to do with the technical merits of languages as languages. >Smalltalk is the winner here, with C++ a strong runner-up. I'm not sure I see how this is *at all* a linguistic issue - it sounds as thought you are talking more of programming environment and fidelity of implementations than anything else. Frankly, I'm surprised that C++ is listed in the same sentence as Smalltalk in this regard - Smalltalk is an entire integrated environment implemented in itself... the only other similar systems that come close are Lisp Machines (from various vendors) running Flavors - perhaps some of the pascal P-machines might be grouped in the same way. >2) The other issue is how many different systems have implementations of your >language available. >C++ wins hands down on this point. Agreed. I would add that most machines that run commonlisp are also able to run at least one of the CLOS implementations (I know of at least two - PCL, which runs on just about any CL out there - certainly all the major vendors are covered, and TI has a native version (Symbolics has announced one as well, but it isn't expected for several months). PCL has the advantages that it is free (thanks to the good guys at Xerox) and easily portable. Native versions are faster). >-- Speed -- >Speed is just as much an implementation issue (compiler AND host CPU) as it is >a function of the language (syntax, semantics). Actually, I don't think >syntax has any effect on speed at all, unless the translation and execution >of the program are both being timed (e.g., an interpretive implementation). >The semantics of a language affect speed of execution in several ways: >... There is no such thing as a free lunch. I'll not itemize responses to this section: a summary of this whole issue is covered by that final line: Expressive power usually requires more machinery to support it - it is exactly the same issue as the Lisp/Smalltalk vs. C/ModulaII camps (which we will NOT go into here - suffice it to say it all depends on what you want to do and how you want to do it... and possibly what sort of hardware you want to do it on). This applies to CLOS vs. C++ just as well: C++ can be fast because much of the "object oriented"ness can be "compiled out" and requires little runtime support (not to be taken as other than praise - C++ does very well at furthering the "charter" of C). CLOS (for instance) must be able to deal with a far more complex (dynamic) runtime environment than C++, as well as such things as multiple class inheritance, multiple argument dispatch, etc. Even so, the better CLOS implementations pay surprisingly little cost over funcall. (BTW, some people in the object-oriented community have object to calling CLOS "object oriented" because it is not based on the usual message passing protocols - rather it uses the generic function metaphor). Some of the Lisp-running hardware is able to provide much better run-time support for CLOS than any conventional-architecture machine will be able to for C++ (or successors). Both Symbolics and TI have loadable microcode sets capable of implementing the basics as instructions. >-- Object Orientation -- >The definition of "object oriented language" is open to debate. Instead of >debating the minimum set of attributes that an object-oriented language >should have, it is more instructive to consider the ideal case. > First, some definitions: A class is a set of values and the functions/relations >defined on the members of that set. An object is an instance of a class which >represents one of the values in the set, that is, one of values of the class. > Inheritance is the ability to define a new class in terms of its differences >(extensions, deletions, changes) from some other pre-existing class. CLOS Generalizes that to "... from some other pre-existing (required for instance instantiation) class or classes". >The ideal object-oriented language would: >1) Have user-definable classes. CLOS satisfies this requirement - methods may be specified not only on defined classes, but also built-in data types (ie. integers vs. floats vs. complex vs. ratios ... etc) and even single values. >2) Have class inheritance. CLOS has this. In addition, it allows inheritance from multiple (possibly disjoint) classes. >3) Allow function/operator overloading. CLOS has this. Any function may be specialized on any one or more of its required arguments. (there is no difference between operator and function in lisp. Note that macros and special forms may not be specialized). >4) Be completely polymorphic. >Smalltalk and Lisp are highly polymorphic. Next is Objective-C and Prolog. >Then C++, and last is Modula-2. I would like to see the definition of "polymorphic" (for my own education). As mentioned somewhere above, CLOS has rejected the message sending/passing syntax of most OOL's in favor of generic dispatching (required by multiple argument dispatch): where in most OOLs, one might say something like "(send :do-something-message )", you'd say "(do-something )" in CLOS for equivalent functionality. In CLOS, however, you are allowed to specialize the behavior of a "message" to be based on any (one or more) of the arguments passed to the generic function. Anyway - I expect that your (informed!) choice of OOP Language will almost definitely follow your favorite philosophy of programming: if you are most productive in C, C++ is right for you... if LISP, than CLOS. Now, to close, I'll ask if anyone would like to comment on the seeming inconsistency of C evolving into a higher-level language (via C++)? At OOPSLA last summer, we were amazed to hear C++ people talking about adding garbage collection to the language! I'd hate to see what people think of as "C" turn into lisp-with-C-like-syntax. The big win of C is that it encorporates into a small language a number of very powerful abstractions with low (or zero) performance cost. Lets face it - if speed were all I cared about, I'd use Fortran exclusively... but I couldn't do without recursion for very long, so next choice is C. If I wanted limited OOP, I'd go for C++. Full dynamic environment? LISP. Full dynamic OOP? CLOS! Does anyone have an opinion as to how far up the "ladder of abstraction" C can be pushed without destroying its best features (low-level expression = speed)?