Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!hub.ucsb.edu!eiffel!bertrand
From: bertrand@eiffel.UUCP (Bertrand Meyer)
Newsgroups: comp.lang.eiffel
Subject: Re: Assertions and deferred routines
Message-ID: <428@eiffel.UUCP>
Date: 23 Oct 90 19:51:53 GMT
References: <443@kepler1.kepler.com> <420@eiffel.UUCP> <1990Oct22.181347.6410@gorgo.ifi.unizh.ch>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 81

From <1990Oct22.181347.6410@gorgo.ifi.unizh.ch> by
schaerer@gorgo.ifi.unizh.ch (Daniel Schaerer):

> I have a cosmetic problem with the proposed syntax
> ["require >  else ..." and "ensure then ..."].
> [...] I think it is not very readable
> for humans, a very important aspect in language design in my opinion.
> I'd rather like to see something verbose like
> 
>      alternatively require ``additional precondition''
> 
>      additionally ensure ``additional postcondition''
>  
> Did you ever consider any proposal along these lines?

	All Eiffel keywords are simple English words. I would personally be
somewhat uncomfortable with a keyword such as ``additionally'',
given the probability of misspelling. (Considering the possibility
of using one `d', two `t', two `n' or one `l', this gives 15
possible misspellings for non-native speakers, bad spellers, or careless
typists!)

	It is certainly true that readability is an important criterion,
but it is not the same thing as verbosity. In particular, mimicking
natural language is not a solution: programming languages are very
simple codes, quite far from the complexity and wealth of expression of
English or another natural language. We want their syntactic structure
to reflect this simplicity; on the other hand, we do want
programming languages to be reminiscent of natural language,
hence the use of English words as keywords and other conventions
borrowed from human language. These two criteria are somewhat
contradictory; if you focus on just one of them, you get at
one end APL and at the other Cobol. The concrete syntax of
most programming languages is in-between. I cannot guarantee that
the Eiffel solution is perfect, but I can claim that the
design choices were made carefully and consciously.

	For a programming language, I would take ``readability'' from the
viewpoint not of an arbitrary reader but of one who has a basic
knowledge of the language. If person X, who does not know Eiffel,
looks at an Eiffel class text and cannot understand what a ``require
else'' clause stands for, this is regrettable, but not a tragedy.
The more important questions relate to users Y, who has taken a couple
of hours to read an introduction to Eiffel, and Z, who is a frequent
Eiffel user. The questions are:

	- Assuming Y has read the few lines about precondition weakening
	and postcondition strengthening, will he remember the convention
	right away when he comes across a ``require else'' in an existing
	class?

	- Will Z learn quickly the convention and be able to apply it
	frequently without hesitation (that is to say, without going back
	to the language manual)?

I hope the answer to both questions will be yes.

	Once the language designer begins to consider that his immediate
constituency is Y and Z more than X (although X is not to be neglected,
of course, since we do want to turn him soon into a Y or Z),
then ``verbosity'' yields to criteria such as regularity and consistency.
To take a cosmetic example from another part of the language,
a ``microscopic'' view of readability would suggest that
a Feature_clause be introduced by the keyword `features' since it can
declare an arbitrary number of features. Instead, the keyword is `feature',
in keeping with a general Eiffel convention according to which
all nouns used as keywords are in the singular. Here the more
macroscopic criterion is regularity. This is very close to
the criteria used in user interface design: more important than
local perfection is global consistency, the ``principle of least
surprise''.

	All this is probably overkill in response to a comment that
his author described as cosmetic. I won't fight for the ``require else''
and ``ensure then''; they are the best solution I could find
after looking at a number of alternatives. When all arguments have
been made, the final choice of concrete syntax is, to a point,
a matter of taste.
-- 
-- Bertrand Meyer
bertrand@eiffel.com