(e-mail address removed) (Kaz Kylheku) wrote in message
[ ... ]
The function belongs with the arguments; enclosing it together with
them expresses this grouping.
Quite the contrary -- the function is something radically different
from its arguments. Even if a function accepts other functions as
arguments, the function being invoked is treated and used entirely
differently from the argument(s).
[ ... ]
But:
(obj.*pmemb)(x, y); // .* low precedence, parens needed!
Ooops.
If you move the function to the right of the parenthesis, these
ambiguities disappear.
First of all, you should be sufficiently aware of programming language
terminology to be well aware that this is NOT an example of an
ambiguity. It's true that the default precedence in C isn't always
right -- but it's NOT true that this leads to an ambiguity. The
meaning without parentheses may not be what you wanted, but that
doesn't mean it's ambiguous at all.
C defines operator precedence that works correctly (at least by doing
some looking through my code) well over 95% of the time. Lisp never
requires parentheses to override default operator precedence, but only
because it throws out the baby with the bathwater -- rather than
requiring parentheses to fix the precedence in a tiny minority of
cases, it requires parentheses in _every_ case, no matter _how_
obvious the right thing to do is.
[ ... ]
The text is in fact mostly words and spaces. The, punctuation, is,
quite, minimal, compared, to, C++, Pascal, Etc. What a waste of
keystrokes; what do the commas accomplish? They disambiguate things
like x, ++y versus x++, y.
The do considerably more than that -- they (along with C's plethora of
other syntactical clues) provide enough differentiation that the eye
tracks it much more easily.
Hopefully we can start by agreeing that to somebody who doesn't know
the language at all, that nearly every programming language is
_completely_ unreadable -- Cobol is the only thing that really even
tries, and one of its unique dangers stems directly from the fact that
people _think_ they understand it long before they really do. Neither
C, nor C++, nor Lisp, however, presents much danger in this regard.
As such, at least _some_ degree of familiarity with the language at
hand is required before "readability" really has much meaning.
With that given, tests have repeatedly shown that C is far more
readable than Lisp. Just for an obvious example, consider finding
problems in code, such as:
int fact(int x) {
if (x == 0);
return 1;
return x * fact(x-1);
}
and:
(define (fact x) (if (= x 0)
(1
(* x (fact (- x 1))))))
In my testing, C programmers find the problem in the C code an average
of more than five times as fast as Lisp programmers find the problem
in the Lisp code. In addition, C compilers almost universally give
SOME sort of complaint pointing (at least indirectly) to the problem
in the C code (typically pointing out the dead code) while Lisp
compilers (and interpreters, the last time I looked) generally accept
the latter code without so much as a peep.
One syntactic sdidiocy is patched over
with another. What a false economy; just so that you could have these
prefix operators and whatnot, you have to type extra punctuation even
when you are not using them!
Lisp hardly provides a suitable platform from which to launch such a
diatribe. Rather the contrary -- Lisp has more extra punctuation than
nearly any other language extant.
In any case, while counting keystrokes has some meaning when
evaluating calculators (yes, I still use HPs), typing in punctuation
on a normal keyboard rarely seems to be a real source of major
problems. If terseness is your measure of choice anyway, then any
choice other than APL seems nearly indefensible for you.
