Re: language design tradeoffs

eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig) writes:
|> This whole thread about ergonomics and language design getting a
|> little out of hand. The only _real_ criteria judging ease-of-use of a
|> language that is at all relevant is (1) how easily can programs be written
|> in it and (2) how understandable are these programs
|> _with_respect_to_experienced_users_of_the _language_! [...]


There are two other criteria: (3) how long does it take to become
"_experienced_users_of_the _language_", (4) how productive are these
experienced users compared to users (of any experience level) of other
languages. These ergonomic questions you deride are the ones which
address these very issues.


|> [...] For example, when
|> teaching Pascal, (and after coding in C for too long!) I've found that the
|> most commonly made simple syntax error is the use of the semicolon as a
|> terminator rather than a separator, leading to the error "begin ... ; a:=
|> a+1 ; end". Students naturally make this error because they're thinking
|> about the semicolon in the wrong way, not because the use of semicolons as
|> statement separators is a bad idea. [...]


Well, actually I believe even Wirth now considers this a bad idea (what's
his most recent language do?). Modula dealt with the above problem by
eliminating the "compound statement" idea and by allowing empty
statements. Control flow syntax in Modula applies to blocks of statements
which are begun and terminated explicitly (though he overloads the symbol
`end' to terminate all the flow control constructs). And, while the
problem in Pascal decreases in frequency with expertise, it doesn't go
away completely even among experts.


|> The _real_ question about a language concerns its _learnability_,
|> rather than its naturalness. There's no _a_priori_ reason to expect
|> programs to read like novels. A good counter-example to the original
|> posted list of "good features" is Fortran. F77 had almost all of those
|> features: statements were terminated by EOL, comments weren't bracketed,
|> control statements weren't first-class, etc. Yet _nobody_ here would
|> claim that they find it easier to program in F77 than in, say, C. [...]


I would. For the applications for which it was designed, Fortran is
superior to C. For the applications for which C was designed, Turing is
superior to C - so are quite a large number of other languages. In fact,
Turing (with certain important extensions) could even be considered as a
Fortran successor - C certainly could not.


Further, you're attempting to discredit ideas based on association. Just
because a feature was in Fortran doesn't make it bad. There are other
problems with Fortran which overshadow its advantages (at least, for many
applications).


You're right, there's no a-priori reason to expect programs to read like
English prose. So, there's no reason to expect that they should span EOL
without meaning, etc.. The only evidence we have for what *should* be in
languages to make them more natural to learn and use suggests that EOL
should be the statement terminator, comments should also be terminated by
EOL, a missing statement terminator should be automatically detectable,
etc..


jlg@cochiti.lanl.gov (Jim Giles) writes:
|> Well, the experiment analysed error rates on a Pascal-like language. The
|> compiler at a university was rewritten to count the number of basic errors
|> and their causes. The result was that 20% of all syntax errors were
|> omitted semicolons at the end of a line. ...
|>
tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
|> Arguments like these for or against specific syntactic features are pretty
|> weak. First, consider the likely user population for a "Pascal-like
|> language" at a university. [...]


Well, if this is a weak argument in favor of EOL termination, then the
counter argument (which opposes the only available experimental data) is
even weaker.


|> [...] Second, the fact that (in this case) 20% of all
|> syntax errors happen to result from omitted semicolons tells you nothing
|> about the utility (or lack thereof) of those semicolons.


And, if there were experiments which showed results which contradict the
first, then I'd reconsider. However, the only experiments I've seen show
that EOL *should* be the statement terminator. And, they correspond well
to my own experience in helping users at this national laboratory while
working at our consulting office (our analogy to the "help desk"). This
later experience involves anything *but* university students. So, if you
have experiments which show that the exclusive use of semicolons *does*
have some useful utility, please present it.


|> [...] Language design should strive to choose syntax that
|> decreases the likelihood of such misunderstandings. Notational economy
|> doesn't necessarily make a language effective at achieving this goal, and
|> it may even hurt.


Exactly. That's why I recommend that statements should be explicitly
terminated (preferably with *either* semicolon or EOL), even though I
recommend that the statement syntax should be designed so that they can be
distinguished without such termination. However, there is no evidence
that requiring a semicolon *always* (just to avoid the rare use of a
continuation marker) is an improvement. In fact the only evidence
available tends to the other conclusion - that EOL *should* be the usual
statement terminator. Whether you consider this evidence strong or weak,
it's the only evidence there is.
--
J. Giles
--

Return to the comp.compilers page.
Search the comp.compilers archives again.