Newsgroups: comp.object Path: utzoo!utgpu!watserv1!watdragon!lion!bamcpherson From: bamcpherson@lion.uwaterloo.ca (Brent McPherson) Subject: Re: Which OOPL is the best? Message-ID: <1991Mar26.165615.6062@watdragon.waterloo.edu> Sender: daemon@watdragon.waterloo.edu (Owner of Many System Processes) Organization: University of Waterloo References: <1991Mar25.045952.813@agate.berkeley.edu> Date: Tue, 26 Mar 1991 16:56:15 GMT Lines: 111 Summary: 1) learn Eiffel 2) play with smalltalk 3) use C++ Lengthy discussion of reasoning behind this approach: 1) learn Eiffel. (ie. Read several good books on object-oriented programming) First, read Bertrand Meyer's book Object-Oriented Software Construction. The book is an excellent introduction to object-oriented programming and it well-written and easy to understand. The book is largely language independent but provides examples in Eiffel. A good second book would be Grady Booch's Object-Oriented Design with Applications. Also, the exposure to Eiffel gives you a feel for what features the ideal OOPL should possess. I think Eiffel is conceptually the best OOPL since it combines the best features of all other OOPLs (and some unique features also). o static typing o generic types and constrained genericity o exception handling and garbage collection o multiple inheritance, dynamic binding o ability to rename inherited features o ability to selectively export features to other classes (much nicer and more controlled than friend classes in C++) o software engineering support (ie. pre/postconditions etc.) o etc... In reality, however, Eiffel is not very useful since there is only one compiler (available from ISE) and it is only available on a limited number of platforms). Furthermore, the compiler [pre 2.2] was very slow and did not produce very good code (possibly because of the intermediate generation of C code and the fact that C compilers do not know about object-oriented programming and the unique optimization problems it presents). Another problem with Eiffel was the high cost dynamic binding (and the fact there is no way to specify early-binding). This results in slower, larger object code that cannot be fine-tuned easily. There is a post-processor that optimizes the C code produced by the compiler (which can remove some unneccessary dynamic binding) but this was buggy and added alot of extra overhead to compile times. My experiences are based on re-writing a moderately sized C program in Eiffel using the OO programming paradigm. The resulting program was faster to develop, easier to maintain, more consistent, and provided greater functionality than the comparable C program. The executable, however, was over three times larger than the C program and much slower (even when compiled with no runtime checking enabled). The solution was realizing that the Eiffel program could not compete with the C program on speed so I made the Eiffel program *smarter* than its C counterpart by saving calculation results, data caching etc. 2) Play with smalltalk. Samlltalk is widely available and Smalltalk interpreters are much cheaper than Eiffel licensing fees. The main drawbacks of Smalltalk is that is doesn't have static type checking which (IMHO) is a prerequisite for production-quality code (since many common errors are not found at compile-time and can go undetected in the code). [Aside: It is interesting to not that many Smalltalk programmers introduce their own primitive form of type checking to Smalltalk. This type checking is enforced by using special naming conventions that make type unintentional "type violations" easier to detect. (ie. aList, aStack, etc.)] Finally, Smalltalk interpreters can be much slower than compiled code for computationally expensive calculations. 3) Use C++. Now that you know all about object-oriented programming you can use C++ the way it was meant to be used without getting bogged down in all the extra syntactic suger of C++ (ie. operator overloading, implicit type conversions, etc.) As you become more competent with object-oriented programming you can gradually introduce these extra features as needed (without forgetting of the essential characteristics of object-oriented programming). C++ also allows the programmer to address real-world efficiency concerns by allowing inline methods and non-virtual methods (than act the same as a function call in non-OOPLs). My own experience is that programmers who are first exposed to a *pure* OOPL can make the transition to C++ faster than C programmers and initially produce better abstractions (ie. classes) than the C programmers. [Note: by my definition C++ is not pure because you can still use C++ for non object-oriented programming (ie. structured programming) while a language such as Eiffel only provides language support for classes and objects] These conclusions are largely based on personal experience. [I had programmed in C for over 5 years but approached object-oriented programming from the Eiffel/Smalltalk route. I also personally prefer C++ because of the flexibility of implementation that C++ allows (giving me greater control over the performance of my code)] In conclusion, I think that OOP is a paradigm that can be applied to any language and that individual concerns should govern the choice of which OOPL to use for a particular situation. Each OOPL, however, has something to offer a programmer who is attempting to learn OOP without getting caught up in language/implementation restrictions of a particular OOPL. -- Brent McPherson (bamcpherson@lion.waterloo.edu)