Re: The disturbing myth of Eiffel portability

[piercarl@sabi.demon.co.uk (Piercarlo Grandi)]

>>> "donh" == Don Harrison <donh@syd.csa.com.au> writes:

  donh> I think you'll find that when people refer to languages without
  donh> stating which version, they are typically referring to the
  donh> current incarnation.

piercarl> The incarnation of the language or that of the language's
piercarl> name? For it is often the case that the same name is used to
piercarl> label rather different languages, not more or less minor
piercarl> revisions of the same language.

donh> The language. Yes, this only applies to languages with a single
donh> line of descendants (eg. Ada, Eiffel). Where the evolutionary tree
donh> branches, it only makes sense to speak of specific variants. [
donh> ... ]

Ahhh, but it's not as simple as that. In part because it's often not
clear what is the ``current'' incarnation of a language; in part
because, and that was my main point w.r.t. to the Eiffel-Eiffel 3
distinction, to me Eiffel 3 is logically a branch on the Eiffel
descendancy tree, not a linear descendant, and that continuining to call
it ``Eiffel'' is thus somewhat misleading, for it implies a degree of
continuity that is not there.

  In the case of Eiffel-Eiffel 3 this device probably has been
  detrimental to the popularity language: for Eiffel and Eiffel 2 have
  earned here and there a reputation as somewhat impractical, because of
  limitations in the language; these *have been corrected* (somewhat
  ilegantly but rather effectively) in Eiffel 3. Giving an impression of
  continuity, instead of the underlining the very large differences in
  Eiffel 3, seems a good way to make those users that were skeptical
  about Eiffel/Eiffel 2 not give Eiffel 3 a second look.

  Conversely with ``C++'': having a name that closely recalls that of
  its predecessor, that predecessor being ``C'', can only help. In fact
  the various successive versions of ``C++'' are about as different from
  each other as ``C++'' is from ``C'': but indicating them all with the
  same generic label again helps, for they have all been popular and
  well accepted, and hiding, rather than underlining, their differences
  is a better strategy therefore than claiming loudly ``new improved'',
  as IMNHO should be done with Eiffel 3.

piercarl> [ ... more whining about the ambiguous meaning of language
piercarl> names without version number and rather different languages
piercarl> being distinguished rather misleadingly just by a version
piercarl> number, and whether ... ]

[ ... ]

piercarl> Is ``C++'' the current ``C'', as it incldues the latter as a
piercarl> subset?

donh> Hasn't C evolved separately? This is the real issue, IMO. BTW, I
donh> thought C++ *wasn't* a superset of C

Ahhhh, now this is amusing. Note that while you write "C++" and "C" as
they were well defined terms (and you did w the I wrote ``C'', not "C", for the
definiton of the latter term is precisely what the difficulty is
about. ``C++'' has always included a ``C'' subset, by design, to the
point that ANSI C has been based in large part on this ``C'' rather than
on ``K&R C''.

The situation is rather subtle here. At the very least there are
_several_ popular ``C'' languages out there, ignoring the very early
ones: the one that came with UNIX edition 6 (the one without 'enum's and
with the lax rule about 'struct' member names), the one that came with
UNIX edition 7 (the one with 'enum's and 'void' etc.) and documented in
K&R 1st edition, ANSI C (the one documented in K&R 2nd ed.), and various
versions of ``C++''.

Now, let's just call C (K&R 1st ed.), ANSI C (K&R 2nd ed.) and C++
(C++ARM) for convenience.

C++ includes both C and ANSI C as closely as possible; indeed Bjarne
Stroustrup quite correctly insists in his book on C++ evolution that
including some fairly narrowly defined sort of ``C'' as a subset of
``C++'' was important:

TDEC++> C compatibility was the first major controversial issue we had
TDEC++> to face. After some occasionally heated debate, it was decided
TDEC++> that 100% C/C++ compatibility wasn't an option. Neither was
TDEC++> significantly decreasing C compatibility. C++ is a separate
TDEC++> language and not a strict superset of ANSI C and can't be
TDEC++> changed to be such a superset without seriously weakening the
TDEC++> guarantees provided by the C++ type system -- and without
TDEC++> breaking millions of lines of C++ code. Similarly, any
TDEC++> significant decrease of C compatibility would break code,
TDEC++> complicate the creation and maintenance of mixed C and C++
TDEC++> systems, and complicate a transition from C to C++.

This means in practice extreme compatibility with other ``C''s to the
point that as he writes elsewhere in the same book the examples in K&R
2nd ed. were developed/checked using a C++ compiler:

TDEC++> This principle has lately been knows as "As close as possible to
TDEC++> C -- but not closer" after the title of a paper written by
TDEC++> Andrew Koenig and me. One measure of the success of this policy
TDEC++> is that every exmaple in K&R2 is written in the C subset of
TDEC++> C++. Cfront was the compiler used for the primary testing of the
TDEC++> K&R2 code samples.

As things stand, both ANSI C and C++ can well claim to be the current
``C'': both are extended versions of classic (K&R 1st ed., arguably) C;
it's also arguable (and I would agree) that C++ is a "better C" than
ANSI C, and perhaps by now it is also more popular. Indeed I suspect
that right now or perhaps soon most users will adopt the same point of
view as that reported by Bjarne Stroustrup above and come to use ``C''
as ``C++ lite''.

Not everywhere; another interesting remark is:

TDEC++> In addition to the many formal constraints on a standards
TDEC++> committee, there is an informal and practical one: Many
TDEC++> standards are simply ignored by their intended users. For
TDEC++> example, the Pascal and Pascal2 standards are almost completely
TDEC++> forgotten. For most Pascal programmers, ``Pascal'' means
TDEC++> Borland's greately extended Pascal dialect. The language defined
TDEC++> by the Pascal standard didn't provide features users considered
TDEC++> essential and the Pascal2 standard didn't appear until a
TDEC++> different informal ``industry standard'' had established
TDEC++> itself. Another cautionary observation is that on UNIX most work
TDEC++> is still done in K&R C; ANSI C is struggling in that
TDEC++> community. The reasons seems to be that some users don't see the
TDEC++> technical benefits of ANSI/ISO C compared to K&R C outweighing
TDEC++> the short term costs of a transition.

donh> - at least, that's what Wiener & Pinson says.

Correctly from a strict point of view: if only because the presence of
extra reserved words in C++ makes some valid ``C'' programs invalid in
``C++''. But as illustrated above, it's rather more subtle than that.