[comp.software-eng] problems/risks due to programming language

tombre@crin.fr (Karl Tombre) (03/01/90)

In article <259@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:
   From <Ec.3251@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger):

   > Personally, it's the little things like this that make me
   > believe that everyone should ABANDON C and move on to C++(two others being
   > function prototyping and strong type checking).  Waddya think?  Wither C?

       How can the words ``strong type checking'' be applied to a language
   in which any variable may be cast to any type? In which you declare the
   type of a generic list element to be ``pointer to characters''?

       C++ only magnifies the problems of C, and it does not even have the
   excuses that can be invoked in the case of a 20-year old design such as C.
   [and so on]

Am I the only one having regularly the following problem?

I think Eiffel is a very good language (probably one of the best), I
am quite impressed by its design. I also appreciate Bertrand Meyer's
various technical and scientifical contributions in conferences and
newsgroups. But from time to time, this attitude of his comes up and
annoys me VERY MUCH : he seems to have difficulties accepting that
there are other solutions for object-oriented programming, that other
languages exist and are popular for various reasons. He especially
tends to become "rabid" when speaking of C++. This leaves such a bad
"taste in my mouth" that it tends to give me unjustly biased views of
Mr. Meyer's product, i.e. Eiffel.

That any "neutral" user gives his opinion about the merits or
deficiencies of C++, Eiffel, Smalltalk, Cobol, BASIC or whatever is
just fine. But shouldn't it be plain decency to restrain from
commenting in such strong and passionnate terms about one's
concurrents' products ? Especially for somebody wishing not to be
a marketing person but to be known as an authority in OO languages and
design ? I remember for instance reading some time ago, in the news,
comments from either Brad Cox or Bjarne Stroustrup about the other's
language; at no time did it have such a bad taste than the referenced
article. Isn't it on the border of arrogance to believe that "I know
the definite, final and only TRUTH about how an object-oriented
language should be designed" ???

--
Karl Tombre - INRIA Lorraine / CRIN
EMAIL : tombre@loria.crin.fr - POST : BP 239, 54506 VANDOEUVRE CEDEX, France

bertrand@eiffel.UUCP (Bertrand Meyer) (03/01/90)

From <Ec.3251@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger):

> Personally, it's the little things like this that make me
> believe that everyone should ABANDON C and move on to C++(two others being
> function prototyping and strong type checking).  Waddya think?  Wither C?


    How can the words ``strong type checking'' be applied to a language
in which any variable may be cast to any type? In which you declare the
type of a generic list element to be ``pointer to characters''?

    C++ only magnifies the problems of C, and it does not even have the
excuses that can be invoked in the case of a 20-year old design such as C.
All the flaws of the older language are still there; amount countless
examples, the break and switch instructions, which were purportedly
responsible for the AT&T breakdown (and started this whole discussion)
are still there exactly as in C. The bug would have occurred identically.

    Then there are new complexities and major new trouble spots -
such as default static binding, which means the guarantee that the
*incorrect* version of an operation will be applied!

-- Bertrand Meyer
bertrand@eiffel.com

henry@utzoo.uucp (Henry Spencer) (03/02/90)

In article <259@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:
>> Personally, it's the little things like this that make me
>> believe that everyone should ABANDON C and move on to C++(two others being
>> function prototyping and strong type checking)...
>
>    How can the words ``strong type checking'' be applied to a language
>in which any variable may be cast to any type? In which you declare the
>type of a generic list element to be ``pointer to characters''?

Come now, at least criticize the modern language, not a caricature of
what you think it was fifteen years ago.  Many "systems programming"
languages allow deliberate unsafe type conversions if you request them,
and they are not considered any less "strongly typed" for it.  Modern
C is a strongly-typed language by any reasonable definition, although
there are still a lot of antique compilers around that don't fully
enforce its rules.  (NB you can't cast any variable to any type in C,
only certain combinations are valid.)  And any modern generic pointer
declaration will say `void *' not `char *'.

There are enough real problems with C and C++ without making up silly
strawmen.

(P.S. They remain eminently usable languages for people who know what
they're doing, although incompetents and novices should definitely
avoid them.  Alas, all too many of the "real programs" in the world are
written by incompetents and novices...)
-- 
MSDOS, abbrev:  Maybe SomeDay |     Henry Spencer at U of Toronto Zoology
an Operating System.          | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

nick@lfcs.ed.ac.uk (Nick Rothwell) (03/02/90)

In article <1990Mar1.172526.28683@utzoo.uucp>, henry@utzoo (Henry Spencer) writes:
>Modern
>C is a strongly-typed language by any reasonable definition,

Could you give me a reference to the type semantics?

		Nick.
Nick Rothwell,	Laboratory for Foundations of Computer Science, Edinburgh.
		nick@lfcs.ed.ac.uk    <Atlantic Ocean>!mcvax!ukc!lfcs!nick
~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~
      A prop?   ...or wings?      A prop?   ...or wings?      A prop?

feg@clyde.ATT.COM (Forrest Gehrke,2C-119,7239,ATTBL) (03/02/90)

In article <1990Mar1.172526.28683@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> 
> There are enough real problems with C and C++ without making up silly
> strawmen.
> 
> (P.S. They remain eminently usable languages for people who know what
> they're doing, although incompetents and novices should definitely
> avoid them.  Alas, all too many of the "real programs" in the world are
> written by incompetents and novices...)



While I agree 100% with everything you said in this article in
support of the modern C language, aren't you being a little
contradictory in your postscript?  Unless you anticipated
Dennis Ritchie, one day you too were a novice in C.  Fortunately
you didn't avoid it.  (;-))

Forrest Gehrke feg@clyde.ATT.COM

karl@haddock.ima.isc.com (Karl Heuer) (03/03/90)

In article <1004@micropen> dave@micropen (David F. Carlson) writes:
>What break does is *very* well defined and is no more prone to
>misinterpretation that any other non-linear control flow statement ...

Yes, it's well defined, but what it's defined to do is bad.

For a formal treatment of the above statement, I refer you to my article
<16039@haddock.ima.isc.com>, posted to comp.lang.misc (also .c and .ada) with
this same title.  I haven't seen any rebuttals yet.

>A multi-case switch is very handy in many situations ...

Yeah.  I wish C had this feature, instead of simulating it with fallthrough.

>That you ask the question of the usefulness of break-per-case/multiple-cases
>implies that you haven't sufficient experience with the construct to judge
>its merits/weaknesses.

I don't know about the person you were addressing, but I think I've had
sufficient experience with it.  I certainly question its usefulness in
comparison to something reasonable, like the language I described in my other
article.

In fact, even if you insist that the comparison must be between C and
plain-C-without-break-switch, I think I'd still go for the latter.  I believe
the benefit of not requiring an overloaded keyword to do a break-switch
exceeds the cost of having to use a goto to merge related cases.

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint

dan@charyb.COM (Dan Mick) (03/03/90)

In article <TOMBRE.90Mar1013132@weissenburger.crin.fr| tombre@crin.fr (Karl Tombre) writes:
|In article <259@eiffel.UUCP| bertrand@eiffel.UUCP (Bertrand Meyer) writes:
|   From <Ec.3251@cs.psu.edu| by melling@cs.psu.edu (Michael D Mellinger):
|
|   | Personally, it's the little things like this that make me
|   | believe that everyone should ABANDON C and move on to C++(two others being
|   | function prototyping and strong type checking).  Waddya think?  Wither C?
|
|       How can the words ``strong type checking'' be applied to a language
|   in which any variable may be cast to any type? In which you declare the
|   type of a generic list element to be ``pointer to characters''?
|
|       C++ only magnifies the problems of C, and it does not even have the
|   excuses that can be invoked in the case of a 20-year old design such as C.
|   [and so on]
|
|Am I the only one having regularly the following problem?

No.

|I think Eiffel is a very good language (probably one of the best), I
|am quite impressed by its design. I also appreciate Bertrand Meyer's
|various technical and scientifical contributions in conferences and
|newsgroups. But from time to time, this attitude of his comes up and
|annoys me VERY MUCH : he seems to have difficulties accepting that
|there are other solutions for object-oriented programming, that other
|languages exist and are popular for various reasons. He especially
|tends to become "rabid" when speaking of C++. This leaves such a bad
|"taste in my mouth" that it tends to give me unjustly biased views of
|Mr. Meyer's product, i.e. Eiffel.

I know nothing *at all* about Eiffel, and I'm much less encouraged to learn
about it based on Bertrand's comments.  It's not that I'm less interested
in it technically; it's just that, due to his attitude toward communication in
general, I'm less apt to believe anything he's done technically is useful.

|That any "neutral" user gives his opinion about the merits or
|deficiencies of C++, Eiffel, Smalltalk, Cobol, BASIC or whatever is
|just fine. But shouldn't it be plain decency to restrain from
|commenting in such strong and passionnate terms about one's
|concurrents' products ? Especially for somebody wishing not to be
|a marketing person but to be known as an authority in OO languages and
|design ? I remember for instance reading some time ago, in the news,
|comments from either Brad Cox or Bjarne Stroustrup about the other's
|language; at no time did it have such a bad taste than the referenced
|article. Isn't it on the border of arrogance to believe that "I know
|the definite, final and only TRUTH about how an object-oriented
|language should be designed" ???

Yes.   Yes, it should. 



Unfortunately, the world is run by sales slime.  Good luck telling the
difference.

henry@utzoo.uucp (Henry Spencer) (03/03/90)

In article <2568@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes:
>>Modern
>>C is a strongly-typed language by any reasonable definition,
>
>Could you give me a reference to the type semantics?

ANSI X3.159 (I think that's the correct number) defines all the semantics
of C.  Publication is imminent.

"Strongly typed" and "has a mathematically formal definition of type
semantics" are two entirely different concepts, in case the latter was
what you were thinking of.  As far as I know, nobody has yet produced
a formal definition of C.  It is possible, although painful, to formally
define non-strongly-typed languages.
-- 
MSDOS, abbrev:  Maybe SomeDay |     Henry Spencer at U of Toronto Zoology
an Operating System.          | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

henry@utzoo.uucp (Henry Spencer) (03/04/90)

In article <4397@cbnewsl.ATT.COM> feg@clyde.ATT.COM writes:
>> ([C/C++] remain eminently usable languages for people who know what
>> they're doing, although incompetents and novices should definitely
>> avoid them.  Alas, all too many of the "real programs" in the world are
>> written by incompetents and novices...)
>
>While I agree 100% with everything you said in this article in
>support of the modern C language, aren't you being a little
>contradictory in your postscript?  Unless you anticipated
>Dennis Ritchie, one day you too were a novice in C.  Fortunately
>you didn't avoid it.  (;-))

I should have drawn slightly finer distinctions here.  Programming novices
should avoid C, period.  Experienced programmers who are C novices should
use C cautiously and avoid using it for production software, if possible,
until they're used to it.  Incompetents should go somewhere where their
lack of talent will not be noticed, e.g. the local DoD contractor. :-)
(It's no accident that one big push for languages that try to legislate
competence comes from DoD...)

Yeah, I was a C novice once.  I'm glad that all the code I wrote then
is dead and buried.
-- 
MSDOS, abbrev:  Maybe SomeDay |     Henry Spencer at U of Toronto Zoology
an Operating System.          | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

g2k@mentor.cc.purdue.edu (Frederic Giacometti) (03/05/90)

In article <TOMBRE.90Mar1013132@weissenburger.crin.fr> tombre@crin.fr (Karl Tombre) writes:
>In article <259@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:
>   From <Ec.3251@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger):
>
>   > Personally, it's the little things like this that make me
>   > believe that everyone should ABANDON C and move on to C++(two others being
>   > function prototyping and strong type checking).  Waddya think?  Wither C?
>
>       How can the words ``strong type checking'' be applied to a language
>   in which any variable may be cast to any type? In which you declare the
>   type of a generic list element to be ``pointer to characters''?
>
>       C++ only magnifies the problems of C, and it does not even have the
>   excuses that can be invoked in the case of a 20-year old design such as C.
>   [and so on]
>
>Am I the only one having regularly the following problem?
>
 ..........
>article. Isn't it on the border of arrogance to believe that "I know
>the definite, final and only TRUTH about how an object-oriented
>language should be designed" ???
>


  Firstly, let me clear up my position on the C/C++ problem: I agree
completely with B. Meyer on C/C++. Is it being arrogant than saying
that C++ is no more than a bricolage around C when it is the mere truth ?
  B. Meyer, may strongly cast his opinions, sometimes subtility is the mark
of a good mind, but there are other
marks as much valuable, among which are frankness and clarity of one's
opinion. 

  Secondly, a cultural problem has to be addressed. I am surprised to see this article emitted from a site in France; that
person should know that "every frenchman is arrogant" (one of the most
common image of French in america: lover and arrogant). This net is not the
place to discuss these features of French culture and education which
make that Frecnh intellectual life is particularly animated and opiniated (a feature one also
finds in Quebeccan politics), a severe contrast with the blendness of anglo-saxon puritan life.
By looking at his first name, I shall consider that Karl must not be french.
  
  Thirdly, I admire the courage of B. Meyer who successfully started his
own independent business. What he is doing is unique in the annals of
computer science: to center the development of a new company around the
development of a language. And I assert that it is a certificate of
quality about the language. As example of low techinical quality products
which were commercially successfull because of a name, one can quote the
IBM PC line.
  If you look at the history of computer science,
major developments (Apple is the exception) have usually been produced
by major corporations rather than by motivated individuals. This dynamism
derives from a strong personality (another arrogant man of which we
recently heard of was Steve Jobs with his NeXT machines). At least
B. Meyer engages the discussion and takes position on problems, whatever
it be. He does not hide himself beyond some obscur corporate barrier. 
Discussions on the net are technical, not commercial. Meyer exposes his
technical point of view, not more. Until now, I haven't seen many flaws in his
analyzes; if so let me know. His position has the merit of the clarity. 
One only has to know it.

  So far, C++ has taken up not much because of its intrinsic value, but
because of the support of AT&T. Besides the problems specific to C, it is
not even a complete object-oriented language (where is the dynamic binding ?).
The compatibility with C is more or less its only advantage from a technical
point of view. When he designed the language, Stroustrup grabbed some
ideas from Modula, and put some inheritance paradigm. On top of that,
the american press, hearing the name AT&T, rushed into it. Bof, it may
convince the one who like to follow the masses.  In that case, it is sure
that the voice of Meyer is very unpleasant, it disturbes what one wants
to hear: the mass is right and secure.

 I maintain that, although for programmers who know C, C++ is the seducing
solution, C++ has exceedingly weak theoretical bases to justify its use
in the future. Should this be considered as arrogance ?
  Eiffel has a very strong theoretical and formal support. It is the
product of a rigorous approach. All the contrary of C++, of which approach is
pragmatic, aimed at solving a short term industrial problem: how to improve
C without throwing it away. Well, it is with such raisonning that america
is still using the english system of measures, and other degree Farenheit,
to the great pleasure of the future generations and technological progress
of america.

Frederic Giacometti
School of Industrial Engineering
Purdue University

ok@goanna.oz.au (Richard O'keefe) (03/05/90)

In article <8113@mentor.cc.purdue.edu>,
g2k@mentor.cc.purdue.edu (Frederic Giacometti) writes:
> Firstly, let me clear up my position on the C/C++ problem: I agree
> completely with B. Meyer on C/C++. Is it being arrogant to say
> that C++ is no more than a bricolage around C when it is the mere truth ?

I'm about to pick a nit, so I'll start by saying that
 -- I found a year's course on category theory easier to understand
    than C++.  I used to read comp.lang.c++ but was frightened off.
 -- the ISE compiler for Eiffel generates C as its output
 -- I would be very happy if Eiffel outsold C++
 -- Eiffel has no published formal definition *either*.

>   Thirdly, I admire the courage of B. Meyer who successfully started his
> own independent business.  What he is doing is unique in the annals of
> computer science:  to centre the development of a new company around the
> development of a language.

This is hardly unique.  What about Objective-C?  What about the Edinburgh
team that developed Edinburgh Prolog and then founded Quintus?  What about
the earlier attempt (that failed) to build a small company around Pop?
What about ParcPlace?  There are lots more examples...

> And I assert that it is a certificate of quality about the language.

No.  All that it certifies is that (a) the founders of the company
believed in the language and that (b) they were about to persuade
a moneylender that the company was a good risk.

> If you look at the history of computer science,
> major developments (Apple is the exception) have usually been produced
> by major corporations rather than by motivated individuals.

It is not clear that this is the case.
(1) In many cases developments are _initiated_ by motivated individuals
    and taken over by corporations.
(2) In many other cases, developments are brought about by motivated
    individuals _within_ major corporations.  Not everything that a
    corporation does is initiated by the board of directors!  For
    example, IBM didn't really want to get into computers in the
    first place; the man who wanted them to do so had to go out and
    get orders for the machines *first* before T.J.Watson could be
    persuaded.

> So far, C++ has taken up not much because of its intrinsic value, but
> because of the support of AT&T.

Is this really true?  In day to day terms, what does "the support of AT&T"
amount to?  It doesn't mean rapid bug fixes.  I was under the impression
that the great appeal of C++ was that you could move into it gradually,
starting out just using it as a better C compiler and learning the extra
features one by one, never having the sensation of learning a whole new
language.  Really good programmers are not afraid of learning a whole new
language, and will do it if they have reason to believe it will pay off.
There are lots of programmers who are reluctant to change.

>   Eiffel has a very strong theoretical and formal support. It is the
> product of a rigorous approach.

If there is a formal specification of Eiffel (version 2.2 for choice)
I would very much like to see it.  "Eiffel: The Language" says quite
clearly (section 2.3) "This book is not a "formal" description of
Eiffel".  Alas, it's as close as we get.

shap@delrey.sgi.com (Jonathan Shapiro) (03/05/90)

In article <418@charyb.COM> dan@charyb.UUCP (Dan Mick) writes:
>|[... re Bertrand Meyers] He especially
>|tends to become "rabid" when speaking of C++. This leaves such a bad
>|"taste in my mouth" that it tends to give me unjustly biased views of
>|Mr. Meyer's product, i.e. Eiffel.
>
>I know nothing *at all* about Eiffel, and I'm much less encouraged to learn
>about it based on Bertrand's comments.

I know a little bit about Eiffel and have read quite a numbet of
Bertrand's technical "contributions" to the world.  I have known
Bertrand to be charming.  I have also known him to be rabid.
Consider, for a moment, how you would act after so many years of
uphill battles against languages like C++ that are deficient in some
important ways.

Having read many of his papers, however, and examined the design of
Eiffel in some detail, I am obliged to conclude that Eiffel is not
nearly as elegant as the marketing hype would have you believe, and
that Bertrand is in general not an effective communicator.

Whatever might be true about Bertrand himself, Bertrand's papers
convinced me long ago not to take Eiffel seriously.  Eiffel has a few
good ideas cribbed from some earlier languages.  It ain't the worlds
ultimate programming language. 

Jonathan Shapiro

tat@pccuts.pcc.amdahl.com (Tom Thackrey) (03/06/90)

In article <1990Mar4.005122.14121@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
 >I should have drawn slightly finer distinctions here.  Programming novices
 >should avoid C, period.  Experienced programmers who are C novices should
 >use C cautiously and avoid using it for production software, if possible,
 >until they're used to it.  Incompetents should go somewhere where their
 >lack of talent will not be noticed, e.g. the local DoD contractor. :-)
 >(It's no accident that one big push for languages that try to legislate
 >competence comes from DoD...)
Why is it necessary to slander some group or another to make a point?
BTW If they didn't notice why would they push ...?

-- 
Tom Thackrey sun!amdahl!tat00

[ The opinions expressed herin are mine alone. ]

bruce@menkar.gsfc.nasa.gov (Bruce Mount 572-8408) (03/06/90)

At the risk of losing my anonymity, I'm jumping feet first into the Eiffel Jihad.

Along with working full time as a contractor to NASA, I am the teaching assistant
for the "Object Oriented Programming" class at the nearby University of Maryland.

Dr. Meyer's contribution to computer science by designing Eiffel is tremendous.
Eiffel is the most elegant OOP language available today.  It's elegance allows
the programmer to easily understand the entire language in a short period of
time while giving them unmatched control via assertions and sensible exception
handling.  This is, of course, my opinion, but one that can be supported by
numerous rigorous arguments.  In my (limited) personal experience, every single
person I know that has access to both Eiffel and C++ uses Eiffel.

However, my opinions about Eiffel are not the point.  Rather, I would like to
discuss Dr. Meyer's attitude.  Dr. Meyer has the quite normal feeling that his 
language is the best OOP available.  If he didn't feel that there were problems
with C++, Objective-C, etc. he wouldn't have designed Eiffel in the first place.

I'm sure that Brad Cox and Bjarne Stroustrup have similar feeling about their
languages.  The difference, however, is that Dr. Meyer has the courage of his
convictions to debate them in public.  People who read comp.lang.eiffel
regularly see posting from Dr. Meyer debating various aspects of the language.
These are, in fact, *debates* NOT arguments, and I have seen Dr. Meyer post
articles several times that said "Ignore my previous posting, I was wrong and
John Doe was right".

I have heard stories from OOPSLA that Bjarne Stroustrup refused to sit on
the same panel with Dr. Meyer because Dr. Meyer was too critical of C++.  I
have heard this story from several different sources, but I still hope that
it is not true.  If OOPSLA is not the correct place to debate the various
languages then where is?

The fact that Dr. Meyer feels strongly about the OOP paradigm can only be
helpful to the entire field.  Dr. Meyer generally makes his points in a
clear, rigorous, manner.  People from all religions (C++, Objective-C,...)
should try to listen to his points with an ear towards how they could apply
his ideas to their languages.  I would be delighted to listen to Brad Cox
or Bjarne Stroustrup, it only they would participate in network discussions.


-Bruce 
=================================================
| Bruce Mount                 "Brevity is best" |
| bruce@atria.gsfc.nasa.gov                     |
=================================================

henry@utzoo.uucp (Henry Spencer) (03/07/90)

In article <885@pccuts.pcc.amdahl.com> tat@pccuts.pcc.amdahl.com (Tom Thackrey) writes:
> >... Incompetents should go somewhere where their
> >lack of talent will not be noticed, e.g. the local DoD contractor. :-)
> >(It's no accident that one big push for languages that try to legislate
> >competence comes from DoD...)
>Why is it necessary to slander some group or another to make a point?

Not necessary, just fun. :-)  Also verifiably true, I'm afraid, which is
generally considered adequate defence against charges of slander...
(This is not to say that there aren't some good software people working
for some DoD contractors, just that the average is very low.)

>BTW If they didn't notice why would they push ...?

Oh, they notice, but they keep signing contracts with the same people anyway.
They want a technical solution, not something simple and obvious like paying
enough to attract competent people and then refusing to buy from incompetents.
-- 
MSDOS, abbrev:  Maybe SomeDay |     Henry Spencer at U of Toronto Zoology
an Operating System.          | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

schow@bcarh185.bnr.ca (Stanley T.H. Chow) (03/09/90)

In article <TOMBRE.90Mar1013132@weissenburger.crin.fr> tombre@crin.fr (Karl Tombre) writes:
>In article <259@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:
>   From <Ec.3251@cs.psu.edu> by melling@cs.psu.edu (Michael D Mellinger):
>
>   > Personally, it's the little things like this that make me
>   > believe that everyone should ABANDON C and move on to C++(two others being
>   > function prototyping and strong type checking).  Waddya think?  Wither C?
>
>       How can the words ``strong type checking'' be applied to a language
			    ^^^^^^^^^^^^^^^^^^^^
>   in which any variable may be cast to any type? In which you declare the
>   type of a generic list element to be ``pointer to characters''?
>
>       C++ only magnifies the problems of C, and it does not even have the
>   excuses that can be invoked in the case of a 20-year old design such as C.
>   [and so on]
>
>Am I the only one having regularly the following problem?
>
> [...]      But from time to time, this attitude of his comes up and
>annoys me VERY MUCH : he seems to have difficulties accepting that
>there are other solutions for object-oriented programming, that other
			       ^^^^^^^^^^^^^^^
>languages exist and are popular for various reasons. He especially
>tends to become "rabid" when speaking of C++.  [...]

Perhaps you ought to *read* what you quote. It seems to me *you* are 
the one with the attitude problem.

Mr. Meyer stated one explicite objection - that C++ cannot be said to have
'strong type checking'. He also stated one general observation - that
C++ magnifies the problems of C. He made no comments regarding any of
the object-oriented features.

Since the thread is about the "robustness" of languages, and Mr. 
Mellinger suggested C++ for its strong type checking, I think it is
entirely fair for Mr. Meyer to comment on this topic.

If you disagree with Mr. Meyer, feel free to post why you think C++
does have strong type checking.

Stanley Chow        BitNet:  schow@BNR.CA
BNR		    UUCP:    ..!psuvax1!BNR.CA.bitnet!schow
(613) 763-2831		     ..!utgpu!bnr-vpa!bnr-rsc!schow%bcarh185
Me? Represent other people? Don't make them laugh so hard.

jimad@microsoft.UUCP (Jim ADCOCK) (03/09/90)

In article <259@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:

[Not totally without cause, IMHO]

>    How can the words ``strong type checking'' be applied to a language
>in which any variable may be cast to any type? 

How can the words 'strong type checking' be applied to a language that
gets its permissions on return types exactly backasswards?  Fix your
*own* language, before throwing stones, Bertrand!

In C++ not any variable can be cast to any type, although many questionable
casts are allowed *if specifically called for by the programmer*

In this light C++ follows the C lead of assuming the programmer is a mature
adult who can make his/her own decisions on these things.  Other languages
don't *really* prohibit programmers from doing these things where the programmer
desires -- if worse comes to worse, the programmer just breaks out the
old assembly language, and does what is necessary to get the job done.

A problem C++ has is that the C++ community has a large number of old
C hackers who run fast and loose with their coercions, and then find
that in C++ these hacks tend to bite them.  But, at least C++ *has*
this large community of old C hackers.  [Not to use the term "hacker"
in a totally derogatory sense]

The biggest problem [IMHO] is the continued heavy dependence by
many C++ programmers/implementations on the C Pre Processor --
which allows for textual substitutions to text code before the code
even gets to the C++ compiler.  Not only is the C Pre Processor
totally *not* type safe, it also allows programmer to make all kinds
of hacks to the [apparent] syntax of their code.  Further, the C Pre-
Processor makes simple tasks, such as the correct importing/exporting
of definitions a real nuisance.

>In which you declare the type of a generic list element to be 
>``pointer to characters''?

C++ provides "C" primitives like "pointer to char" that programmers can
use to create their own well encapsulated higher-level classes such
as "String."  Other OOPL languages, such as Eiffel, do not provide
this low level support.  Instead, the authors of these other languages
break out their handy-dandy "C" compiler and program up *one*
version of a "String" class that *all* users of the language must use --
even if it doesn't make the optimal speed/space/complexity tradeoffs
for that a particular user needs.  This heavy dependence on standard
libraries to do everything tends to mean that OOPLs taking this approach
only come from one vendor.  Better to provide compilers and libraries
separately, and allow users to choose which from where best meet their
needs.

C++ attempts to provide the power and flexibility to cover the entire
spectrum of programming tasks users need to do.  This includes the
power and flexibility to hose yourself, if you insist on doing so.

>    C++ only magnifies the problems of C, and it does not even have the
>excuses that can be invoked in the case of a 20-year old design such as C.

I am somewhat sympathetic to this complaint.  The latest definitions of
C++ try to be backwardly compatible with K&R C, ANSI-C, and previous
versions of C++.  In some areas, this makes for some pretty complicated
language rules.  This makes the life of compiler writers harder, so that
users can write C/C++ code as they are use to writing, and most of the
time their software will compile without compiler squawks.  Personally,
I think it would be good to give up some of the backward compatibility
in order to clean up some of the language rules.  Perhaps this will
happen as part of the ANSI-C++ standardization effort.  In any case, it
will be nice to have a standardize OOP language.

>All the flaws of the older language are still there; amount countless
>examples, the break and switch instructions, which were purportedly
>responsible for the AT&T breakdown (and started this whole discussion)
>are still there exactly as in C. The bug would have occurred identically.

C++ OOP programmers avoid switch statements as not being "object oriented,"
so propagating this "C" bogosity to C++ is not much of a problem.  Compilers
can choose to warn against missing break statement, if the compiler writers
so choose.  Better yet, an OOPL compiler should warn against using
switch statements in the first place!  

>    Then there are new complexities and major new trouble spots -
>such as default static binding, which means the guarantee that the
>*incorrect* version of an operation will be applied!

I disagree.  If a programmer wants a member function to answer to a
particular abstract protocol, the programmer creates such an abstract
protocol, marking its member functions "virtual", and inherits the
protocol in concrete classes matching that protocol.  Member functions 
in those concrete classes that match the abstract protocol are 
automatically default dynamic binding.  The "default static binding" 
you mention keeps classes with method names that *accidentally* match 
the names of parts of protocols from being considered such.  
This prevents the problem common in other OOPLs where method names 
accidentally match, causing problems not detected [if ever] until run time.


As always, the proof is in the pudding.  I encourage people new to
OOP to actually *try* several languages in "non-trivial" tasks,
and see how well those languages, and their compilers, meet you needs.
Your smilage will vary.

[Standard disclaimer, these are *my* opinions only.  I do not disagree
 with Bertrand entirely, only in degree.]

bertrand@eiffel.UUCP (Bertrand Meyer) (03/09/90)

From <2628@castle.ed.ac.uk> by nick@lfcs.ed.ac.uk (Nick Rothwell):

> The [Eiffel] type system seems a bit shakey to me.

From <53012@microsoft.UUCP> by jimad@microsoft.UUCP (Jim ADCOCK):

> How can the words 'strong type checking' be applied to a language
> [i.e. Eiffel] that gets its permissions on return types exactly
> backasswards?  Fix your *own* language, before throwing stones, Bertrand!


    Every once in a while someone ``discovers'' that the Eiffel type
system is ``wrong''. The latest printed occurrence I know of is a letter
published in the last JOOP.

    The Eiffel type system is neither ``shakey'' nor wrong. I have
written a long paper (posted in comp.lang.eiffel as
<176@eiffel.UUCP> and <177@eiffel.UUCP> in July of 1989)
explaining why the type rules are what they are. This answered in
particular an earlier paper by William Cook. My paper has not been
published in print (for lack of time and because I will
reuse it as book chapter), but it has been fairly widely circulated
since it was first posted.

    Denying the validity of Mr. Rothwell's statement would be
contradicting a matter on which he is better informed than I am:
his personal opinion regarding the Eiffel type system.
There is no reason to doubt that the statement is true,
although it provides information about Mr. Rothwell, not about Eiffel.

    It is not, however, a very pleasant statement, for impressions are
easy to spread and hard to fight.

    This is like when a person is being criticized: if Paul says Peter
has stolen Paul's car, Peter can defend himself; if Paul spreads
the rumor that Peter is a shady (or shaky) character, what can Peter do?
I have strong opinions, and have not been shy in publicizing what
I think of C++, but I have endeavored to focus on concrete technical
arguments addressing specific points. Reciprocality will be appreciated.

    Mr. Adcock's suggestion is gratefully acknowledged but
Eiffel's type system needs no fixing. I have had some trouble
understanding his message; first I do not know the word ``backasswards'',
although my limited but improving knowledge of English leads me to
gather that this word is not likely to carry an entirely favorable
connotation. Second, I have not heard anyone else criticize the
Eiffel rule for redefining the ``return type'' (which I understand
as the type of a function's result). In Eiffel this has to be a
descendant of the original type, not raising any problem that I know of.

    What has been criticized before (and I must assume this is what
Mr. Adcock really had in mind) is the rule for routine arguments,
which is the same as for results. This shocks many people who approach
the problem from a purely theoretical perspective; the absence of a
precise discussion of this topic in my book ``Object-Oriented Software
Construction'' did not help here. (Obviously I should have been more
careful.)

    Unfortunately for the theoreticians, the Eiffel rule is the one that
makes sense in practice. To take a very simple example, take the generic
class

    LIST [T]

with a procedure

    insert (x: T)

Assume a class and one of its heirs, for example STUDENT and its heir
UNIVERSITY_STUDENT. With the declarations

    sl: LIST [STUDENT] 
    usl: LIST [UNIVERSITY_STUDENT] 

the call ``sl.insert (s)'' should be valid for any s of type STUDENT,
but the call ``usl.insert (s)'' should be valid only for s of type
UNIVERSITY_STUDENT. The ``contrapositive'' rule advocated by some
would require that the version of ``insert'' for class
LIST [UNIVERSITY_STUDENT] take arguments whose types are *ancestors*
of STUDENT! This does not make sense - nor does the rule suggested by
the authors of the JOOP letter, according to whom it should not be
possible to change the argument types. They cite this as being the C++
rule. My congratulations to anyone who can write  useful software
in these conditions. (This is impossible, of course, and is one
of the reasons why undisciplined type casts are constantly needed
in such a context. I think this makes a mockery of
object-oriented ideas.)

    What the above simply means is that type checking in an
object-oriented language is more difficult than what a two-minute
peek at the problem might suggest.

    By the way, Eiffel's genericity (parameterized classes, such as
LIST [T]) only makes the problem more visible; the same argument could
be applied without any use of genericity.

A few more comments:

1. It would be immensely pleasurable if critics of the Eiffel type
rules would work under the assumption that Eiffel's designers,
although they have made mistakes and will undoubtedly make
more, are not *totally* incompetent.

2. In the same vein, our experience may have given us a perspective that
not all outside commentators enjoy. We have written tens of thousands of
lines of typed, reusable object-oriented software, including libraries
that are used daily by hundreds of people. Once again
this does not make us infallible, but I know of very, very few people in
the world today who have that kind of experience, and the appreciation
it gives for what works and what does not.

3. I have seen no one mention what I think is one of Eiffel's
significant contributions: a type system which is fully uniform, and
entirely based on the notion of class. Even integers and booleans are
theoretically based on classes (through ``expanded types''), with no
loss of efficiency at the implementation stage.

4. One thing that does need fixing is the amount of type checking done
by our current compiler, which misses some cases. The reason this has
not been done before is that these cases occur extremely rarely in
practice (for example there has not been a single recorded case in our
company), so that we have devoted our forces to more urgent tasks.
However the situation will be corrected in the next major release.

5. I have known for a long time Luca Cardelli's elegant work
(A Semantics of Multiple Inheritance, in Semantics of Data Types,
edited by Gilles Kahn, David B. McQueen and Gordon Plotkin,
Lecture Notes in Computer Science 173, Springer-Verlag, New York,
1984, pp. 51-67). This denotational model of some of
the properties of inheritance suggests a contrapositive rule.
Enamored as I may be of denotational semantics, however, I think that in
science theories should be made to fit reality, not the other way around.
Physicists are not supposed to change experimental results which do not
agree with the model.

This, of course, assumes somewhat arrogantly that Eiffel's rules
are ``the reality''. Quite frankly, I would prefer the
type rules to be as simple as Cardelli's work suggests but,
as mentioned above, I don't see any other usable solution than Eiffel's.
If someone can come up with a better suggestion, I will be the first
to embrace it. In the meantime, we'll have to live with a useful
practical solution even if it pains the theoreticians. Sorry.

6. Finally, our group does not just talk about Eiffel but also
implements it. The type rules that we use makes type checking more
difficult. Like everyone else we prefer easy jobs to hard jobs;
one more reason to welcome any simpler solution - provided it also
works.

-- Bertrand Meyer
bertrand@eiffel.com

munck@linus.UUCP (Robert Munck) (03/09/90)

I wonder if others have noticed that there's a single strong divisor
in this thread, separating it into two warring groups.  It corresponds
roughly to the C/Ada division, also C/anti-C and anti-Ada/Ada.

Basically, it's the "world view" that programming is a solitary activity
or a communal one.  That is, that programming is done by one person, with
little or no contact with others, or that it's done by a group of some
size, in constant close contact and also spread out in time and space.

That dicotomy obviously splits the university crowd from the military-
industrial crowd; universities have the problem that cooperative work
is called "cheating" in most other areas, so it's difficult for them to
take any other approach to s/w eng.  The m-i complex people have the
problem that they cannot take the risk of entrusting a project to a
single or small number of people because of the possibilities that they
will be hit by a bus, poisoned at the local Chinese restaurant, or leave
the company.

I don't know how the differences can be reconciled.
                          -- Bob Munck, MITRE ==> Unisys (STARS)
-- 
                 -- Bob <Munck@MITRE.ORG>, linus!munck.UUCP
                 -- MS Z676, MITRE Corporation, McLean, VA 22120
                 -- 703/883-6688

woody@eos.UUCP (Wayne Wood) (03/10/90)

In article <101567@linus.UUCP> munck@linus.UUCP (Robert Munck) writes:
>
>That dicotomy obviously splits the university crowd from the military-
>industrial crowd; universities have the problem that cooperative work
>is called "cheating" in most other areas, so it's difficult for them to
>take any other approach to s/w eng.  The m-i complex people have the
>problem that they cannot take the risk of entrusting a project to a
>single or small number of people because of the possibilities that they
>will be hit by a bus, poisoned at the local Chinese restaurant, or leave
>the company.
>
>I don't know how the differences can be reconciled.

just get rid of the M-I complex

:-)

just another '60's throwback
:-)


/***   woody   ****************************************************************
*** ...tongue tied and twisted, just an earth bound misfit, I...            ***
*** -- David Gilmour, Pink Floyd                                            ***
****** woody@eos.arc.nasa.gov *** my opinions, like my mind, are my own ******/

chris@mcc.UUCP (Chris Robertson) (03/12/90)

In article <1990Mar4.005122.14121@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>
>Yeah, I was a C novice once.  I'm glad that all the code I wrote then
>is dead and buried.

Oh no it ain't, Henry -- I saved it all, and it's available to any who
ask for just a modest fee...  hey, I could post sections of it, and we
could all discuss it!  

(I guess I could skip the latter step if you were to to mail me Mucho$ Buck$,
in small bills, in a plain brown wrapper...) 

(It's always nice to feel one's years at University weren't wasted -- of
course, I *was* supposed to be studying Zoology at utzoo, not creative
entrepreneurship and advanced blackmail! ;-)
-- 
"Down in the dumps?  I TOLD you you'd     |    Chris Robertson
 need two sets..."                        |  chris@mcc.pyrsyd.oz

henry@utzoo.uucp (Henry Spencer) (03/14/90)

In article <101@mcc.UUCP> chris@mcc.UUCP (Chris Robertson) writes:
>>Yeah, I was a C novice once.  I'm glad that all the code I wrote then
>>is dead and buried.
>
>Oh no it ain't, Henry -- I saved it all, and it's available to any who
>ask for just a modest fee...  hey, I could post sections of it, and we
>could all discuss it!  

Sorry, Chris, my *real* C-novice days were back before you knew me, and
the code from then really is dead and buried.  Thank heavens. :-)  I'd
been using C for about five years by the time I started working at utzoo.
This is not to say there isn't some slightly embarrassing code from more
recent times...
-- 
MSDOS, abbrev:  Maybe SomeDay |     Henry Spencer at U of Toronto Zoology
an Operating System.          | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

weiner@novavax.UUCP (Bob Weiner) (03/14/90)

not all outside commentators enjoy. We have written tens of thousands of
lines of typed, reusable object-oriented software, including libraries
that are used daily by hundreds of people. Once again
this does not make us infallible, but I know of very, very few people in
the world today who have that kind of experience, and the appreciation
it gives for what works and what does not.
-- 
Bob Weiner, Motorola, Inc.,   USENET:  ...!gatech!uflorida!novavax!weiner

weiner@novavax.UUCP (Bob Weiner) (03/14/90)

[Please pardon and disregard my last message which was inadvertently
posted prior to my writing it.  This is the intended message.]

In article <264@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:

> We have written tens of thousands of
> lines of typed, reusable object-oriented software, including libraries
> that are used daily by hundreds of people.

As a user and supporter of Dr. Meyer's work on Eiffel, I feel qualified
to take exception with his statement above.  I certainly am unaware of
any code that ISE (Dr. Meyer's company) has not yet released publicly
but I hesitate to label the present set of Eiffel class libraries from
ISE as 'tens of thousands of lines of ... reusable ... software'.

It is true that the code may be reused, as may any code, but the present
state of the libraries does not put them in the class of what I believe
any experienced developer would want in reusable classes.  More
precisely:

There are no performance characteristics given with any of the classes.

There is little in the way of documentation explaining the protocols
used by each class and the single line public comments associated with
most class features (routines and attributes) mask some often needed
information about the code internals.  That is, very often the external
specifications of features in these classes are quite incomplete.

There is hardly any internal feature documentation.

The class indexing provided with V2.2 is extremely spotty.


I should also say that most of these libraries do work as expected and
ISE is very generous with their source code licensing.  Additionally,
AT&T provides no significant class library with their C++ compiler;
hence I would definitely choose a broad working class library over none
at all (such commercially supported libraries will come, but they are
not here today).

My main point is that I simply can't imagine developing a system that
uses the Eiffel libraries without examining the source code.  Development
through conformance to external specifications is truly my hope for when
we reach the dawn of 'reusable software components'.
-- 
Bob Weiner, Motorola, Inc.,   USENET:  ...!gatech!uflorida!novavax!weiner