Re: language design tradeoffs

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_! I could craft the
most beautiful, elegant, and politically-correct language in the world,
and somebody from Tanzania would still mispell the keyworlds frequently.
In fact, I could probably get a group of 100 Tanzanian programmers
together, make them use my language, and note that misspelling of the
keywords was a very common programming error. Does that mean that I make
a mistake by not using Tanzanian keywords?


As long as a language has a clear and simple syntax, easily
described with a few rules and without many quirky special cases, it will
become easy to write programs in this language. 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. As an example of a _bad_ syntax,
consider C's use of the semicolon: it serves as (1) the
expression-to-statement converter, (2) the null statement, (3) the control
expression separator in the "for" loop.


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. The
_pieces_ of F77 are easily understood by themselves; unfortunately, that
doesn't help one understand the aggregate.


Consider recursion. Most students learning how to program find
themselves baffled by the concept.


There are a bunch of new language features that are heading into
mainstream programming languages: first-class functions, polymorphism,
abstract data types, objects, etc. Each of these provides new expressive
power and has deep implications about the way people think about programs.
Is this a "natural" way of thinking? Well, probably not; most people
don't find any new programming construct natural at first. Consider
recursion. Most students learning how to program find themselves baffled
by the concept of recursion; most can't follow a complicated recursive
routine, and few still can write them. Does this mean that recursion is
an undesireable language feature? As Homey the Clown would say: "I don't
_think_ so!"


BTW, as long as we're on the subject of poor programming
languages, _nothing_ I've ever seen comes close to the filter language for
MH.
--
[Actually, I'd expect that most programmers in Tanzania would speak pretty
good English, given its history, but I suppose that's a little off the point.
-John]
--

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