Subject: Re: Ousterhout and Tcl lost the plot with latest paper
From: Erik Naggum <>
Date: 1997/04/19
Newsgroups: comp.lang.scheme,comp.lang.scheme.scsh,comp.lang.lisp,comp.lang.tcl,comp.lang.functional,comp.lang.c++,comp.lang.perl.misc,comp.lang.python,comp.lang.eiffel
Message-ID: <>

* James Logajan
| NOTE TO LISP AND FORTH FANS: one important reason your languages have
| never caught on may be due to the fact that many natural languages follow
| the "subject verb object" form.  Usage of SOV, OSV, VSO, and VOS are less
| likely (I don't have any references in front of me; if anybody wants
| details, I'll try to locate what I have).  They also lack visual
| redundancy (they aren't alone in this short-coming of course).

I hope you find studies of human factors with _experienced_ users.  the
results coming from the ever-present inexperienced users has no validity
for more than inexperienced users, yet get touted as truths about the
languages.  this tends to annoy people who believe that "experience" is a
valid concept in any discipline.

for some reason, we don't see open heart surgery defamed by "research" into
how inexperienced users with a scalpel and an attitude kill people and that
it should therefore be a discommended practice.

many a Lisp programmer will testify that he thinks in Lisp and reads Lisp
code with _less_ "stack depth" and "cognitive load" than is needed for the
many other languages he knows.  e.g., I find C to be _much_ harder to read
than Lisp because I need to scan forward in hairy expressions a lot to know
how things work together, and to scan backwards for type information.  I
also have to work to remember operator precedence rules in the language.
in Lisp, I may have to scan back and upwards, but I've already been there
when I'm reading the code.  in C++, I need to keep in mind the classes of
all the variables so I can have a glimmer of hope of understanding _which_
function is being called.  the foo in is not the foo in, unless
the class of x and the class of y relate such that they are.  in CLOS, (foo
x) and (foo y) is the same generic function with different specializers and
a Lisp programmer is _much_ less likely to implement widely different
semantics with the same name than is a C++ programmer who is "alone" in his
class (hierarchy).

there should be a measure of "mental clutter" that each language leaves
with its (moderate to excellent) programmers.

somebody should tell those Subject-Verb-Object guys from the wrong
department that it is quite uncommon to nest sentences and expressions the
way it is done in programming languages, lest this invalid argument should
keep coming back from the argument grave yard yet again.  for some reason,
C/C++ programmers can't handle very deep nesting, while Lisp people can.
my take on this is that C/C++ already "use up" quite a number of "stack
levels" with its complex syntax, while Lisp does not, and can use those
"stack levels" for real work.

back in high school, I was reprimanded by my teachers for using too long
sentences and too complex sentence structure.  (my editors have said the
same.)  I found the rules they laid down for me to follow to be extremely
crippling in expressive power.  write short sentences.  use only simple
conjunctions.  don't use the passive voice.  the active voice helps
"involve" people.  this all gives me the creeps.  subject verb object.  I
just don't think that way.  I think of my sentences as evaluation of nested
expressions that yield intermediate values used by other parts of the
sentence and which conclude in communicating some meaning.  the paragraph
is similarly constructed to carry those sentence-values forward into a
concluding sentence.  this process _precludes_ the use of stunted forms and
the imperative, active style for me.  then again, I don't write children's
books or "Crotch Sniffing for Dummies".

and last time I checked, I was still human, despite all this bogus research
into human factors that pretends I and people like me don't exist.

I'm no longer young enough to know everything.