If you don't like language wars, skip this article.  If you read it,
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 {*filter*} 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        *

**********************************************************

|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 {*filter*} 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.

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.

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?

Why 50%? You could run a check for the `languages' "B", "D" etc. and
come up with a somewhat meaningfull zero level.

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!)

|

|> ...
|> Number of references to a particular language in the magazine articles
|> and abstracts of the Computer Select database:
|>
|> C         22595
|> C++                4300
|> 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?

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...

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 :>

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.

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.  

Well, no: see above.

or the numbers.

Or those who take measurements but have no idea of what they measured.

Ah, ok so you did follow that up. Sounds ok to me.  From the original
post I had thought you had just guessed... sorry.

Ouch! (again)

!!! :>:>:>

[...]

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    |

| Bang {uupsi,uunet}!bony1!richieb |                                          |

The name I heard was

   POSTINCREMENT COBOL BY ONE

The "proprietary windowing mechanism" is gone as of Release 4. What else
does "etc." cover?

--

ParcPlace Systems, Inc., 1550 Plymouth St., Mountain View, CA 94043

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

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?

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.

->
->>...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"?
--

ParcPlace Systems, Inc., 1550 Plymouth St., Mountain View, CA 94043

Yes and yes.

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 de{*filter*} 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 de{*filter*} 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.
--

ParcPlace Systems, Inc., 1550 Plymouth St., Mountain View, CA 94043

And Digitalk's Smalltalk/V now runs under Windows/3 and OS/2+PM.

--

                        Are you ready for Pachenka?

|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! :-)

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