Re: (Modula 3 and Eiffel verbosity and libraries)

On Tue, Apr 12, 2005 at 01:10:58PM +0200, Wolfgang Jansen wrote:
> Frank Salter wrote:
> 
> >Wolfgang Jansen wrote:
> >
> >>Joseph Kiniry wrote:
> >>
> >>>Why is it that people would always trade a few characters for less 
> >>>intelligible code?
> >>
> >Because they extrapolate from some local truth and represent it as a 
> >global truth (frequently incorrectly).
> >It behoves us to remember that Algol 60 was introduced not as a 
> >programming language but as a language to represent algorithms.
> >[Personal aside -- How I have wished that Donald Knuth had used Algol 
> >to describe algorithms in "The Art of Computer Programming"]
> >
> >>I think because fewer character make texts more intelligible!
> >
> >True when the text is overblown.  Surely, if this were generally true, 
> >we would all be using shorthand or speed writing as the norm.
> >
> >>You may this observe in natural languages as well as in artificial 
> >>languages

Since we have brought in natural language...

Natural language tend to abbreviate until it gets to the edge on
unintelligibility.  Words fall out of idioms, words lost sounds,
and later syllables (e.g., the "gh" in "light" used to be pronounced,
and now people are starting to leave it out of the spelling).
There's also a limit to what people will remember.  Irregular
words tend to become regular if they are rarely used -- unless
the irregularity is enforced by a school system or a standards
committee (like the wcademie francais), and then its use becomes
a status marker for the speaker.  But at some point the tendency
towar elision becomes too great, and confusion arises.  Then
people try to speak precisely, and, when that fails, sdd on extra
words of context to make their meaning clear.  It's quite possible
over centuries for these words to become auxiliaries, and eventually
become absorbed into the main word as inflections.

So language eveloves both ways -- commonly used words become shorter,
and when things get ambiguous, long phrases are synthesised to
replace the short ones.  All this is to optimise the speed and
clarity of communication, which are conflicting goals.

This does suggest a few things for words in programming languages:
the common ones should be short.  Rarely used ones -- the ones an
experienced programmer might not use in an average program -- can
be long -- who cares?  But certainly words for common control
structures, names of common types, words used to delimit procedures
and declarations and the like whould all be short.  And words that
are so rare that a programmer is not likely to notice that he's
inadvertently used a reserved word should be long or otherwise marked
to minimize the chance of conflict.
> >
> >Some languages elide vowels in the written form.  I understand that 
> >this has led to misunderstandings and mistranslations..
> 
> Maybe the texts have not been written for the sake of modern translators.
> Maybe ancient Egyptian presbyters and modern Hebraic and Arabic people
> could and can read vowel-less texts very well.

Hebrew has acquires a set of vowel marks, presumably because they
can't read then as well as they would like.

> 
> >>as mathematical and chemical formulas. When some new thing (or 
> >>process, situation ...)
> >
> >As an engineer who used mathematics as a tool rather than it being my 
> >vocation, I have spent many hours reading extremely terse 
> >representations with which I was essentially unfamiliar.  I wished for 
> >less terse explanations of the thinking I was trying to understand.
> 
> Well, language depends on both, the speaker and the audience. So, if you 
> were not
> familiar with the extremely terse representation then, I think, you did 
> not belong to
> the targeted audience (and you had made efforts to join that audience).

What drives me crazy in papers on logic is when the writer introduces
a bunch of notation withoug making it clear what the procise syntax
is -- for example, the precedence of operators.  Often if you
understand the concepts he is presenting, the syntax is obvious,
and if you inderstand the syntax you can divine the semantics.
But trying to do both at once is too much.  This leads me to add
another criterion for progamming language:

If you know the language, you should be able to understand the
syntax of a program without understanding the meanings of the
programmier-chosen names in it.

-- hendrik