C++ vs Eiffel vs Smalltalk (warning--long language war)
& Samuelson bruce@ling.uta.edu
you did so voluntarily--don't complain that I posted it.
As an outside observer, I've been reading the, ahem, sharp comments in
comp.lang.c++ by Stroustrup, Meyer, and others on the "Ethics of
technical discussions." I'd like to follow up on the part of the
discussion regarding the relative popularity of these languages.
An article by Jim Adcock in comp.lang.c++ cited metrics for comparing
C++ and Eiffel based on the number of references in the literature and
the number of products shipping. C++ came out far ahead in both
categories. The article then asked the reader to draw conclusions.
We need to look at more data first. Consider the grandaddy of
programming languages. In Workstation News, May 1991, page 11, an
article cites statistics from the International Data Corp.:
"Fifty-seven percent of all applications worldwide are written in
COBOL... 80 billion lines of COBOL code exist in the world today.
Currently, an estimated 3 million COBOL programmers work in the
information processing industry."
By this measure Cobol is superior to C++ which is superior to Eiffel.
C, Fortran, and many of their procedural cousins would also end up
ahead of C++ in the pecking order.
One might be tempted to reject Cobol because it is not object
oriented. Not to worry. Object oriented extensions are in the works.
Won't the result be ideal? It will start from a huge intsalled base
and add technical enhancements. Think of all the existing code that
can still be used. Think of all those programmers who won't have to
be completely retrained.
Analogies between Cobol --> Cobol++ and C --> C++ are deliberate.
Cobol++ (or whatever its name turns out to be) and C++ may make sense
in projects where the dominant factors are historical legacies
consisting of installed code and of programmers' experience. In
projects without these constraints one is free to place more weight on
the technical merits of the programming language and its compilers and
libraries. I think pure OO languages such as Eiffel and Smalltalk are
good candidates. Use Eiffel when you want strong typing, safety
through contracts, static compilation, and hopefully efficiency.
However, perhaps the Eiffel people could offer us more evidence that
efficient compilers exist. For that matter, I wouldn't mind seeing
more C++ benchmarks too.
If you want dynamic typing, incremental compilation, dynamic
compilation, better portability than C, an extensive and mature class
library, robustness, a superb development environment, simpler syntax
than perhaps any other language, purity of paradigm, beauty of
implementation (usually), garbage collection, exception handling,
support for persistence, and many other features that make programming
easy and intuitive, use Smalltalk-80. (I'm not saying that Eiffel
lacks many of these--I'm just more familiar with Smalltalk.) The
struggles C++ programmers document each day in comp.lang.c++ are
usually a piece of cake in Smalltalk. Coffee mocha cake with
chocolate frosting, as a matter of fact.
In fairness to C++, I have advised people to use it at times. An
owner of a small software company who ruled out Smalltalk for various
reasons asked me for advice re/ C++ versus Eiffel. His product needed
to run portably under MacOS and Windows. I said to postpone the
decision if possible to see what commercial Eiffel development
environments come out in the next few months. If they are good,
choose Eiffel. If he had to choose now (which was last spring),
choose C++. He much preferred Eiffel but wasn't sure he could wait.
Let's watch and see whether C++ becomes the Cobol (or Cobol++) of the
1990s (commercial success, technical and aesthetic disappointment).
I've been predicting for some time that this will happen, but I hope
I'm wrong. Come on Adele! Come on Bertrand! I'm rooting for you.
Disclaimer: I have direct experience with Smalltalk, but only second
hand knowledge of C++ and Eiffel through publications and through the
experience of friends. I nevertheless stand by the opinions
expressed.
--
**********************************************************
* Bruce Samuelson Department of Linguistics *
* br...@ling.uta.edu University of Texas at Arlington *
**********************************************************
Jim ADCOCK
I started tracking these kinds of references-cited statistics some
years ago out of frustration for the lack of ANY kind of hard data
from any of the fans of this, that, or the other language. My intent
for myself was to have some kind of reality check for where the various
languages really are at *in the real world* as opposed to how many
flames one finds for or against a particular language on the notes.
I was serious when I said people should draw their own concluions from
the numbers. For example, some programmers may choose to see Eiffel
as a small but rising language, and think that now is an ideal time
to jump on their bandwagon. Other programmers may see the small size
of Eiffel as an indication that supporting tools will not be readily
available. Other programmers may see the large numbers of C++ programmers
as being the lambs led to slaughter. Its you're choice how to interpret
the data. The point is is that I am offering you data by which you
can make up your own mind. I am not vacuously claiming that such-and-
such a language is good, or that such-and-such a language is bad, or
that this that or the other language designer is some kind of evil lying
bastard. I simply suggest that data speaks louder than [name calling]
words, and that the fans of one or another language would do better
posting supporting data [***data that can be confirmed independently***]
to back up their cause rather than calling each other names.
I guess, personally, my skepticism of OO languages without many followers
relates to my experience a half dozen years ago with Objective-C,
where some programmers fell in love with that language, sold it
to my management at the time, and continued to pursue it to the death
in spite of problems with only having one single vendor. And meanwhile
C++ was taking off, compilers were available from a large number of
vendors, etc.... So, my advice would be that programmers should keep
their eyes open, choose the horse they ride carefully, but not to
fall too much in love with one or the other of the beast. Languages
ought to be programming tools, not programming religions. And [in my
experience] its not much fun being a martyr to a lost cause.
I've heard claims of the large number of COBOL programmers, but I cannot
find the number of magazine references, books, magazines, products
etc that I would expect to find corresponding to these large numbers
claimed. If there are such large numbers of COBOL programmers,
all I can conclude is that they don't read, they don't write, and
they don't buy product. They must all be sitting in the dark somewhere
using pencils to print their COBOL programs onto paper forms.
[personally, I *hate* numbers like the "3 million Cobol programmers"
quoted above that one cannot confirm from primary sources. On a similar
subject locally we tried to verify some other "number of programmers"
quotes and came to the conclusion that the numbers quoted were off
by about a factor of four. So don't believe these kinds of numbers
unless you have the chance to confirm them independently.]
Seriously, here's some more numbers to put things into a wider
prospective:
Number of references to a particular language in the magazine articles
and abstracts of the Computer Select database:
C 22595
Cobol 1948
C++ 4300
Pascal 2325
FORTRAN 1316
Smalltalk 816
Eiffel 171
Note: the above number for "C" has not been corrected for about a 50%
mishit rate on the "C" word where it is not the "C" language that
is being referred to. For example "Howard C. Smith" generates a false
hit. Therefor I suggest the reader discount the "C" numbers by about
50% [but not "C++" -- which doesn't generate such false hits]
Number of software products relating to a particular language in the
software products section of the Computer Select database:
C 7547
COBOL 3403
FORTRAN 1920
Pascal 1691
C++ 178
Smalltalk 17
Eiffel 2
Here again "C" generates some false hits -- but a lower percentage
of false hits than in the magazine references.
----
Again, here's some data. If you feel you have some other "hard"
data supporting one language or the other, let's see it. Otherwise,
let's knock off with the name calling and the vacuous opinions about
which language is best. We've all heard it all before, and generally
expressed more creatively.
Bruce R. Miller
In article <1991Sep05....@microsoft.com>, Jim ADCOCK writes:
> ...
> Number of references to a particular language in the magazine articles
> and abstracts of the Computer Select database:
>
> C 22595
> Cobol 1948
> C++ 4300
> Pascal 2325
> FORTRAN 1316
> Smalltalk 816
> Eiffel 171
Hmm, Lisp isn't used _at all_!!!?
Well, it is data and you've described how you collected it; that is
good. But this only counts the _mentions_; I would expect that older
established languages would often go unmentioned; A numerical
application, well _of_course_ we're using Fortran!; Business:
_of_course_ we're using Cobol... You might expect C to be the same
case, but C & Unix are sort of a bandwagon these days, very "in".
On the otherhand, I would expect languages like c++ and Eiffel to be
sufficiently "in" and unusual that they would most likely be
consistently mentioned.
So, I wouldn't draw conclusions comparing usage of Cobol to C, but C++ and
Eiffel, maybe. As you say; Who knows what it means?
> Note: the above number for "C" has not been corrected for about a 50%
> mishit rate on the "C" word where it is not the "C" language that
> is being referred to. For example "Howard C. Smith" generates a false
> hit. Therefor I suggest the reader discount the "C" numbers by about
> 50% [but not "C++" -- which doesn't generate such false hits]
Why 50%? You could run a check for the `languages' "B", "D" etc. and
come up with a somewhat meaningfull zero level.
> Number of software products relating to a particular language in the
> software products section of the Computer Select database:
>
> C 7547
> COBOL 3403
> FORTRAN 1920
> Pascal 1691
> C++ 178
> Smalltalk 17
> Eiffel 2
This statistic would seem less succeptible to the problems I mentioned
above. 'Course I feel obligated to point out that the fact there are no
Lisp `products' whereas there are so many C ones, probably just points
out how many tools and things you _need_ to program in C!!! :>:>:>
(sorry, couldn't help it!)
Jim ADCOCK
|
|In article <1991Sep05....@microsoft.com>, Jim ADCOCK writes:
|> ...
|> Number of references to a particular language in the magazine articles
|> and abstracts of the Computer Select database:
|>
|> C 22595
|> Pascal 2325
|> Cobol 1948
|> FORTRAN 1316
Lisp 1311
|> Smalltalk 816
|> Eiffel 171
Objective-C 100
|
|Hmm, Lisp isn't used _at all_!!!?
No, its just that I'm not very good at guessing who on the net
is going to be offended if I leave off their pet language.
My intent was to show the major historical language in perspective
to the major OOP language. Thus, Lisp wasn't on the list. Basic
probably should be, but the word "basic" appears so commonly in normal
English usage that one can hardly search on it. But, I did manage
to successfully seach for it in the product list below.
|Well, it is data and you've described how you collected it; that is
|good. But this only counts the _mentions_; I would expect that older
|established languages would often go unmentioned; A numerical
|application, well _of_course_ we're using Fortran!; Business:
|_of_course_ we're using Cobol... You might expect C to be the same
|case, but C & Unix are sort of a bandwagon these days, very "in".
Hm, I thought C++ and Windows are "in" nowadays.... but oh well.
In any case, one can expect to find a monster in Loch Ness, but,
if one cannot find any data to support one's position, most engineers
and scientists would discount your expectations. My expectation would be
that if hoards of people are still using Cobol and Fortran, then there
would be hoards of business people still trying to make a buck off of it
-- even if it means coming out with an OOCobol, OOFortran, or whatever.
|On the otherhand, I would expect languages like c++ and Eiffel to be
|sufficiently "in" and unusual that they would most likely be
|consistently mentioned.
Well, if you read the numbers you'd see that at least half you
expectation is wrong. Which was the point of the numbers.
Yes, there are lots of interpretations people can put on the
numbers, but, if a person's expectations and the numbers don't
match, then there must be something wrong with that person's expectations.
This is why we tend to be skeptical of scientists who have lots
of theories but who never make any measurements.
|Why 50%? You could run a check for the `languages' "B", "D" etc. and
|come up with a somewhat meaningfull zero level.
The 50% estimate was more meaningful. I looked up about 50 of the hits,
kept a hit count, and it literally came out 24/26. If it had come
out about 21/29 or something, then I would have said 40%. Since there's
no way to automate whether a "hit" is meaningful or not other than having
a human read the word in context, all I can do is estimate. Based on
my studies, I believe the 50% is a reasonably good estimate. If you don't
buy that, then you can go to the original data I'm using, namely the
Computer Select database and do your own numerical studies. Which is
the whole point. It does readers on the net no good to have people post their
"conclusions" unless their data is readily available for other people
to review and make their own judgements on the matter. Personally,
I think the Computer Select database is a really cool competitive analysis
tool, and I encourage people to check it out, if they haven't already.
|> Number of software products relating to a particular language in the
|> software products section of the Computer Select database:
|>
Basic 9882
|> C 7547
|> COBOL 3403
|> FORTRAN 1920
|> Pascal 1691
Lisp 1311
|> C++ 178
|> Smalltalk 17
Objective-C 5
|> Eiffel 2
|This statistic would seem less succeptible to the problems I mentioned
|above. 'Course I feel obligated to point out that the fact there are no
|Lisp `products' whereas there are so many C ones, probably just points
|out how many tools and things you _need_ to program in C!!! :>:>:>
|(sorry, couldn't help it!)
Actually, the real fact [as opposed to your speculations] is that
there are ton of Lisp products. I forgot to check what proportion of
the Lisp products are actually versions of the "Doctor" program, but
that could be an interesting study too. Again, I didn't include Lisp
and Basic because I didn't guess that there would be anyone in my
listening audience who cares. Still, given the high numbers of Basic
and Lisp based software offerings, I'm really surprised at the few
Smalltalk offerings. Do they have problems with run-only licenses
or something?
Bruce R. Miller
In article <1991Sep06.1...@microsoft.com>, Jim ADCOCK writes:
> In article <28930...@ARTEMIS.cam.nist.gov> mil...@FS1.cam.nist.gov (Bruce R. Miller) writes:
> |In article <1991Sep05....@microsoft.com>, Jim ADCOCK writes:
> |> ...
>
> No, its just that I'm not very good at guessing who on the net
> is going to be offended if I leave off their pet language.
Ouch!
1st off, I was half-way kidding you about Lisp -- although it _is_ my
pet language. 2nd, I dont want to get into a long digession about lisp,
especially in this forum. But...
> My intent was to show the major historical language in perspective
> to the major OOP language. Thus, Lisp wasn't on the list.
I'm not sure I understand you here. Depending on what we're talking
about, leaving Lisp out was not necessarily wrong. But for the record:
Lisp is just about as `historical' as you can get: only COBOL is older.
And as far as OOP is concerned, Lisp was used for most of the original
research into OOP, predating everything (I think) short of SIMULA.
And lisp is still a major force in research in OOP (meta-object
protocols and so forth), if perhaps not in actual use. Otherwise, I'm not
sure what `major' means.
Just for the record, you understand. :>
No need to further cater to my tastes though, unless it seems appropriate.
Oh, and you can leave out BASIC, too, as far as I'm concerned :>
> |Well, it is data and you've described how you collected it; that is
> |good. But this only counts the _mentions_; I would expect that older
> |established languages would often go unmentioned; A numerical
> |application, well _of_course_ we're using Fortran!; Business:
> |_of_course_ we're using Cobol... You might expect C to be the same
> |case, but C & Unix are sort of a bandwagon these days, very "in".
>
> Hm, I thought C++ and Windows are "in" nowadays.... but oh well.
>
> In any case, one can expect to find a monster in Loch Ness, but,
> if one cannot find any data to support one's position, most engineers
> and scientists would discount your expectations.
I suppose the reference to Loch Ness is supposed to be an insult?
I think you're misunderstanding my use of the word `expect'. I wasn't
"expecting" something in the data, rather I was "expecting" that there
may be patterns in usage and citation that would make the interpretation
of your data difficult. You counted "mentions" of the languages.
Nothing more, nothing less. You seem to want to interpret "mentions" of
a language as proportional to "usage" of a language. I suggest there
may be a sampling error; the ratio of mentions/uses of certain languages
may be significantly less than for other languages. Specifically, I
know that it seldom occurs to people who use Fortran for numerical work
to mention Fortran; ie, it's so normal that it's not worth mentioning
--- and so it doesn't show up in your measurement. On the other hand,
if they were using C++ (or Lisp!) they probably mention it because it is
unusual. The same thing might hold for business & cobol?
Likewise, I think you misunderstood what I meant by "in"; I didn't mean
to say that everybody was using them but rather that are `hot topics',
ie worth mentioning. Some things get mentioned because management likes
its preconceptions verified.
> My expectation would be
> that if hoards of people are still using Cobol and Fortran, then there
> would be hoards of business people still trying to make a buck off of it
> -- even if it means coming out with an OOCobol, OOFortran, or whatever.
There may (or may not) be a large community of users but unless there is
a need for a variety of products and that community has shown a
disposition to spending money on such products, then there still wont be a
large number of vendors.
> |On the otherhand, I would expect languages like c++ and Eiffel to be
> |sufficiently "in" and unusual that they would most likely be
> |consistently mentioned.
>
> Well, if you read the numbers you'd see that at least half you
> expectation is wrong.
Well, no: see above.
> Which was the point of the numbers.
> Yes, there are lots of interpretations people can put on the
> numbers, but, if a person's expectations and the numbers don't
> match, then there must be something wrong with that person's expectations.
or the numbers.
> This is why we tend to be skeptical of scientists who have lots
> of theories but who never make any measurements.
Or those who take measurements but have no idea of what they measured.
> |Why 50%? You could run a check for the `languages' "B", "D" etc. and
> |come up with a somewhat meaningfull zero level.
>
> The 50% estimate was more meaningful. I looked up about 50 of the hits,
> kept a hit count, and it literally came out 24/26.
Ah, ok so you did follow that up. Sounds ok to me. From the original
post I had thought you had just guessed... sorry.
> ...
> Actually, the real fact [as opposed to your speculations] is that
> there are ton of Lisp products.
Ouch! (again)
> I forgot to check what proportion of
> the Lisp products are actually versions of the "Doctor" program, but
> that could be an interesting study too.
!!! :>:>:>
Richard Bielak
>
>Analogies between Cobol --> Cobol++ and C --> C++ are deliberate.
>
I think the name for object oriented COBOL is "ADD ONE TO COBOL". :-)
...richie
--
*-----------------------------------------------------------------------------*
| Richie Bielak (212)-815-3072 | I don't believe in psychics, because |
| Internet: ric...@bony.com | you have to make an appointment. |
| Bang {uupsi,uunet}!bony1!richieb | |
chuck m durrett
POSTINCREMENT COBOL BY ONE
Mike Khaw
>...Smalltalk marches too
>much to its own tune (no multi-inheritance, proprietary windowing mechanism,
>etc.)
The "proprietary windowing mechanism" is gone as of Release 4. What else
does "etc." cover?
--
Mike Khaw - Domain=kh...@parcplace.com, UUCP=...!uunet!parcplace!khaw
ParcPlace Systems, Inc., 1550 Plymouth St., Mountain View, CA 94043
SRINIVASAN,K
>In <1991Sep9.2...@helical.com> ral...@helical.com (Robb Aley Allan) writes:
>
>>...Smalltalk marches too
>>much to its own tune (no multi-inheritance, proprietary windowing mechanism,
>>etc.)
>
>The "proprietary windowing mechanism" is gone as of Release 4. What else
>
Wait a minute, you are yet to answer the first point in his list. Let
us go to his "etc" after that.
--
SRINIVASAN,K
School of Textile Engineering Georgia Tech.
uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!gt4084c
ARPA: gt4...@prism.gatech.edu
Jim ADCOCK
>>Jim ADCOCK writes
>> Again, I didn't include Lisp
>> and Basic because I didn't guess that there would be anyone in my
>> listening audience who cares.
>No one who cares? I do, quite a bit.
Okay, but the title *did* say we were comparing C++ to Eiffel to Smalltalk.
Why would you expect to see a comparison to Lisp here?
>C++ is a hack/hog
I've heard lots of erroneous arguments that C++ is a hack -- and
a few valid ones, so I'll let that stand. But, I think you better
explain what you mean by C++ being "a hog". Certainly compared to Lisp
[and most other OOPLs] C++ is very frugal in both its development tool
requirements and its run-time/space requirements.
Mike Khaw
-In article <khaw.68...@parcplace.com> kh...@parcplace.com (Mike Khaw) writes:
->In <1991Sep9.2...@helical.com> ral...@helical.com (Robb Aley Allan) writes:
->
->>...Smalltalk marches too
->>much to its own tune (no multi-inheritance, proprietary windowing mechanism,
->>etc.)
->
->The "proprietary windowing mechanism" is gone as of Release 4. What else
->
-Wait a minute, you are yet to answer the first point in his list. Let
-us go to his "etc" after that.
I thought it was obvious by omission :) -- ParcPlace Smalltalk is still
single-inheritance. Now how about the "etc"?
Mike Khaw
>... I presume that means that Smalltalk v4 is calling the local windowing
>mechanism...? If so, that's good news and progress. Assuming that the rest
>of one's code is still portable.
Yes and yes.
>My past impressions of Smalltalk (all with Macintosh implementations,
>which may not be representative :-) were that it was slow, big, and
>awkward for users who found it too disorienting since it resembled
>nothing else. Does v4 "tree-shake" out all the unused code to produce
>an optimal binary image? Has method-lookup speed been optimized so that
>runtime is faster? How does it handle one-button mice (control
>keys?)?
Slow and big: well, it's not C. ParcPlace Smalltalk on Mac doesn't run
on the "compact" Macs (the ones with a 68000 CPU), and it requires at
least 4MB RAM. But it feels reasonably responsive on a IIcx or faster
Mac II and the hardware is getting faster and cheaper. On the Mac, to
some extent we can only do as well as the code generated by MPW C. We
couldn't use Think C because (until recently) it didn't generate 32-bit
code.
Resembles nothing else: Most of the proprietary look is gone. Smalltalk
still has its own conventions about mouse buttons and popup menus,
however. When I was starting out, the main thing I found disorienting
was that there was just so much in the standard class libraries. It was
somewhat analogous to sitting down to an OS I'd never seen before and
trying to figure out what facilities it had so I could use it effectively.
But the browsers and the debugger really help in learning how various
pieces of code work. One of the biggest "aha" experiences I had was
when someone pointed out that one way to unravel how something worked
was simply to interrupt it (with control-C), which would allow you
to bring up a debugger on the running code and then examine variables,
arguments, and step through/into message sends.
Removing unused code: We haven't quite figured out how to do that
automatically and safely, because of the #become:, #perform:, and
#evaluate: messages; e.g., suppose a scan of the running image showed
that class Foo was not used anywhere and had no subclasses. So you
remove it. Sometime later, you open a disk file containing:
Foo new initialize.
You read that into a Smalltalk string named anExpression, and execute:
Compiler evaluate: anExpression.
Oops! (no pun intended). However, there are tools that will allow you
to remove the development environment plus some set of classes that you
specify so that you can deliver images and protect your source code.
Method-lookup: I don't know much about the implementation of method
lookup, but my understanding is that it represents very little of a
method's execution time. Our dynamic translation technology converts
Smalltalk bytecode to native machine code if the latter representation
is not already cached, and saves it in the cache. Subsequent uses
of the same method then execute at full machine speed out of the
native code cache.
One button mice: click = left-button; option+click = middle;
command+click = right. Recently, 3-button mice for the Mac have
become available (Advanced Gravis Supermouse, Logitech Mouseman for
Mac, Mouse Systems A3). None of allows the button mappings that
Smalltalk wants. However, it's easy enough to use another mapping,
and I've implemented that in Smalltalk for the Logitech mouse.
Dave Berry
And Digitalk's Smalltalk/V now runs under Windows/3 and OS/2+PM.
--
Dave Berry, LFCS, Edinburgh Uni. db%dcs.ed...@nsfnet-relay.ac.uk
Are you ready for Pachenka?
Jim ADCOCK
|Well, perhaps an inopportune choice of words. Let's withdraw "hog". I was thinking of the
|double-compilation issue, but that's not really a memory issue, but a filesystem one.
Hardly an argument against the language, given that the vast majority
of C++ compilers sold [or "given away freely" under copyleft restriction]
do not do the double-compilation. Bjarne's decision to implement the
original C++ compiler using "C" as the back-end was a good stategic decision
[IMHO] since it allowed rapid propagation of C++ everywhere, and allowed
him to [relatively] simply introduce language enhancements. Still the
purchasing habits of most compiler buyers seem to be saying that
single compilers are what most people want. [Personally, I don't believe
single verses double is a big deal. A much bigger deal is incremental
verses not-incremental]
|My real objections to C++ are:
|1) syntax and
I believe language designers need to be much more aware of the importance
of syntax to programmers. The attitude of some language designers seems
to be: "Its juust syntax -- who cares?" Whereas the programmers say:
"I care -- its ugly, and its not what I'm use to looking at. I prefer
to continue to use the syntax that I'm familiar with."
Personally, I like most of C++ syntax, excepting the pointer verses
reference mess. I hate the syntax of most other languages, finding
them overly intrusive. The point only being that all of this is
simply a matter of a particular programmer's taste. Some people
like stuff that's more verbose and flowery. Some people prefer stuff
that's short and plain. I just don't believe anyone's going to be
able to squeeze the tastes of all programmers into one mold.
|2) lack of a standard object library;
No problem here -- C++ has dozens of standard object libraries from
dozens of different vendors. :-) Likewise, other languages with more
than one vendor also have at least one object library from each vendor.
It would be *nice* as OOPL languages catch on if the multiple vendors
for each of those languages would be willing to get together and
at least agree to put a subset of those libraries to national or
international standard. C++ is doing this now on a formal basis,
and I guess Eiffel is getting started on a less formal "consortium"
basis, but all this is going to take time for any OOPL.
|other concerns are proprietary ownership by AT&T
It ain't "owned" by AT&T anymore, given that Bjarne published a half
reasonable reference manual on it a year or two ago. If anything,
I'd be worrying that C++ is becoming "owned" by Borland, given
the large number of "C++" compilers they've been selling.
Likewise, sounds like Eiffel is beginning to enter that phase of its
life where multiple vendors are going to be offering more or less
incompatible versions of the language, and then hopefully, someday
for the sake of the Eiffel programming community, those vendors are
going to have to sit down and hammer out their differences, and
decide what really *is* or *is not* going to be in the language.
|but in general I find the syntax learning curve much easier with these
|languages and the presence of a good library of classes is invaluable.
Again, syntax is "programmers choice." But I'd be willing to debate
how "good" some libraries are! :-)
Lawrence E. Fitzpatrick
>...C++ is very frugal in both its development tool
>requirements ...
In fact, I consider this to be one of its major drawbacks. For some
time, there has been an attitude of "yes it's spartan, but you can
always build a browser, interpreter, {insert favorite tool} on top of
it." In my experience, the Unix/C style of development (RCS or SCCS,
make, emacs,...) breaks down very quickly with OOP in general and C++ in
particular, especially with multi-person projects.
Oh well, it's just a matter of time... [yeah Saber, ObjectWorks, Borland, etc]
Regards, fitz
Lawrence Fitzpatrick
Personal Library Software
15215 Shady Grove Rd
Rockville MD 20850
(301)926-1402
...!uunet!plsparc!lef
l...@pls.com
Lawrence E. Fitzpatrick
>The lack of multiple inheritance, however, is what finally drove me away
> from the language.
At the risk of starting a religious war, why is multiple inheritance so
important in Smalltalk? I recognize that it is required in the likes
of C++. Are you interested in MI as an aggregation technique for
reusing implementation (in which case aggregation usually works just fine)?
Or are you interested in MI as a technique to combine classes that specify
behavior only (this can be done rather ad hoc in Smalltalk anyway
because of the lack of type checking and truly dynamic binding)?
Lawrence E. Fitzpatrick
>My real objections to C++ are 1) syntax and 2) lack of a standard
>object library;
Robb, I cannot help piling on. I also find the syntax uncomfortable,
mainly because many things are done as side-effects (e.g., if a member
function is declared "= 0" it makes the class abstract? now that was
intuitive!), terms are hopelessly overloaded (e.g., virtual, static,
"just to save some reserved words"), and the source code is INCREDIBLY
unreadable (e.g., quick! find the member function with the name "doThis"
among 20 other member functions that have argument lists, a non-trivial
classname, and return values! -- realize that a browser REALLY solves
this problem).
But there are a few other things that have been problems in developing
with C++:
- constructors and destructors are "different from" other member
functions (cannot control a return value);
- there is no runtime type information available, so to resolve an
arbitrary type at run time (yes it's necessary) requires techniques that
are against the spirit of the language;
- related to this is the lack of a 'super' class pointer which makes
reorganizing complex class hierarchies a nightmare with potential bugs
that may take quite some time to show up;
- and if I read ONE MORE TIME that a feature was made a certain way
because it would make the compiler-writers' job easier, I'll...
I'll... I'll... phew! -- so the answer is, let 10's of thousands of
programmers suffer with it for years to come rather than let a few
compiler writers suffer with it a few times! (cf. last time I remember
seeing it was JOOP about a year ago in the "exceptions" paper by Koenig
& Stroustrop, I think).
- the class libraries I've seen are difficult to learn and understand,
not to mention that they are all relatively incompatible with ea other
(cf. the author of iostream's article about how bad iostreams is with
MI in one of the JOOP's)
I actually have a few more, but I'm sure you've heard it all before.
David M Geary
]
] >C++ is a hack/hog
]>
]> I've heard lots of erroneous arguments that C++ is a hack -- and
]> a few valid ones, so I'll let that stand. But, I think you better
]> explain what you mean by C++ being "a hog". Certainly compared to Lisp
]> [and most other OOPLs] C++ is very frugal in both its development tool
]> requirements and its run-time/space requirements.
] Well, perhaps an inopportune choice of words. Let's withdraw "hog".
] a memory issue, but a filesystem one.
Good idea to "withdraw hog". Double-compilation is a complete
non-issue...
] My real objections to C++ are 1) syntax and 2) lack of a standard object
]
Affinity for syntax is highly subjective, and, like languages
itself, a religous issue. IMO, syntax is purely asthetic; the
real issue is what one can do with the language.
Lack of a standard object library is a legitimate gripe. Good
point...
] library; and the fact that it is not "purely" OO (whatever that is...:-).
^^^^^^^^^^^^^^^^^^^
I believe that those supporting this viewpoint are simply
parroting dogma that they have heard from supporters of the "pure"
OO languages.
I would really like to see someone expound upon the "whatever
that is" part of the arguement.
Perhaps those supporting C++ should take the following stance:
"I believe that language XXX is a hack, due to the fact that it is
"purely" OO (whatever that is)".
(Insert favorite "purely" OO language for XXX) ...
--
|~~~~~~~~~~ David Geary, Boeing Aerospace, Seattle, WA. ~~~~~~~~~~|
|-----------------------------------------------------------------------------|
|~~~~~~ Seattle: America's most attractive city... to the *jetstream* ~~~~~~|
|-----------------------------------------------------------------------------|
M. Gallo
Geary) writes:
[in response to complaints about C and C++]
> Affinity for syntax is highly subjective, and, like languages
> itself, a religous issue. IMO, syntax is purely asthetic;
It's true that many people overreact to syntax issues (though having
to learn a new syntax is often a pain in the #@!), but I would disagree
that syntax is a *purely* aesthetic issue.
One of my biggest problems with C syntax is operator side-effects.
It allows (and seems to encourage!) cryptic and even unreadable code
while often surreptitiously altering the program's data. What's worse
is that such errors are often very difficult to find later. Clarity
and simplicity should not be so simply put aside.
--
_ /|
Miguel \'o.O'
mga...@ares.calpoly.edu =(___)=
"C is its own virus." U
Eric W. Sink
> Affinity for syntax is highly subjective, and, like languages
> itself, a religous issue. IMO, syntax is purely asthetic; the
> real issue is what one can do with the language.
> Lack of a standard object library is a legitimate gripe. Good
> point...
Now, now, syntax does have *some* meaning. The language should assist
us as programmers in our task. C++ syntax can be downright obnoxious.
It makes for a less readable language, and worst of all, the language
is really hard to parse ! (spoken by a compiler writer)
>] library; and the fact that it is not "purely" OO (whatever that is...:-).
> ^^^^^^^^^^^^^^^^^^^
Pure OO-ness is not terribly crucial. The purity of the OO paradigm
as it appears in Smalltalk makes that language an excellent choice
for teaching OOP. But OOP is not a panacea of programming technology,
and the truth is that not all concepts fit all that well into the
OO paradigm. A hybrid language is nothing to be ashamed of, but
a language which cannot determine the types of its objects at
run time has some problems in my opinion. My first gripe with
C++ is that it equates types with classes, not that it is a hybrid
language.
>
> I believe that those supporting this viewpoint are simply
> parroting dogma that they have heard from supporters of the "pure"
> OO languages.
Agreed.
> I would really like to see someone expound upon the "whatever
> that is" part of the arguement.
Not a very dramatic exposition, but I submit my paragraph above.
> Perhaps those supporting C++ should take the following stance:
> "I believe that language XXX is a hack, due to the fact that it is
> "purely" OO (whatever that is)".
> (Insert favorite "purely" OO language for XXX) ...
C++ may not be a hack, but it certainly cannot be described as pretty,
elegant, or simple. Most language designers are trying to avoid
complexity, because language complexity does not aid the programmer.
C++ offers 9 ways to attack almost anything, making it perhaps the
most powerful, incomprehensible language today. I'd like to see the
language simplify its menu a little, overcome its great fear of knew
keywords in favor of more readability, keep its powerful features,
add a totally polymorphic message send (I can send ANY message to any
object, type determined at run time, like Smalltalk, and Objective-C).
This type of message send doesn't have to be the only thing on the
menu, just make it available.
It's not a bad language, but it's certainly capable of becoming one.
--
Eric W. Sink University of Illinois at Urbana-Champaign
e-s...@uiuc.edu
David M Geary
] = <1991Sep24....@helical.com> writes:
]> I believe that those supporting this viewpoint are simply
]> parroting dogma that they have heard from supporters of the "pure"
]> OO languages.
]>
]No dogma here. Thanks for the nice compliment, though.
]
] I simply feel that consistency in a language's implementation and
] syntax is a wonderful thing. Why have everything be an object,
] except for, gee, we forgot, those variable types over there, which
] are still primitives, hope you don't mind? Why have functionality
] encapsulated into objects--except for these and those function
] packages, which are too low-level and besides it's too confusing
] to existing hordes of programmers to encapsulate them anyway?
] Making exceptions for tradition's sake or for the hardened brain
] arteries of existing programmers sounds like an excuse for the
] design of the New York subway system:
] it's not a reasonable excuse for language design.
]
Well, excuse me, but this is simply more dogma parroting.
*Why* does everything have to be an object? *What* is
gained from everything being an object? Realize that the
OOP paradgim, while very important (yes, I'm a believer), is
not a panacea for all the ills of the programming community.
Please state why having a non-object inherent type, such
as C++'s int is a disadvantage. Statements about how you
*feel* have absolutely no validity. You must present some
hard facts such as "Well here's an instance where not
having everything implemented as an object is a real bummer:",
followed by a good, solid example. Otherwise, you are, as many
before you simply *SPOUTING DOGMA*!!!!!!!
]> I would really like to see someone expound upon the "whatever
]> that is" part of the arguement.
]>
] "Whatever that is": sure, I'll bite. Pure OO is a design environment
] in which all data is encapsulated in objects. It's an environment in
] which all behavior is instigated with a call of consistent syntax
] and style. It's an environment in which all data is accessed by
] use of these behavior calls.
]
Ok, good. Now we have a *definition* of "pure OO".
However, you have not provided *one concrete example*
which convinces me that "pure OO" is preferable to OO
based on a hybrid language design.
] I am not suggesting that OO is the Last Word in language design.
] I AM suggesting that consistency of design and implementation is
] an achievable ideal that programmers should demand of language
] designers.
*Why*. Tell us *why*.
David M Geary
]In <45...@ssc-bee.ssc-vax.boeing.com> dmg@ssc-vax (David M Geary)
writes:
]>
]> I believe that those supporting this viewpoint are simply
]> parroting dogma that they have heard from supporters of the "pure"
]> OO languages.
]
]Agreed.
(The "viewpoint" above being that being a purely OOP
language, where everything is an object is better than an
OOP hybrid).
]> I would really like to see someone expound upon the "whatever
]> that is" part of the arguement.
]
]Not a very dramatic exposition, but I submit my paragraph above.
]
]> Perhaps those supporting C++ should take the following stance:
]
]> "I believe that language XXX is a hack, due to the fact that it is
]> "purely" OO (whatever that is)".
]
]> (Insert favorite "purely" OO language for XXX) ...
]
]C++ may not be a hack, but it certainly cannot be described as pretty,
]elegant, or simple. Most language designers are trying to avoid
]complexity, because language complexity does not aid the programmer.
I believe that most language designers try to avoid complexity, but
definetely not for the sake of the programmer. C++ is
admittedly a complex language; however, from a C
programmer's standpoint it is probably easier to learn C++
than to start at ground 0 with something like Eiffel.
]C++ offers 9 ways to attack almost anything, making it perhaps the
]most powerful, incomprehensible language today. I'd like to see the
Ok. But how does one offer a language with "9 ways to
attack almost anything, making it perhaps the most
powerful" language without it being complex?
]language simplify its menu a little, overcome its great fear of knew
]keywords in favor of more readability, keep its powerful features,
]add a totally polymorphic message send (I can send ANY message to any
]object, type determined at run time, like Smalltalk, and Objective-C).
]This type of message send doesn't have to be the only thing on the
]menu, just make it available.
]
Wow, does this open Pandora's box. I am sure that many, especially
in this newsgroup, will argue vehemently against dynamic typing.
Some argue that dynamic typing is unsafe, causing programs to bomb
out at runtime due to unforseen and untested situations where an
object winds up being sent a message it cannot deal with.
Those people will probably not want to by flying in a
airplane whose software is written in SmallTalk.
Others argue that situations where an object is sent a
message that it cannot handle are very rare, and that even
statically typed languages such as Eiffel and C++ cannot
*guarantee* that they will not bomb at runtime for various
other reasons unrelated to dynamic typing.
Personally, I think dynamic typing greatly simplifies the
programmers job. However, I'm not sure that I'd want to be
in that 747 ...
BTW, I have heard that GNU is coming out with a new C++
which includes objective C syntax. Anyone know if this is
true?
]It's not a bad language, but it's certainly capable of becoming one.
]
I think C++ is analagous to C in many ways. It gives you
almost unlimited power to do anything you want. However,
that power cannot be had with no cost. Yes, C++ (and C) are
harder to read and understand vs. comparable languages, such
as Eiffel and Pascal respectively. I would rather pay the
cost, and have the power ...
Bertrand Meyer
> C++ is admittedly a complex language; however, from a C
> programmer's standpoint it is probably easier to learn C++
> than to start at ground 0 with something like Eiffel.
I disagree. The key to learning a language is its simplicity and
consistency. In C++ you have a mixture of two very different
paradigms, C and O-O; in addition, the constructs supporting
the second of these paradigms are (in my opinion at least) not very
well done. Even if they were, the programmers would still have
to ask themselves constantly ``should I do this in manner C or
manner O-O? Can I handle some parts in C style and the rest in
O-O style? If so, how do they communicate with each other?
If not, how do I choose?
In contrast, a pure O-O language may be more of a culture shock
initially - for the first two hours, that is. After that you realize
that you are working in a consistent conceptual framework, and
that makes things easier for you.
Although Eiffel has been criticized for various reasons, I don't recall
people seriously saying the language is hard to learn. A few days (or
hours) to a couple of weeks is what it takes.
Becoming an expert designer and programmer in Eiffel is another matter,
of course. But that would be true in any language reflecting a novel
approach to problem-solving. I would contend that this process is in fact
easier in Eiffel for two reasons:
- Since there is no C burden to contend with, one can concentrate on
the significant conceptual issues, rather than fighting irrelevant
details coming from a language which (viewed from the O-O world)
is a remnant of obsolete technology. The C++ Annotated Reference Manual
(Addison-Wesley, 1990) lists many of these, with remarkable candor.
For example the book states that the C array concept is ``weak and beyond
repair'' (page 212). Elsewhere it describes the declarative syntax of C,
``and therefore of C++'', as ``unnecessarily hard to read and write''
(page 132). These are just two examples among many.
- Since there is fuller support in Eiffel for the most difficult aspects
of O-O technology (genericity, full typing, exception handling,
assertions, exceptions, support for garbage collection, repeated
inheritance, renaming etc.) one is not hampered by problems due
to the language rather than the O-O method itself.
One may dismiss the above assessment as biased. In a way it is, of course.
But it is such reasoning that led to the existence of Eiffel - not the
other way around.
-- Bertrand Meyer
Interactive Software Engineering Inc., Santa Barbara
bert...@eiffel.com
David Adrien Tanguay
> I believe that most language designers try to avoid complexity, but
>definetely not for the sake of the programmer. C++ is
>admittedly a complex language; however, from a C
>programmer's standpoint it is probably easier to learn C++
>than to start at ground 0 with something like Eiffel.
This C programmer will take the opposite viewpoint (assuming that learning
C++ implies learning the benefits of C++ above C).
> I think C++ is analagous to C in many ways. It gives you
>almost unlimited power to do anything you want. However,
>that power cannot be had with no cost. Yes, C++ (and C) are
>harder to read and understand vs. comparable languages, such
>as Eiffel and Pascal respectively. I would rather pay the
>cost, and have the power ...
Okay when you need that power, but for many programmers it is only rarely
needed. ISE's Eiffel has excellent support for including other language
modules. Given my opinion above (i.e., C + Eiffel < C++, in terms of learning
difficulty), I prefer a mixed language approach to get the best of both
comprehensibility and power.
Silly thought: Unobjective-Eiffel, where C is dropped into the middle of
nice, clean Eiffel code, a la Objective-C.
--
David Tanguay d...@Thinkage.on.ca d...@Thinkage.com uunet!thinkage!dat
Thinkage, Ltd. Kitchener, Ontario, Canada [43.40N 80.47W]
Richard Bielak
[...]
> Well, excuse me, but this is simply more dogma parroting.
>*Why* does everything have to be an object? *What* is
>gained from everything being an object? Realize that the
>OOP paradgim, while very important (yes, I'm a believer), is
>not a panacea for all the ills of the programming community.
[...]
Why does everything have to be an object? Because it can. Why multiply
entities (Occam's razor, and all that). Why do I have to have five
things - like variables, pointers, references, objects - if objects
are sufficient?
You are right that OOP is not a panacea, but the reason for the
paradigm being important, is that it unifies to the whole process of
software development. I mean, you can find the objects and classes
that were discussed with the user during analysis in the source of the
production system.
...richie "recovering from OOPSLA :-)"
--
*-----------------------------------------------------------------------------*
| Richie Bielak (212)-815-3072 | It is more efficient to do something |
| Internet: ric...@bony.com | once, than to do it a thousand times. |
| Bang {uupsi,uunet}!bony1!richieb | - me - |
Rick Jones
>From <45...@ssc-bee.ssc-vax.boeing.com> by dmg@ssc-vax (David M Geary):
>
>> C++ is admittedly a complex language; however, from a C
>> programmer's standpoint it is probably easier to learn C++
>> than to start at ground 0 with something like Eiffel.
>
>I disagree. The key to learning a language is its simplicity and
>consistency.
I can speak from experience as an Eiffel user, rather than its designer, and I
fully agree with Bertrand. The notion that C++ is the obvious route into OO
for C programmers is somewhat misplaced.
I am an experienced C systems programmer by background, and have certainly been
writing in C for many more years than I have in Eiffel. I learnt Eiffel from
the books and manuals, and found it very straight-forward to understand. I
have also investigated C++, and although I know C very well I find C++ to be
not at all straight-forward and generally confusing.
As many people have commented, the "paradigm shift" is one of the hardest
aspects of OOP to grasp. Since Eiffel both enforces the paradigm and supports
it very elegantly, it greatly assists in re-arranging one's thinking in the
right direction.
I have also taught Eiffel to other programmers, and have covered both the
concepts of OOP and the whole of Eiffel in 3 days of hands-on training. The
subjects (or should it be objects:-) at the end of this time of course lack
experience, but have learnt all the key aspects of the language and know how to
set about writing an Eiffel program to solve any problem. They have also seen
and used in examples all of Eiffel's available syntactic constructs, and have
come away feeling happy and enthusiastic about the language.
I would even suggest that if you really want to teach a C programmer C++ so
that he will use it properly (i.e. making full use of all the OO features), you
could do worse than teach him Eiffel first!
--
Rick Jones, Tetra Ltd. Maidenhead, Berks, UK ri...@tetrauk.uucp
Chairman, NICE (Non-profit International Consortium for Eiffel)
Any fool can provide a solution - the problem is to understand the problem
James McKim
>In article <6...@eiffel.UUCP> bert...@eiffel.UUCP (Bertrand Meyer) writes:
>>From <45...@ssc-bee.ssc-vax.boeing.com> by dmg@ssc-vax (David M Geary):
>>
>>> programmer's standpoint it is probably easier to learn C++
>>> than to start at ground 0 with something like Eiffel.
>>
I'll second Rick's comments and 'third' Bertrand's. I programmed in C and C++
before programming in Eiffel. Having read a fair amount about the OO paradigm
before learning C++, I was disappointed in how difficult it was to take
advantage of the OO capabilities of C++ because I was continually distracted
by the syntax and semantics of the language. I had no such problems with
Eiffel.
One of my favorite quotes comes from an AT&T C++ consultant (whom I promised
anonymity). "The hardest people to whom to teach the OO paradigm using
C++ are C programmers."
-- Jim
*------------------------------------------------------------------------------*
Jim McKim (203)-548-2458 In exactly 3.2 seconds it will be a few
Internet: j...@mstr.hgc.edu minutes to 5:00.
Bob Weiner
In-reply-to: j...@mstr.hgc.edu's message of 16 Oct 91 13:50:48 GMT
Subject: Re: C++ vs Eiffel vs Smalltalk (warning--long language war)
--text follows this line--
> In article <12...@tetrauk.UUCP> ri...@tetrauk.UUCP (Rick Jones) writes:
>>In article <6...@eiffel.UUCP> bert...@eiffel.UUCP (Bertrand Meyer) writes:
>>>From <45...@ssc-bee.ssc-vax.boeing.com> by dmg@ssc-vax (David M Geary):
>>>
>>>> C++ is admittedly a complex language; however, from a C
>>>> programmer's standpoint it is probably easier to learn C++
>>>> than to start at ground 0 with something like Eiffel.
>>>
>>>I disagree. The key to learning a language is its simplicity and
>>>consistency.
>>>[...]
>>
> I'll second Rick's comments and 'third' Bertrand's. I programmed in C and C++
> before programming in Eiffel. Having read a fair amount about the OO paradigm
> before learning C++, I was disappointed in how difficult it was to take
> advantage of the OO capabilities of C++ because I was continually distracted
> by the syntax and semantics of the language. I had no such problems with
> Eiffel.
I must also agree here. After years of C programming, Eiffel was much
easier to master than C++ for these very reasons. Unfortunately, a much
larger portion of the world is mired in C and C++ technologies at this
point. I should also temper this comment by saying that a number of quite
bright electrical engineers that I sought to introduce to the use of Eiffel had
a great deal of trouble understanding it. I believe this relates to the idea
of letting the machine produce the control logic, rather than explicitly coding
how each feature call dispatches. EEs tend to have strong groundings in
control models and so it may be difficult for them to shift to the less
explicit control model of OO technologies and methods.
A little known fact is that Bill Joy, chief technical officer of Sun
Microsystems, has on more than one occasion said publicly that he had wanted to
use Eiffel for his advanced OO rewrite of UNIX but that Sun's alliance with
AT&T has made this impossible.
The rule of convenience and political correctness run much stronger in
the real world than do the forces pushing for the Right solutions, wherever
they may be.
--
Bob Weiner r...@cs.brown.edu
I speak only for myself. No official positions here.
Bruce D Mount
>fully agree with Bertrand. The notion that C++ is the obvious route into OO
>for C programmers is somewhat misplaced.
I have to put my vote in this corner as well. Speaking as another
non-designer of Eiffel with years of C programming (down and dirty
stuff, embeded real-time systems, etc.), I have to say that Eiffel
was MUCH easier for me to learn than C++.
Expanding on Rick's comments about Eiffel being MUCH easier
to read. A new Eiffel programmer can easily look at other Eiffel
examples and know exactly what was done. This is critical in a
team environment where new members must learn the existing code
to be completely productive.
In contrast, a new C++ programmer often has difficulty decyphering
C++ programs written by others. Even experienced C++ programmers
frequently have problems.
-------------------------------------------------------------------
Bruce Mount "Another member of the Eiffel Jihad"
br...@pls.com or
...uunet!plsparc!bruce
-------------------------------------------------------------------
130...@gmuvax2.gmu.edu
> The key to learning a language is its simplicity and
>consistency. In C++ you have a mixture of two very different
>paradigms, C and O-O; in addition, the constructs supporting
>the second of these paradigms are (in my opinion at least) not very
>well done. Even if they were, the programmers would still have
>to ask themselves constantly ``should I do this in manner C or
>manner O-O? Can I handle some parts in C style and the rest in
>O-O style? If so, how do they communicate with each other?
>If not, how do I choose?
>
>In contrast, a pure O-O language may be more of a culture shock
>initially - for the first two hours, that is. After that you realize
>that you are working in a consistent conceptual framework, and
>that makes things easier for you.
Speaking as one who has recently learned both Eiffel and C++, I agree.
In addition to the points that Mr. Meyer makes, Eiffel has the bonus of
working at a higher level. Automatic garbage collection, for instance,
reduces indirectly reduces the complexity of the language, and
facilitates learning it.
Bruce Feist
Norman Diamond
>>From <45...@ssc-bee.ssc-vax.boeing.com> by dmg@ssc-vax (David M Geary):
>>> C++ is admittedly a complex language; however, from a C
>>> programmer's standpoint it is probably easier to learn C++
>>> than to start at ground 0 with something like Eiffel.
>>I disagree. The key to learning a language is its simplicity and
>>consistency.
>fully agree with Bertrand. The notion that C++ is the obvious route into OO
>for C programmers is somewhat misplaced.
Come on, guys. Real programmers don't use Pascal. Clearly the same goes
for Eiffel. To quote from an article in Datamation around 1984:
"If [a program] was hard to write, it should be hard to understand."
And there's only one suitable class of languages (this name is original):
INC ASMVNO
--
Norman Diamond dia...@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
signature, n.: acm special interest group on studies of the real world.
Jim ADCOCK
|One of my favorite quotes comes from an AT&T C++ consultant (whom I promised
|anonymity). "The hardest people to whom to teach the OO paradigm using
|C++ are C programmers."
Maybe a true statement, but not one that reflects much on C++ --
-- because the hardest people to whom to teach *anything* are C programmers.
:-) [juuust kidding]
Lawrence E. Fitzpatrick
>>From <45...@ssc-bee.ssc-vax.boeing.com> by dmg@ssc-vax (David M Geary):
>>
>>> C++ is admittedly a complex language; however, from a C
>>> programmer's standpoint it is probably easier to learn C++
>>> than to start at ground 0 with something like Eiffel.
>>
>for C programmers is somewhat misplaced.
I cannot help but second Rick (and by extension, BM). I knew C long
before Smalltalk & C++, have taught OOP at the university level and used
Smalltalk for that course against the persistent hammering of some
students who wanted to use C++, and was glad I did. In fact, I let a
few really insistent students use C++ while the rest of the class used
Smalltalk. With the exception of one of these students, the rest never
really "got it."
C programmers can learn to USE C++ easily but do not necessarily learn
OOP. I have also experienced this with people who have worked for me.
>As many people have commented, the "paradigm shift" is one of the hardest
>aspects of OOP to grasp. Since Eiffel both enforces the paradigm and supports
>it very elegantly, it greatly assists in re-arranging one's thinking in the
>right direction.
Got that right!
I would like to outline two very specific, very real problems we have had
with shifting from C to C++. First I should explain that I learned
Smalltalk some 6 years ago. Shortly after that I learned C++ for use
in a small project that lasted about 8 months, but did not use it again
heavily until about a year ago when we decided to use it on my project.
First, a pure OO design does NOT translate naturally into C++ code. There
is too much infrastructure missing from C++, and a few things in the
language that make the kind of problems we have had to solve "unnatural"
in C++ (the lack of runtime type information and a safe method for
downcasting -- no religion please, it's necessary). I firmly believe
that had I been able to use Eiffel or Smalltalk, the development of
one particular subcomponent would have been quartered.
Secondly, because there is no stable infrastructure and there are many
choices to be made in C++ (do I use values or objects, pointers or
references, a single rooted hierarchy or a forest of trees, mixin style,
or other, ...) the code evolves unnecessarily as you build your own
infrastructure. That is, you will write some classes one way, use them
for a while, and then have to upgrade them later because some
infrastructure components that these classes depend upon have changed as
you have discovered a "better" way to organize your infrastructure.
I guess if I could sum these two points up, I would say: experience with
OOP does not necssarily give you great leverage on C++ and experience
with C++ is far more critical to a good implementation design than with
other languages I have experienced.
Eric Smith
C++ seems to be gaining "critical mass" for the same reason Pascal did
in the late 1970's. Pascal became widely available at low cost when
UCSD published their version at a very low price. It rapidly gained
popularity during the rest of the 1970's and early 1980's. Borland's
Turbo Pascal gave it an additional kick.
The same thing happened to C a few years after Pascal. There were lots
of companies publishing low cost high quality compilers for it so it
gained critical mass.
The same thing has been happening with C++ recently, and that is IMHO
the real reason why C++ is more popular than Eiffel. When people
choose a new programming language, it has nothing to do with what
language they used before.
Programmers satisfied with their present programming language are less
likely to try to find better alternatives than those who are
dissatisfied. So a C programmer who wants to find a better language
would probably have a bias against C++ in favor of getting further away
from C.
However, all such biases probably have much less effect than they get
credit for. The real motivating forces might be almost purely
economic. Programmers want to use whatever language lets them get the
most work done with the least effort, provided they don't have to pay a
lot of money to get started with it.
Suppose I could use Eiffel at work but just C++ at home. If I spend
20% of my time programming at home on personal projects, doesn't it
make sense that I would want to use the same language at work, just to
avoid daily switching between them? Especially if that is the only way
I could use the same class libraries etc.?
A 486/33 with 64 megabytes of ram costs around $5000. A good C++
compiler for it usually adds less than a few hundred dollars to that.
I have been programming for more than 20 years, but have never had
access to any computer more powerful than that. Not even the
mainframes I used to program were anywhere near that powerful.
Compare that to what is available with Eiffel. I don't know of any
system of such low cost that will even run Eiffel. And I suspect the
Eiffel compiler alone would probably cost a large fraction of that.
It would be wonderful to have Eiffel as readily available as C++, but
until then, it's more like a fairy tale than a real product.
Meanwhile C++, even though less elegant than Eiffel, is genuine magic.
In a race between genuine magic and a fairy tale, the genuine magic
usually wins.
Rick Jones
[among other things]
>A 486/33 with 64 megabytes of ram costs around $5000. A good C++
>compiler for it usually adds less than a few hundred dollars to that.
>I have been programming for more than 20 years, but have never had
>access to any computer more powerful than that. Not even the
>mainframes I used to program were anywhere near that powerful.
>
>Compare that to what is available with Eiffel. I don't know of any
>system of such low cost that will even run Eiffel. And I suspect the
>Eiffel compiler alone would probably cost a large fraction of that.
>It would be wonderful to have Eiffel as readily available as C++, but
>until then, it's more like a fairy tale than a real product.
You seem to have an extreme impression of the amount of computing power needed
to use Eiffel. I have done all my work on a 386/20-16Mb, which is quite
adequate. Granted, compile times are not exactly electric with the current ISE
compiler, but I find I need fewer compile cycles with Eiffel than with C to get
to an equivalent result. I've not used C++ sufficiently to draw a direct
comparison. For a short time I had the opportunity to try using a 486 of the
sort of power you mention, and that compiled very quickly; I was by no means
the sole user of that machine, either.
Added to that is the fact that in a few weeks (if all I read is correct) you
will be able to buy Eiffel/S for MS/DOS, which will compile and run in a 640k
basic PC. Eiffel is well within the reach of the "ordinary" user without
access to exotic hardware.
>Meanwhile C++, even though less elegant than Eiffel, is genuine magic.
>In a race between genuine magic and a fairy tale, the genuine magic
>usually wins.
Some sorts of magic require spells, potions, and incantations to make them
work, and result in curses when they don't. I prefer a more rigorous approach
:-)
David M Geary
]>From <45...@ssc-bee.ssc-vax.boeing.com> by dmg@ssc-vax (David M Geary):
]>
]>> C++ is admittedly a complex language; however, from a C
]>> programmer's standpoint it is probably easier to learn C++
]>> than to start at ground 0 with something like Eiffel.
]>
]>I disagree. The key to learning a language is its simplicity and
]>consistency.
]>[...]
]
]I can speak from experience as an Eiffel user, rather than its designer, and I
]fully agree with Bertrand. The notion that C++ is the obvious route into OO
]for C programmers is somewhat misplaced.
]
]I am an experienced C systems programmer by background, and have certainly been
]writing in C for many more years than I have in Eiffel. I learnt Eiffel from
]the books and manuals, and found it very straight-forward to understand. I
]have also investigated C++, and although I know C very well I find C++ to be
]not at all straight-forward and generally confusing.
]
]As many people have commented, the "paradigm shift" is one of the hardest
]aspects of OOP to grasp. Since Eiffel both enforces the paradigm and supports
]it very elegantly, it greatly assists in re-arranging one's thinking in the
]right direction.
]
]that he will use it properly (i.e. making full use of all the OO features), you
]could do worse than teach him Eiffel first!
I teach two off-hour classes: "Object-Based Programming in C" and
"Object-Oriented Programming in C++". Neither course has an
assigned book, just lecture notes that are handed out. For both of
these courses, however, I recommend OOSC by Bertrand Meyer, and have
had quite a few students buy the book. I must agree that OOSC is
the most comprehensive book out for general OOP concepts.
Maybe I will have to rethink my original hypothesis about C++
being easier to learn than Eiffel for C programmers. What Bertrand
and Rick have stated do seem to make sense. Note however, that I
did say "probably" ;-).
--
|............... David Geary, Boeing Aerospace, Seattle, WA. ................|
|-----------------------------------------------------------------------------|
|............... How's my programming? Call 1-800-DEV-NULL ..................|
|-----------------------------------------------------------------------------|
Eric Smith
>Added to that is the fact that in a few weeks (if all I read is correct) you
>will be able to buy Eiffel/S for MS/DOS, which will compile and run in a 640k
>basic PC. Eiffel is well within the reach of the "ordinary" user without
>access to exotic hardware.
Will it run the way Zortech C++ runs on my 486/33? I don't need Unix
to run my C++ programs, and they can use as much memory as they want.
(As far as I am concerned, since memory now costs less than $50 per
megabyte, the whole concept of swapping to disk is totally obsolete and
very wasteful.)
I was using a version of Unix on this computer, but it had too many
bugs, so I "upgraded" to MS-DOS v5 for $38. (I'm real cheap.) One of
the bugs my version of Unix had was that it wouldn't work with more
than 16 megabytes of ram on this computer because it used dma to ram
addresses beyond 16mb which weren't physically available on the ISA
bus. The reason I "upgraded" to MS-DOS v5 instead of just using my
old copy of MS-DOS v3 was that I wanted to use a 200 meg disk as a
single partition, and the old version of MS-DOS only supports
partitions up to 32 megabytes.
Anyway, I assume if I want to get ISE Eiffel working on this computer,
then at the very least I need an expensive version of Unix such as
SCO. I assume it needs the full development system, not just the Unix
runtime system. And what if SCO turns out to be incompatible with this
hardware? Will I then be stuck with an expensive shelf full of useless
Unix manuals and floppies?
When I said Eiffel was a fairy tale, I didn't really mean to imply that
it is and will continue to be one, so much as that it has been in the
past. But it takes years to gain critical mass, so Eiffel has a lot of
catching up to do vs C++ which already is starting to get critical
mass. When I first started using C++ I just had a PC clone with two
360K floppies and no hard disk. The C++ version I was using then
wasn't very good, but it was a lot better than anything else I could
find, with the possible exception of Smalltalk. (Back then the
cheapest version of Smalltalk was called Methods. Smalltalk V evolved
from that.) But anyway I wound up with C++, and have been evolving my
own class library during all the years since then.
Eiffel has been a fairy tale to me ever since I first heard of it.
I've been continuing to work on my C++ class library, and occasionally
wonder if I should try some other language such as Eiffel. However,
for all the flaws of C++, C++ does seem to be getting critical mass
now. This means I can count on always being able to get high quality
compilers and related tools at low cost due to the amount of competition.
So, the question boils down to this: Should I just continue to develop
my C++ library, or should I give Eiffel a try, and if I do, how much time
and effort will it take to get started? (By getting started I mean being
able to convert all my C++ stuff to Eiffel, and being able to use all
the physical memory in my 486/33 without any disk swapping etc.)
If, after I try Eiffel, I find that it isn't as good as C++, perhaps due
to speed or perhaps because I really need some of the features of C++,
will I be able to back out gracefully and continue with C++, or will I
be stuck due to the amount of time and effort I will have already invested
in Eiffel?
Rick Jones
]In article <12...@tetrauk.UUCP> ri...@tetrauk.UUCP (Rick Jones) writes:
][...]
]>Added to that is the fact that in a few weeks (if all I read is correct) you
]>will be able to buy Eiffel/S for MS/DOS, which will compile and run in a 640k
]>basic PC. Eiffel is well within the reach of the "ordinary" user without
]>access to exotic hardware.
]
]
]Will it run the way Zortech C++ runs on my 486/33? I don't need Unix
]to run my C++ programs, and they can use as much memory as they want.
](As far as I am concerned, since memory now costs less than $50 per
]megabyte, the whole concept of swapping to disk is totally obsolete and
]very wasteful.)
I can't say, since I don't know Zortech C++, and haven't seen Eiffel/S yet.
There's more info on Eiffel/S, including distributors, in the just-posted FAQ,
or if you want to ask specifics you could try SIG Computer, the authors -
Frieder Monninger (f...@sigbr.sigcomp.sub.org) will get you in touch.
]Anyway, I assume if I want to get ISE Eiffel working on this computer,
]then at the very least I need an expensive version of Unix such as
]SCO. I assume it needs the full development system, not just the Unix
]runtime system.
If you want ISE's version, yes you will need SCO or equivalent. If you prefer
DOS (which you obviously do), then there's Eiffel/S. For people to try it out,
there is a special version available for $60, whose only restriction is that
programs are limited to 75 classes. That sounds to me like a low-risk and
realistic way to find out if you really want to invest in Eiffel.
]So, the question boils down to this: Should I just continue to develop
]my C++ library, or should I give Eiffel a try, and if I do, how much time
]and effort will it take to get started? (By getting started I mean being
]able to convert all my C++ stuff to Eiffel, and being able to use all
]the physical memory in my 486/33 without any disk swapping etc.)
]
]If, after I try Eiffel, I find that it isn't as good as C++, perhaps due
]to speed or perhaps because I really need some of the features of C++,
]will I be able to back out gracefully and continue with C++, or will I
]be stuck due to the amount of time and effort I will have already invested
]in Eiffel?
This doesn't sound like a question anyone can answer - only you can by doing
it. There is risk either way, and assessment of risk is to some extent
guess-work. The risk of sticking to C++ is that Eiffel might have worked
better, but you'd never know. The risk of trying Eiffel is that it might not
suit you. You've obviously invested a lot of time in the groundwork for C++
which is a point in its favour for your purposes.
I believe you should think seriously about the Eiffel/S trial pack, it's not
a lot of money, and I think a small amount of time invested in getting to know
it should give you a good idea of whether you want to take it further. At
worst it might give you some better ideas on how to use C++!
Paul Big-Ears Menon
> In article <12...@tetrauk.UUCP> ri...@tetrauk.UUCP (Rick Jones) writes:
> >In article <6...@eiffel.UUCP> bert...@eiffel.UUCP (Bertrand Meyer) writes:
> >>From <45...@ssc-bee.ssc-vax.boeing.com> by dmg@ssc-vax (David M Geary):
> >>
> >>> C++ is admittedly a complex language; however, from a C
> >>> programmer's standpoint it is probably easier to learn C++
> >>> than to start at ground 0 with something like Eiffel.
> >>
> >...fully agree with Bertrand. The notion that C++ is the obvious route into OO
> >for C programmers is somewhat misplaced.
>
> I cannot help but second Rick (and by extension, BM). I knew C long
> before Smalltalk & C++, have taught OOP at the university level and used
I have (yet another) example of how a (possibly typical) C programmer struggles
with the paradigm shift, even into Eiffel. I shall slightly change the needle
to protect the record (??).
It went along something like this..
Jo Bloggs came along, asking advice on an OOP implementation which required
(at the very least) a collection of some sort. His immediate solution was
to create a linked list. OK I said, as long as you're happy with that. He
was still stuck with how one object could refer to this list. His solution?
"Point to the first element of the list".
"Uh huh..." That's where I stepped in.
"No, Jo, you `point' to the list."
"How do I do that?"
"Well, you make the list `part' of the object which wants to refer to it."
"Huh?"
"Make an object which comprises (other things and) a `variable' for the
list."
"Ohhhh, then how do other objects get to this list?"
"Think of variables as references (`pointers') to the actual object data."
And so on..
Now this is something which all programmers may go through in a silent
fashion anyway, regardless of paradigm (the above is obvious even in C), but
the first mistake (as far as I can gather) that most C programmers fall for
is jumping straight to something they're familiar with. In this example, a
linked list. Everyone's built and used one. They're all experts with
malloc, realloc, calloc, sizeofs etc.. But can you get them to abstract?
To suggest there is something like a dictionary or set of `things'? This
example didn't need to traverse the linked list whatsoever, it was just a
collection (perhaps keyed). He totally missed the point of what a linked
list doesn't provide, but a dictionary or set does (unique objects or keys)
and relate it to his problem. I guess he'd write some code to do that for
this `special' case :-). Or maybe he'd just assume this wouldn't be
a problem.
I suggest that this is the real struggle people have, and when provided
with an escape hatch (as C++ does in letting you revert to C), one totally
misses key design issues. One wonders how well `real programmers' abstract
in the first place.
The above was an attempt to write Eiffel.
I have also been involved with some postgrad students using GemStone (OODB).
It was interesting to watch their reaction to the difference twixt a reln DB
and an OODB. It was even more interesting (and rewarding) to be able to
teach in such an abstract manner. More rewarding was the acceptance
that they didn't need (and in most cases, want) to know what
was `under the cover', but I enticed them to be inquisitive anyway.
Paul Menon,
Dept of Computer Science,
Royal Melbourne Institute of Technology,
124 Latrobe Street,
Melbourne 3001,
Victoria, Australia.
email: p...@goanna.cs.rmit.oz.au
PH: +61 3 660 3209
FAX: +61 3 662 1617