Subject: Re: *Why* is LISP better? From: Erik Naggum <email@example.com> Date: 01 Aug 2002 18:31:34 +0000 Newsgroups: comp.lang.lisp Message-ID: <firstname.lastname@example.org> * John Gilson > Ironically, one of the most often heard criticisms of Lisp is its syntax, > e.g., Lots of Insipid Silly Parentheses. Can't please everyone! * Joe Marshall | Excerpts from real C header files: These phenomena are actually connected. In the Algol family, parentehses signal pain. In the Lisp family, they signal comfort. Since most people are highly emotional believers, even programmers, it is very hard for them to relinquish their beliefs in their associations of parentheses with pain and suffering. This has nothing to do with aesthetics, design rationales, ease of use, the value of the code-as-data paradigm, etc. This has everything to do with the deeply ingrained "knowledge" that you do not need parentheses unless you want to transcend the (overly simple) rules of the language. The psychology of programming has taught programmers in the Algol family that parentheses are to be minimized and that any large number of parentheses is a good sign that the code, or worse, the thinking behind it, is too complex. Because of such fundamentally ridiculous syntactic optimizations as the associativity and precendence of infix operators, which favors the writing of simplistic code and expressions so much that normal complexity is wildly exaggerated, such that out-of-the-ordinary complexity becomes intractable, we have trained a large number of programmers to abhor complex expressions that would be within reach if they had used parentheses with every operator. The result is that when they have to do what should have been normal, they associate it with the painful experience of getting it right and remembering when they have to do it because the language does not do what they want. Lisp is like telling an Algol-family programmer to write (x + (y * (z ^ t))) for x+y*^t, so it would not be different from (((x + y) * z) ^ t). Chances are an Algol-family programmer would not only balk at this because it goes against the grain of the language, he would get it wrong because he does not actually know the rules of his language. Back in the Dark Ages, when I gave courses in C, one of the most common problems my students experienced was getting the operator precedences right. I did not have the presence of mind to teach them never to rely on the stupid rules of the language but instead write it out explicitly and acquire that level of control that C programmers are so fond of at the machine level, but apparently not at the language level. For some reason that I cannot recount, I thought these stupid rules were worth memorizing and I still help people with them without looking it up. Today, if anybody let me near a school of newbies¹ who wanted to learn C, I would tell them to save themselves a lot of pain by thinking about what _they_ want and not about how to "optimize" their code to reduce the number of parentheses. Showing people tragically painful C code and arguing that there are just as many parentheses as in Lisp is the wrong psychological move, because you do _not_ want to carry the "tragically painful" part over from C. They key is to make C programmers understand that the ability to _omit_ some parentheses is the root cause of their painful experiences with the remaining parentheses and that the right way to write safe C is never to omit any parentheses. Then you will see just how many parentheses C actually _infers_ for you and you may get to appreciate the _smaller_ number of parentheses in Lisp. ------- ¹ That really should be the collective form for "newbie". -- Erik Naggum, Oslo, Norway ***** One manslaughter is another man's laughter. Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.