> Gerhard
>>> Of course. The more redundant (that is, verbose) the syntax is, the
>>> easier it is both for the programmer to get something wrong and for
>>> the compiler to catch when something is wrong.

Olin:
>> Not necessarily, and this is one of the problems with C.

Gerhard:
> What "not necessarily"? Sometimes, it seems you don't really try to
understand and go against, just because... :)
FWIW, and this is entiely about understanding each other's language, and not
about understanding 'the machine's' language, I read what Olin wrote,
understood it and largely agreed with it and it SEEMS to me that he
understood you but that you misunderstand him. He seems to have an entiely
valid point and to be addreessing a real issue. ("But,", as Sagan was wont
to say , "I may be wrong" :-) ).

This is NOT a criticism - just an observation.
And it may be wrong in fact.

>> It's not always as obvious to a human when the wrong special character
>> is used, for example, than a more verbose keyword.

>This is what I wrote: the more verbose, the easier to catch ("more
>obvious") when something is wrong.
To my ear/brain/eye [ebe], that is NOT what you wrote - My ebe says that you
are say ing the opposite of what Olin is saying.

> It is easier to get "{" or "}" wrong than the more verbose "begin" or
> "end", for example.

ie Olin is saying NOT that by random typing error you are more liable to get
a single character errot (which, as you correctly note, is not the case, on
a purely statistical basis. He is saying that if one substitutes any one of
{ or } or ) or ( incorrectly for some other member of the set, then one is
more likely to miss the eeeor than if one puts begin when one should have
put end.
Whereas { for } is a typo,

    begin
        blah blah blah
    begin

is a 'braino' which one would not makev (except on bank holidays at new moon
in a fish market).

You said (my ebe says)
     People are liable to make more mistakes and machines
     less with multi-character symbols compared to single
     character sumbols.

> I think here you're wrong. The probability to type a wrong letter is
> about the same per letter, so the probability to type "begin" wrong is
> higher than the probability to type "{" wrong.

As above - Olin was talking about mental parsing, not about statistical
typing erros.

>> The latter are bigger patterns to match against and more obvious when
>> they are wrong, especially to a casual observer.

> Exactly... for the reviewer or for the compiler, it's much easier to
catch the error with "begin" than with "{". This is what I wrote. So
again: what "not necessarily"?
/>

No. You actually said the opposite FOR A PERSON (my ebe says).

> > I had exactly this case last week.  I added one more symbol to a C
>> ENUM, and apparently typed ")" instead of "}" to close the list.
>> These two look fairly similar, so I didn't notice.  That, and the
>> fact that I don't do C that often caused several wasted minutes
>> trying to figure out why the code wouldn't compile.  The C18
>> compiler's cryptic "syntax error on line xxxx" didn't exactly help
>> either.
>It seems that the compiler didn't have a problem detecting that there
>was something wrong.

Yes. Which is his point. Olin had problems with the single character symbol.
The compiler didn't. That is the point he was making and the one that you
SEEMED to be opposing.


>That the compiler didn't provide you with a helpful
>error message is another issue -- that's not a problem with language
>syntax but with the specific compiler implementation.

Yes.

> I'm pretty sure that if I had been required to type END or something
> more verbose than "}", the mistake would never have happened or I
> would have noticed it much quicker.
You can define preprocessor macros and use Begin and End instead of {
and }.

Yes.
The main point (possibly :-) ) is that the double ended sharp bladed light
sabre has no guards on either end as that's the way the original expert
liked it, but when playing with it it's easy to lose a finger.
One can, of course, use a preprocessor to add guards and a scabbard.
Some of the 'expert' features are harder to "fix" with simple text
substitution pre-processing. eg the (if I recall the argument correctly)
fall through CASE treatment which the original expert probably didn't mind
but which allows people to make mincemeat of their programs if they do not
understand that it diffres from more protective languages.


     Russell

       Russell
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist