Subject: Re: Ousterhout and Tcl lost the plot with latest paper From: Erik Naggum <erik@naggum.no> 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: <3070400361379585@naggum.no> * 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 x.foo is not the foo in y.foo, 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. #\Erik -- I'm no longer young enough to know everything.