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> <jls.669956945@rutabaga>
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)
