labc-1ia@web-4d.berkeley.edu (Andrew M. Choi) (03/25/91)
Hi. I know the subject of this article may imply the imminent arrival of language war (oh no!), please, that is not my intention of posting this article. To minimize the "flame" activity, would you please send reply to me directly? Thanks. Anyway, let me get to the point ... I learned C++ a year ago, and have been ever since frustrated by its limitation (no flames on this, please). Since I believe that OOP will stay around for a while, I want to learn a new OOP langauge which encompasses most (if not all) of the OOP concepts. I asked 3 different people, and they gave me 3 different replies with different reasons: "Learn Smalltalk. It is the language from which C++ is based upon." "Learn CLOS, it is the most powerful OOPL you will ever know." "Learn Eiffel, it is the *ONLY* other OOPL (besides C++) used in the real world. The others are all toy languages." So, which one should I learn? I want to learn one that is hopefully the "superset" of all the other OOPL's, that is, I don't really have to learn new concepts as I go from 1 OOPL to another. Furthermore, it would be nice if the language is not a *toy* language, though this is not a requirement. Would someone please help me out? I don't want to spend all my time learning dozens of OOPL's, only to find out that there is still a better OOPL to learn. Thank you very much for your help. Name: Andrew Choi Internet Addr: achoi@cory.berkeley.edu Tel: (415)848-5658 #include <std/disclaimer.h>
gyro@kestrel.edu (Scott Layson) (03/26/91)
In article <1991Mar25.045952.813@agate.berkeley.edu> labc-1ia@web-4d.berkeley.edu (Andrew M. Choi) writes: >Would someone please help me out? I don't want to spend all my >time learning dozens of OOPL's, only to find out that there is >still a better OOPL to learn. Why not? There probably always will be better ones being developed. Once you learn two, the third will be much easier, and the fourth easier yet. The languages you listed are all good suggestions. I would add Haskell; although I don't know it, I have heard some very interesting things about it, and would like to learn it myself. -- Scott Layson Burson Gyro@Reasoning.COM
jls@rutabaga.Rational.COM (Jim Showalter) (03/26/91)
>"Learn Smalltalk. It is the language from which C++ is based upon." Funny--most Smalltalk people blast C++ for NOT being a "pure" OO language like Smalltalk. I don't think C++ is based on Smalltalk other than in philosophy. >"Learn CLOS, it is the most powerful OOPL you will ever know." It is also the rarest. >"Learn Eiffel, it is the *ONLY* other OOPL (besides C++) used in the > real world. The others are all toy languages." Eiffel is rarely used in the real world, and the percentage relative to C++ grows less rapidly. My advice? Stick with C++. Much as it makes me cringe from an aesthetic standpoint, I believe C++ will be the dominant OO language for the next decade. Definite job security. P.S. You never said what it was about C++ that frustrated you. -- ***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd ever be able to find a company (or, for that matter, very many people) with opinions like mine. -- "When I want your opinion, I'll read it in your entrails."
px@fct.unl.pt (Joaquim Baptista [pxQuim]) (03/26/91)
Smalltalk: For me, it's the purest of them all. Clean enough, excelent programming environment, reasonably fast for some jobs. I produced a toy compiler in Smalltalk/V for a fast PC. Compilation was fast enough, about half a second for each source file. Execution was horrible, since I compiled to objects, and used objects to represent activation frames and such. My final idea is that it's fast enough to do a lot of flexible things, like user interfaces, and that it's horrible to do one thing a lot of times, like executing a sequence of "instructions" very fast. All in all, it was a pleasure to use, and final speed could have been obtained by implementing a bytecode interpreter in any traditional language. CLOS: Don't know it. Heard some good things about it, though. Eiffel: I never used the language, but I've read the book. For me, Eiffel is definitely in the right direction. If I wanted to do some real work out there, I'll probably be using it. It's a strongly typed language, but I think the type system is flexible enough to work. C++: I've teached it, but I did not used it so much :-) It misses some points that some consider relevant to "true" OO programming, like good polymorphism (memory fails here: this point intentionaly left vague) and garbage collection. Some thing garbage collection is not really useful, but one quickly changes its mind after starting to decide where and who destroys which objects. One gets tempted to either copy everything or else look really well at ones program, and that is sometimes very difficult. Dangling pointers are just everyday's problems. Although C++ is strongly typed, you will have to circumvent the type system and use casts almost everywhere if you need generic code. Final opinion: Learn at least Smalltalk and Eiffel. You will learn techniques that will always be useful, even if you end up programming in C++ for the rest of your days. And you will have a perspective to judge the continuous flame wars in comp.lang.c++ :-) -- Joaquim Manuel Soares Baptista, aka px@fct.unl.pt, px@unl.uucp Snail: CRIA, UNINOVA, FCT/UNL, 2825 Mt Capar
drich@klaatu.lanl.gov (David O. Rich) (03/27/91)
In article <jls.669956945@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes: >> My advice? Stick with C++. Much as it makes me cringe from an >> aesthetic standpoint, I believe C++ will be the dominant OO >> language for the next decade. Definite job security. Up until recently I would not have recommended C++ as the OOPL of choice. As I learn more and more about C++ -- what it is and what it is all about -- I must reconsider. It seems to me that C++ is all about flexibility, e.g., being able to express an OO solution exploiting various OO styles. This is quite an attractive feature especially for research-oriented groups still grappling with OO methods appropriate for their particular domain (note that I'm using the term "method" very loosely here). And with the whispers of exceptions and templates (coming to a compiler near you) I'm just about ready to give in to the irresistible pull. But there is still this concern I have about all this power and flexibility (uh oh, the double-edged sword analogy...I knew it!;-). Just how can I enforce a particular OO method once I've decided what is right for me? For example, suppose I want to maximize reusability within a particular domain. Just how do I keep satellite projects in line and enfore reusability standards across the domain? (We all know how easy it is to let deadlines drive software quality, etc.) With these kinds of questions in mind, I am very much interested in work on C++ systems that enforce a particular OO method. The Demeter system falls in to this category. What I'd like to see is a tailorable system that will let you identify stress points in your OO method and then enforce them (CASE anyone?). -- David Rich | Military Systems Analysis Group Email: dor@lanl.gov | Mail Stop F602 Phone: (505) 665-0726 | Los Alamos National Laboratory FAX : (505) 665-2017 | Los Alamos, NM 87545
bamcpherson@lion.uwaterloo.ca (Brent McPherson) (03/27/91)
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)giddy@astrix.trl.oz.au (David Giddy) (03/27/91)
In article <1991Mar26.165615.6062@watdragon.waterloo.edu>, bamcpherson@lion.uwaterloo.ca (Brent McPherson) writes: [deleted] > > 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. > I would like to bring Brent up to date on Eiffel as I believe that most of his criticisms have now been addressed. - Eiffel is available from ISE on nearly all the major UNIX platforms. - Their current compiler (version 2.3) is much faster than previous compilers and is quite useable. The optimizer now works and produces code that is reasonably compact (for object oriented languages). - The Eiffel language is now in the public domain and controlled by an industry consortium. - A German company (SIG Computer GmbH) has announced a compiler for Eiffel on both UNIX and PC/DOS (announced at TOOLS Paris and CeBit in Hanover, but not yet released). Other PC and Mac versions are apparently under development by other companies. In this group I have seen people time and again say that Eiffel is the best Object Oriented language currently available but then qualify the statement with reservations about it being single sourced and slow. These qualifiers have nothing to do with the language, only the implementation. Now that Eiffel is in the public domain, why not support the language and encourage other software houses to get behind it (listening Sun, Microsoft, Borland,...??). How about a GNU version of Eiffel so that we can all try it out for free ? Lets not be tied to C hacks for ever more ! (ducks for cover :-) Regards, David. P.S: I am currently involved in a medium sized project using Eiffel. Disclaimer: My opinions are not necessarily the opinions of my employer. ______________________________________________________________________________ David Giddy, Voice: +61 3 541 6388 Fax: +61 3 543 1944 Telecom Research Laboratories, P.O. Box 249, Clayton, Victoria 3168, AUSTRALIA Internet: d.giddy@trl.oz.au X400: g=david s=giddy ou=trl o=telecom prmd=telecom006 admd=telememo c=au
jls@rutabaga.Rational.COM (Jim Showalter) (03/27/91)
>Just how can I enforce a >particular OO method once I've decided what is right for me? Good question. This is where language simply runs out of steam, and the OTHER 95% of the problem rears its ugly head. This is where process, methodology, community hygiene, tool support, etc are all dominant concerns. While I do believe that implementation rules (e.g. no gotos) can help at the micro-level (and can even be enforced with a tailorable compiler [we sell one for Ada]), they don't mean diddly at the architectural/design level. I've seen projects jump into OO all happy and smiling and then fall over dead because they didn't change their paradigm, their management structure, their way of assessing progress ("Hey, start typing: we need to get our SLOC rates up!"), their accounting system (SLOC = money), etc etc etc. These infrastructural issues are so daunting they dwarf mere language issues...which may explain why so many people are content to focus on just the language issues--it's EASIER! -- ***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd ever be able to find a company (or, for that matter, very many people) with opinions like mine. -- "When I want your opinion, I'll read it in your entrails."
melling@cs.psu.edu (Michael D Mellinger) (04/01/91)
In article <jls.669956945@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes:
Eiffel is rarely used in the real world, and the percentage relative
to C++ grows less rapidly.
My advice? Stick with C++. Much as it makes me cringe from an
aesthetic standpoint, I believe C++ will
be the dominant OO language for the next decade. Definite job
security.
P.S. You never said what it was about C++ that frustrated you.
Furthermore, learn to program C++ on an IBM PC. Definite job
security. Over 25 million machines with more everyday. It's too bad
we all have to accept the world the way it is. Anyone want to trade
an MBA for a master's in computer science?
-Mike