[comp.lang.eiffel] Eiffel language stability

bertrand@eiffel.UUCP (Bertrand Meyer) (05/01/89)

    Because two recent postings on language improvements for release
2.2 have described new traits (<133@eiffel.UUCP> on the type system and
<135@eiffel.UUCP> on the ``join'' subclause), it seems appropriate to
allay possible fears by reiterating that Eiffel will *not* change
much and will remain a small, easy-to-learn language.

    At the time the language description was published, the biggest
Eiffel system that had been written (to our knowledge)
was about 60,000 lines long. Since then applications have grown and
contributions at the Paris User Conference described an application
that currently includes 2000 classes totaling 350,000 lines of
Eiffel software, written by a group of 100 programmers. At such
a scale of use, it is inevitable that some tuning of the language
should appear necessary.

    In fact, remarkably little such need for change has surfaced.
I don't think I am betraying the participants' opinion in expressing
that the group agreed that the language was essentially fine as it is,
even for applications of the size cited.

    It is, however, necessary to bring in any extensions or changes
that appear necessary, and to do so before the crowds rush in.
This will be done in two stages:

    - A small number of extensions are introduced in release 2.2,
    addressing all significant known problem for which the solutions
    provided by the current language are not elegant enough, or are
    otherwise unsatisfactory. This includes the BITS types, infix
    and prefix operators, expanded classes and associated notions
    (see <133@eiffel.UUCP>), the ``join'' subclause
    (<see <135@eiffel.UUCP>), the ``Accept'' instruction for
    controlled assignment in the presence of possible type
    incompatibility, and the ``obsolete'' construct for disciplined
    library evolution. (Descriptions of the last two have not yet
	been posted.)

    No language incompatibility is introduced by these extensions,
    except for possible name clashes with the new keywords
    (which have been chosen so as to minimize the likelihood
    of such an event).

    - A few changes are planned for release 3 (late 1989). These are
    mostly syntactical cleanup and will be discussed in a forthcoming
    posting (with a request for comments).

    [A pending question is that of concurrency. I will remain
    silent on this point until when and if I or someone else
    publishes a complete solution. In other words, the existence
    of a concurrency mechanism for Eiffel and its nature are a
    recursively enumerable problem: if you see the answer, you know
    there is one, but if you don't it doesn't mean anything because
    the answer might be coming tomorrow or in the next century
    or not at all.]

    No significant language evolution is envisioned beyond the above.
My hope is that after the end of 1989 Eiffel will essentially
remain unchanged. Then everyone can work full-time on the truly
meaningful challenges: tools and libraries.
-- 

-- Bertrand Meyer
bertrand@eiffel.com