Xref: utzoo comp.lang.c++:3896 comp.lang.eiffel:295
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!agate!ucbvax!tut.cis.ohio-state.edu!att!cbnewsc!nevin1
From: nevin1@cbnewsc.ATT.COM (nevin.j.liber)
Newsgroups: comp.lang.c++,comp.lang.eiffel
Subject: Re: Eiffel vs. C++
Message-ID: <1559@cbnewsc.ATT.COM>
Date: 5 Jul 89 23:41:09 GMT
References: <2689@ssc-vax.UUCP> <6590138@hplsla.HP.COM> <149@eiffel.UUCP> <1989Jun8.172152.2069@mntgfx.mentor.com> <166@eiffel.UUCP>
Reply-To: nevin1@ihlpb.ATT.COM (nevin.j.liber)
Organization: AT&T Bell Laboratories
Lines: 73

Disclaimer:  these are my PERSONAL opinions, period.  I agree with some
of the points; I am mainly commenting on those I disagree with.

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

|3. Some constructs are known to be dangerous, meaning that programs
|employing them are prone to contain damaging errors.
|In any language meant for industrial production, it is the language
|designer's responsibility to exclude such constructs.

|    Examples include type casts, user-controlled memory deallocation,
|pointer arithmetic, in-line functions (in an object-oriented language)
|etc.

Unfortunately, stuff like type casts and user-controlled memory
management tend to be useful in many contexts.

|4. The purpose of excluding a construct is not to prevent
|programmers from writing bad programs or doing ``dangerous things'' if
|they want to. (See points 1 and 2.) Instead, a construct is excluded
|because it is known to lead programmers to make mistakes even when
|applied towards legitimate goals.

But, as a USER, I really don't care what the *purpose* behind doing
something is.  For example, the *purpose* behind putting in ramps in
sidewalks wasn't to allow kids to ride their bicycles into traffic
without having to stop like they had to for curbs, yet that was the
*result*.

|The restrictive parts of the language design are not meant to prevent
|the programmer from being ``bad'', but rather to help him avoid
|known pitfalls and involuntary mistakes.

But they DO prevent the programmer from being ``bad''; that is the
price that is being paid in order to help him avoid known pitfalls and
involuntary mistakes.

|6. Literal compatibility with previous languages should not be a
|criterion. People will learn a new language quickly if its design is
|simple and consistent. One should learn from the mistakes of the past, not
|perpetuate them.

|    Some care should be exercised, however, when one deals with programmers'
|current habits. For example, a new language should not use an existing
|notation in a way that confusingly departs from its accepted semantics.
|(The Eiffel assignment operator, :=, is a case in point;
|its semantics would probably have been different were it not for the fear
|of confusing Algol-Pascal-Ada programmers.)

Keeping 6 in mind, and assuming that you wanted to give the Eiffel
assignment operator different semantics than those given by
Algol/Pascal/Ada to ":=", why didn't you just pick another symbol (eg:
".=")?  Please elaborate.

|7. Perhaps my major personal guideline is to maximize the signal-to-noise
|ratio of the language.

|    Exclude constructs that just add complexity to the language without
|bringing any significant new possibility (for example, varieties of
|loops); include constructs that tersely and elegantly address a large number
|of practical situations.

But varieties of loops, if used correctly (admittedly, a big if), can
add to the self-documenting aspect of a language.


This whole discussion reminds me of an early paper by Wirth which I
read a while back (I wish I could find that paper :-().  In it, he
spends the first half describing his ideal programming language, which,
to me, seemed close to C, and then spent the second half saying that it
was unusable because you couldn't guarantee safety.
-- 
NEVIN ":-)" LIBER  AT&T Bell Laboratories  nevin1@ihlpb.ATT.COM  (312) 979-4751