Re: Is Smart Eiffel ready for large-scale application ? (Modula 3 and Eiffel verbosity and libraries)

fJoseph Kiniry wrote:

> Hi Wolfgang,
>
> --On 11 April, 2005 18:45:02 +0200 Wolfgang Jansen 
> <[email protected]> wrote:
>
>> Joseph Kiniry wrote:
>>
>>>>> - Eiffel is very verbose. I found myself always putting as much
>>>>>   functionallity into one class to avoid the handling of 100 files,
>>>>>   for compiler and editor performance. Java has the same problem so
>>>>>   maybe this is not a problem for you.
>>>>
>>>>
>>>>
>>>> The verbosity is what really gets to me.  Same in Modula-3, which I've
>>>> had extensive experience with.
>>>
>>>
>>>
>>> The same holds in any language that focuses on readability over
>>> terseness and has types and variable declarations.  It is a simple
>>> fact of language design.
>>>
>>>> Why is it that every object-oriented language is so wordy?  Java 
>>>> escapes
>>>> the long-keywords plague, but uses long standard-library names 
>>>> instead.
>>>
>>>
>>>
>>> Why is it that people would always trade a few characters for less
>>> intelligible code?
>>
>>
>> I think because fewer character make texts more intelligible!
>> You may this observe in natural languages as well as in artificial
>> languages
>> as mathematical and chemical formulas. When some new thing (or process,
>> situation ...)
>> has to be expressed in a language it will be expressed rather wordy.
>> When it is no longer new and has often to be expressed then the 
>> expression
>> will be soon reduced to a bar minimum. So, an Eiffel feature name like
>> `get_new_iterator_on_keys' is very nice when it is newly introduced in a
>> library,
>> or used for the first time by a newcomer. After some time one would be
>> satisfied with `key_iterator' or even `keys'. Most characters of the
>> original
>> long name are redundant for no gain, instead they are disturbing because
>> they prevent seeing more contents at once. In other words: less is more!
>>
>> (OK, this comment is a side step of this discussion thread's topic.)
>>
>>  WJ
>
>
> So your complaint is not about the verbosity of the language per se, 
> but the length of the identifiers chosen by most Eiffel programmers, 
> and promoted by the popular coding standards of the field?
>
> Just making sure I understand your position,
> Joe

Sorry, my comment was not precise enough. Long identifiers are
one form of verbosity making a program text less readable.
I have chosen long identifiers just for quick demonstration.
Another verbosity is using identifiers instead of operator symbols.
While it is true that we can define the semantics of "a+b" by
that of "a.add(b)" (for this purpose the dot form is unavoidable)
the former is much better readable than the latter and reduces
the risk of errors: formulas in a program should look like their
origins in a text book. In the same sense, most syntactic sugar
makes writing and reading of programs easier (yes, I like sweets).
(BTW, I like to write "a + b*c" instead of "a + b * c" or
"a+b*c", i.e. I try to group subexpressions by operator
precedence. I believe that the first form makes the formula
better readable than the others.)

Now, the verbosity of Eiffel per se. In general, I don't think
that Eiffel is very verbose (e.g. just "end", not "end if").
OK, some keywords might be replaced by symbols. For example,
the probably most often occurring construct "do ... end"
by "{ ... }". But "do" and "end" are short themselves and
are not the problem. What I hate is the proposed style, e.g.

   from
      i := 1
   until
      i > n
   loop
      ...
   end

instead of

   from i:=1 until i>n loop
      ...
   end

The first needs 5 times more lines than the second thereby
moving 4 LOC out of the reader's view, possibly onto the
next page. If ever possible, the entire syntactic construct
should be visible at once and it should be clearly separated
from other constructs. In the second form of the loop example
"from" and "end" are the well visible bounds. The loop limits
(which are not emphasized) are detail information and can be
read later when loop details become interesting.

I hope the really verbose comments make my point of view
a bit more precise.

WJ