From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,dad65365cb2b3396 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,dad65365cb2b3396 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,bdaddde464f6e704 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,dad65365cb2b3396 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,dad65365cb2b3396 X-Google-Attributes: gid1014db,public X-Google-Thread: f43e6,bdaddde464f6e704 X-Google-Attributes: gidf43e6,public From: piercarl@sabi.demon.co.uk (Piercarlo Grandi) Subject: Re: The disturbing myth of Eiffel portability Date: 1996/11/30 Message-ID: X-Deja-AN: 201565200 x-nntp-posting-host: sabi.demon.co.uk x-disclaimer: Contents reflect my personal views only references: content-type: text/plain; charset=US-ASCII mime-version: 1.0 (generated by tm-edit 7.94) newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c,comp.lang.c++,comp.object,comp.software-eng Date: 1996-11-30T00:00:00+00:00 List-Id: >>> "donh" == Don Harrison 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.