How Lisp's Nested Notation Limits The Language's Utility
Xah Lee, 2007-05-03
There is a common complain by programers about lisp's notation, of nested parenthesis, being unnatural or difficult to read. Long time lisp programers, often counter, that it is a matter of conditioning, and or blaming the use of “inferior” text editors that are not designed to display nested notations. In the following, i describe how lisp notation is actually a problem, in several levels.
(1) Some 99% of programers are not used to the nested parenthesis syntax. This is a practical problem. On this aspect along, lisp's syntax can be considered a problem.
(2) Arguably, the pure nested syntax is not natural for human to read. Long time lispers may disagree on this point.
(3) Most importantly, a pure nested syntax discourages frequent or advanced use of function sequencing or compositions. This aspect is the most devastating.
The first issue, that most programers are not comfortable with nested notation, is well known. It is not a technical issue. Whether it is considered a problem of the lisp language is a matter of philosophical disposition.
The second issue, about nested parenthesis not being natural for human to read, may be debatable. I do think, that deep nesting is a problem to the programer. Here's a example of 2 blocks of code that are syntactically equivalent in the Mathematica language:
In the latter, it uses a full nested form (called FullForm in Mathematica). This form is isomorphic to lisp's nested parenthesis syntax, token for token (i.e. lisp's “(f a b)” is Mathematica's “f[a,b]”). As you can see, this form, by the sheer number of nested brackets, is in practice problematic to read and type. In Mathematica, nobody really program using this syntax. (The FullForm syntax is there, for the same reason of language design principle shared with lisp of “consistency and simplicity”, or the commonly touted lisp advantage of “data is program; program is data”.)
The third issue, about how nested syntax seriously discourages frequent or advanced use of inline function sequencing on the fly, is the most important and I'll give further explanation below.
One practical way to see how this is so, is by considering unix's shell syntax. You all know, how convenient and powerful is the unix's pipes. Here are some practical example: “ls -al | grep xyz”, or “cat a b c | grep xyz | sort | uniq”.
Now suppose, we get rid of the unix's pipe notation, instead, replace it with a pure functional notation: e.g. (uniq (sort (grep xyz (cat a b c)))), or enrich it with a composition function and a pure function construct (λ), so this example can be written as: ((compose (lambda (x) (grep xyz x)) sort uniq) (cat a b c)).
You see, how this change, although syntactically equivalent to the pipe “|” (or semantically equivalent in the example using function compositions), but due to the cumbersome nested syntax, will force a change in the nature of the language by the code programer produces. Namely, the frequency of inline sequencing of functions on the fly will probably be reduced, instead, there will be more code that define functions with temp variables and apply it just once as with traditonal languages.
A language's syntax or notation system, has major impact on what kind of code or style or thinking pattern on the language's users. This is a well-known fact for those acquainted with the history of math notations.
The sequential notation “f@g@h@x”, or “x//h//g//f”, or unixy “x|h|g| f”, are far more convenient and easier to decipher, than “(f (g (h x)))” or “((compose h g f) x)”. In actual code, any of the f, g, h might be a complex pure function (aka lambda construct, full of parenthesis themselves).
Lisp, by sticking with almost uniform nested parenthesis notation, it immediately reduces the pattern of sequencing functions, simply because the syntax does not readily lend the programer to it as in the unix's “x|h|g|f”. For programers who are aware of the coding pattern of sequencing functions, now either need to think in terms of a separate “composition” construct, and or subject to the much problematic typing and deciphering of nested parenthesis.
(Note: Lisp's sexp is actually not that pure. It has ad hoc syntax equivalents such as the “quote” construct “ '(a b c) ”, and also “`”, “#”, “,@” constructs, precisely for the purpose of reducing parenthesis and increasing readability. Scheme's coming standard the R6RS ↗, even proposes the introduction of [] and {} and few other syntax sugars to break the uniformity of nested parenthesis for legibility. Mathematica's FullForm, is actually a pure nested notation as can be.)
------- The above, is part of a 3-part exposition: “The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations”, “Prefix, Infix, Postfix notations in Mathematica”, “How Lisp's Nested Notation Limits The Language's Utility”, archived at: http://xahlee.org/UnixResource_dir/writ/notations.html
On May 4, 5:11 pm, Xah Lee <x...@xahlee.org> wrote:
> How Lisp's Nested Notation Limits The Language's Utility
> Xah Lee, 2007-05-03
> There is a common complain by programers about lisp's notation, of > nested parenthesis, being unnatural or difficult to read.
That is false. The complaint does not frequently occur among all of the complaints occured by the entire population of complaintive programmers.
> (1) Some 99% of programers are not used to the nested parenthesis > syntax. This is a practical problem.
Since 99% of programmers don't use Lisp, it's not a practical problem.
> (2) Arguably, the pure nested syntax is not natural for human to read. > Long time lispers may disagree on this point.
Programming language syntax shouldn't be natural for humans to read. Or, rather, this shouldn't be a requirement which creates technical compromises.
> (3) Most importantly, a pure nested syntax discourages frequent or > advanced use of function sequencing or compositions.
That is an artifact of the way in which function composition is rendered in nested syntax, and not an artifact of that syntax itself.
There exist macros that provide alternate syntax for function composition, such as a left-to-right pipeline.
> This aspect is the most devastating.
Compared to issues like global warming and problems in the Middle East, hardly.
> The first issue, that most programers are not comfortable with nested > notation, is well known.
Many programmers are also not comfortable in social situations. So what?
> shell syntax. You all know, how convenient and powerful is the unix's > pipes. Here are some practical example: “ls -al | grep xyz”, or “cat a > b c | grep xyz | sort | uniq”.
> Now suppose, we get rid of the unix's pipe notation, instead, replace > it with a pure functional notation: e.g. (uniq (sort (grep xyz (cat a > b c)))),
When you think about this more deeply (i.e. at all) you run into nasty details. These programs pass their output to each other, but they also have a return value (termination status) which isn't passed through the pipeline. And they take arguments, but the arguments of a pipeline element are not derived from the previous pipeline element.
Your call (grep xyz (cat ...)) means to pass the output of cat as the third argument of grep.
In the POSIX shell, this would be coded using guess what, Lisp-like syntax:
grep xyz $(cat ...)
Taking it further:
uniq $(sort $(grep xyz $(cat a b c)))
or enrich it with a composition function and a pure function
> construct (λ), so this example can be written as: ((compose (lambda > (x) (grep xyz x)) sort uniq) (cat a b c)).
I posted a filter macro in comp.lang.lisp which expresses function chaining into a left-to-right notation. Look for it.
In this notation, you might write:
(filter 3 (expt _ 2) (* 4))
which means, start with 3, raise it to the power of 2 to obtain 9, and then multiply by 4 to get 36.
The underscore indicates the argument position where the output of the previous pipeline element is to be inserted when calling the next pipeline element. The default is to add it as a rightmost argument. The macro has features for dealing with splitting and recombining lists, and handling multiple values.
This is still the same ``pure nested'' syntax; it merely expresses function chaining differently.
What was that about notation limiting language utility?
Yes. The Mathematica language really brings home the fact that non-trivial syntax is good. In particular, it does an excellent job of mimicking conventional mathematical notation. Arguing in favor of Lisp syntax is like advocating the use of cave painting...
Also, note that Mathematica provides strictly more in the way of macros.
Kaz Kylheku wrote: > On May 4, 5:11 pm, Xah Lee <x...@xahlee.org> wrote: >> (1) Some 99% of programers are not used to the nested parenthesis >> syntax. This is a practical problem.
> Since 99% of programmers don't use Lisp, it's not a practical problem.
If you're being pedantic, you may mean "it is an uncommon practical problem". However, the problem extends beyond Lisp.
Recent discussions have covered the use of pattern matching. In SML, OCaml, Haskell (I believe) and F# you must write pattern matches over the expr type in prefix notation. To borrow from Alan's example, the Lisp code:
(destructuring-bind (op1 (op2 n x) y) form `(* ,n (* ,(simplify x) ,(simplify y))))) ((cons (eql *) *) (destructuring-bind (op left right) form (list op (simplify left) (simplify right)))) ((cons (eql +) (cons (eql 0) (cons * null)))
could be written:
| n*x*y -> n*(x*y)
but in ML this must be written as a pattern match over a sum type where the type constructors must use prefix notation:
| Mul(Mul(n, x), y) -> Mul(n, Mul(x, y))
While this is clearly much better than the Lisp, it would be preferable to use the mathematical syntax in this case. You can address this in OCaml using macros and there is a chance that F# will support overloaded operators in patterns in the future.
Mathematica lets you do:
n x y -> n (x y)
but I don't know of any other languages that do, without forcing you to reinvent the wheel via macros.
Xah Lee <x...@xahlee.org> writes: > How Lisp's Nested Notation Limits The Language's Utility
You know, I am all about keeping one's eyes open so as to see the limitations of the tools one chooses or is forced to use. If more people were open to the flaws in their OS, religion, editor, and a myriad of other things the world would surely be a better and more peaceful place. However, I have to say that all I ever see from you, Mr. Lee, is complaints and how you want emacs and lisp to change. For the love of whatever god you choose to pray to, find a frigging tool that makes you happy. If it is emacs that makes you happy, then change the things you don't like and be happy but I fail to see how your whining diatribes serve any useful purpose. If you don't like lisp then by all means use something else.
On May 4, 8:37 pm, Jon Harrop <j...@ffconsultancy.com> wrote: [...]
> Yes. The Mathematica language really brings home the fact that non-trivial > syntax is good. In particular, it does an excellent job of mimicking > conventional mathematical notation.
If I wanted to exhibit the benefits of syntax, Mathematica would be pretty low on my list of languages to do it with. The combination of C- ish abreviations (i++, et c.), tricky rules for implicit multiplication, and a maze of twisty little infix operators make it very confusing. It's not Perl, but I'd still pick Lisp's syntax any day of the week and twice on Sundays.
> If it is emacs that makes you happy, then change the things you don't > like and be happy but I fail to see how your whining diatribes serve > any useful purpose. If you don't like lisp then by all means use > something else.
Xahlee likes to complain. That's the main factor here.
Xah Lee wrote: > How Lisp's Nested Notation Limits The Language's Utility
> Xah Lee, 2007-05-03
> There is a common complain by programers about lisp's notation, of > nested parenthesis, being unnatural or difficult to read. Long time > lisp programers, often counter, that it is a matter of conditioning, > and or blaming the use of “inferior” text editors that are not > designed to display nested notations. In the following, i describe how > lisp notation is actually a problem, in several levels.
> (1) Some 99% of programers are not used to the nested parenthesis > syntax. This is a practical problem. On this aspect along, lisp's > syntax can be considered a problem.
Simply wrong. What would be a problem would be if they tried it and could not quickly get used to it.
> (2) Arguably, the pure nested syntax is not natural for human to read. > Long time lispers may disagree on this point.
No code is natural to read, and yes, I have written a ton of COBOL. Neither are legal or scholarly natural language texts natural to read.
> (3) Most importantly, a pure nested syntax discourages frequent or > advanced use of function sequencing or compositions. This aspect is > the most devastating.
The example you chose was a command line, where conciseness rules and where one is not likely to encounter refactoring or macros. ie, the syntax for a command-line has nothing to do with the syntax for serious programming.
sexpr notation provides a hierarchical lexical grouping that maps isomorphically onto the functional semantics, and the latter is what I need to rearrange when refactoring, so it kinda helps that the code I must edit to achieve said rearrangement maps so directly to the semantics.
I think the biggest argument in favor of parens is all the people that want them to go away. Bad features just die out (see C++ and Java).
> (1) Some 99% of programers are not used to the nested parenthesis > syntax. This is a practical problem. On this aspect along, lisp's > syntax can be considered a problem.
The first time I saw graph-theory notation, I thought it was gibberish. I still think most mathematical notation is gibberish, but I deal with it --- I don't turn in proofs written in prose.
> (2) Arguably, the pure nested syntax is not natural for human to read. > Long time lispers may disagree on this point.
And mathematical notation is not natural for people to read, at least not anybody who grew up learning a natural language. But people deal with it. They're remarkably adaptable this way.
Speaking of gibberish. I can't believe anybody would hold up Mathematica as an example of good programming. Next you'll be telling me that 99% of Matlab code isn't really crap!
> The third issue, about how nested syntax seriously discourages > frequent or advanced use of inline function sequencing on the fly, is > the most important and I'll give further explanation below.
I consider this to be a Good Thing (TM). Unix shell commands read like line noise.
Xah Lee <x...@xahlee.org> writes: > How Lisp's Nested Notation Limits The Language's Utility
> Xah Lee, 2007-05-03
> There is a common complain by programers about lisp's notation, of > nested parenthesis, being unnatural or difficult to read. Long time > lisp programers, often counter, that it is a matter of conditioning, > and or blaming the use of “inferior” text editors that are not > designed to display nested notations. In the following, i describe how > lisp notation is actually a problem, in several levels.
As a practical matter, most LISPers don't even see the parens, but rather interpret the code according to the indentation.
> (1) Some 99% of programers are not used to the nested parenthesis > syntax. This is a practical problem. On this aspect along, lisp's > syntax can be considered a problem.
It's certainly different. Whether it is a problem or not depends on personal or subjective criteria.
> (2) Arguably, the pure nested syntax is not natural for human to read. > Long time lispers may disagree on this point.
Harder to read for some things, easier to read for others.
E.G.
1 + 2 + 3 + 4 + 6 - 3 + 32
or
(- (+ 1 2 3 4 6 32) 3)
> (3) Most importantly, a pure nested syntax discourages frequent or > advanced use of function sequencing or compositions. This aspect is > the most devastating.
This is one reason LISP has macros. Don't like the syntax? Make your own. How many languages make this as easy as LISP does?
> The third issue, about how nested syntax seriously discourages > frequent or advanced use of inline function sequencing on the fly, > is the most important and I'll give further explanation below.
> One practical way to see how this is so, is by considering unix's > shell syntax. You all know, how convenient and powerful is the > unix's pipes. Here are some practical example: “ls -al | grep xyz”, > or “cat a b c | grep xyz | sort | uniq”.
> Now suppose, we get rid of the unix's pipe notation, instead, > replace it with a pure functional notation: e.g. (uniq (sort (grep > xyz (cat a b c)))), or enrich it with a composition function and a > pure function construct (λ), so this example can be written as: > ((compose (lambda (x) (grep xyz x)) sort uniq) (cat a b c)).
(pipe (cat a b c) (grep xyz) (sort) (uniq))
'Nuff said.
UNIX pipe `|' is not just a throw-away syntactic separator, anyone with LISP experience would see it for what it is: a function that operates on functions.
> Lisp, by sticking with almost uniform nested parenthesis notation, > it immediately reduces the pattern of sequencing functions, simply > because the syntax does not readily...<snip>
I would contend that LISP did not do this. You did.
<snip>
> (Note: Lisp's sexp is actually not that pure. It has ad hoc syntax > equivalents such as the “quote” construct “ '(a b c) ”, and also > “`”, “#”, “,@” constructs, precisely for the purpose of reducing > parenthesis and increasing readability. Scheme's coming standard the > R6RS ↗, even proposes the introduction of [] and {} and few other > syntax sugars to break the uniformity of nested parenthesis for > legibility. Mathematica's FullForm, is actually a pure nested > notation as can be.)
Some functions are used so often, they have shorthand equivalents. This is a feature in many languages. But if for some reason one wanted the sexp to be "pure," nothing's stopping him from using the fully-parenthesized versions.
> ------- > The above, is part of a 3-part exposition: > “The Concepts and Confusions of Prefix, Infix, Postfix and Fully > Functional Notations”, > “Prefix, Infix, Postfix notations in Mathematica”, > “How Lisp's Nested Notation Limits The Language's Utility”, > archived at: > http://xahlee.org/UnixResource_dir/writ/notations.html
Xah Lee wrote: > How Lisp's Nested Notation Limits The Language's Utility
I didn't read your thesis, but the general premise is correct.
Caution: late-night ramblings follow. Proceed with caution.
The solution is simple: do something in Lisp that is nearly impossible in other languages.
Do something that is anathema to the programmer machismo.
Write an interactive, point-and-click interface that lets users edit Lisp code as block diagrams, seamlessly transforming back and forth between s-expressions and widgets.
In another project, write macros that convert Basic code into idiomatic Lisp.
Provide the user with "UI/syntax macros" that can present code in any number of forms.
With such frameworks in place, the truth will be exposed: All languages are "preprocessed Lisp"; their only essential difference is the preferred syntax and the libraries provided.
Definition: Turing-complete, n., an expression of Lisp.
(I should really get some sleep now.)
Seriously, though. The lisp environment is overwhelming to the new user. Everything is foreign; they should offer a course in the history department just so people can understand all the thoughts that resulted in what we have today.
I "learned programming" by typing hex codes from magazines into a VIC20; when these didn't work, I finally entered the BASIC checksum program to help identify where things went wrong. This was foreign, but Commodore basic provided a simple interface for the types of interactive programming that Lisp excels at. I learned "for loops" by bouncing *'s across the screen... I can only imagine what it would happen if I were at that age trying the same experiments today... construct a widget, add a text panel, oops can't position text, try a blank panel, figure out which command draws text... 2 years later?
What will future generations learn to program on? The abomination known as Visual Basic? Perl, Python, and other "scripting languages"? Almost certainly not Lisp. Dr.Scheme (or whatever had the simple built-in Windows IDE) was my first introduction to Lisp, and I must say that Commodore and GRA (? AtariST) basic were much easier to grasp -- largely due to the linguistic nature of their commands.
Lisp has a full suite of macros for morphing code; but the main efforts to fix the syntax always seem to result in new compilers being written (Dylan anyone?). Why can't we have syntax macros?
We need something that new coders can grasp easily. If it runs on a thin layer over Lisp, then they will learn to see through the facade -- and hopefully avoid the brain damage encoded in restrictive programming paradigms enforced by inferior language systems. Plus code written in the "simple" syntax will be translated by these syntax macros into idiomatic Lisp code, thus providing an interactive lesson in Lisp.
Treat Lisp as the bytecode of a universal "virtual machine".
I've cobbled together a simple framework inspired by Terence Parr's Antlr and StringTemplate libraries. These (Mr. Parr's libraries) are excellent libraries that implement a fairly , ignoring their linguistic implementation. Something like this in Lisp should be just the key to providing a standardized syntax macro framework...
> Yes. The Mathematica language really brings home the fact that non-trivial > syntax is good. In particular, it does an excellent job of mimicking > conventional mathematical notation. Arguing in favor of Lisp syntax is like > advocating the use of cave painting...
> Also, note that Mathematica provides strictly more in the way of macros.
Sorry for double posting but I'm getting sick of Xah Lee and Jon Harrop. We all get their message :COMMON LISP SUCKS so please let us leave in our misery while you make all the great programms in F#, Mathematica or whatever ...
«(1) Some 99% of programers are not used to the nested parenthesis syntax. This is a practical problem. On this aspect along, lisp's syntax can be considered a problem.»
Ken Tilton wrote:
«Simply wrong. What would be a problem would be if they tried it and could not quickly get used to it.»
I think what you said is part of what i said. But let me elaborate.
Lisp's nested parenthesis certainly is a problem, if you want to attract programers to lisp and programers are not attracted by sexp in the first place.
What you expressed, is to consider the question of whether people can get used to sexp. If programers cannot adapt sexp and find it comfortable as a syntax of a programing language, then, you consider THAT, to be a problem of the lisp syntax. Otherwise no problemo.
I think you vantage point is not so goody. But if we consider the question itself, i think yes, people can adapt and use sexp reasonable well for programing. Actually, this has been already done i guess by lispers for 40+ years right? But if we really focus on this point of view, namely: whether sexp can be suitable as a syntax for computing language. Then, that is rather not a interesting question i thinky. Because, in general, people can adapt to all kind of wierd shits, really depending how pressing the matter is. If it is life threatening, or they have no other choice, human animals can adapt. Imagine, compare, the technology today are far advanced than 40 years ago. Computers are what? a thousand, ten thousand times faster? And there's no Perl, Python, Java, Internet 40 years ago. But People went to the Moon! Imagine, what kind of torturous pain these people have to go thru in software and hardware or the computation of mathematics to do this. BASIC with GOTO and FORTRAN? What? no structured constructs? No code blocks? No libraries? No symbols? No macros? Not even Eval()? No USB and DVDs but punchcards?
You know about Chinese characters right? To a European, Chinese characters looks torturous. But in fact it is. Just consider the number of strokes. But i think Chinese people of 13 billion are surviving.
Sure. I certainly agree human animals can get used to sexp. Under some conditions, human animals can get used to a lot of things, and loving it too.
The interesting question would be, to what degree of botchedness of computer language syntax can be, until programers will not be able to adapt it and code it fruitfully? Suppose, for each paren in lisp, we double it. So, “(+ 3 4)” will be written as “((+ 3 4))”. And suppose we force this to be the new syntax for lisp. I will bet you one hundred bucks, that all lispers will find in exactly as easy to read as before.
How many level of parens do you think we can add till all lispers abandon ship?
How many?
----------------------------
Xah Lee wrote:
«(2) Arguably, the pure nested syntax is not natural for human to read. Long time lispers may disagree on this point.»
Kenny wrote:
«No code is natural to read, and yes, I have written a ton of COBOL. Neither are legal or scholarly natural language texts natural to read.»
Huh? surely you agree that there is at least some qualification as to some written language being more natural or easier to read?
For example, compare language A and B, where A is just lisp's sexp, and B is sexp with every paren replaced by double parens. Now, which is more “natural” or easy to read?
So, likewise, compare Perl and Python. Which is easier to read in general? You can't wax philosophy on this can you?
Imagine a philosophical scenario, where a devil killed off all pythoners on earth. Therefore perl code is easier to read, because nobody would understand a fuck when shown a python code. So, the question of whether Perl or Python code is easier to read, depends.
Also, i mean, it depends on the programer!! Because, if i write Perl code versus a moron writing in Python, then my Perl code will sure be easier to read. So, it also depends on me.
What a great tough undecidability!
---------------------------- Xah Wrote: «(3) Most importantly, a pure nested syntax discourages frequent or advanced use of function sequencing or compositions. This aspect is the most devastating.»
Kenny wrote:
«The example you chose was a command line, where conciseness rules and where one is not likely to encounter refactoring or macros. ie, the syntax for a command-line has nothing to do with the syntax for serious programming.»
Yes the example i gave was unix's shell. It is chosen because it is simple to illustrate and widely known.
I could give Mathematica examples with explanations... but its not suitable as the simple unix pipe example because then i'll have to spend great space explaining Mathematica.
Basically, you'll see on the right side are 3 sequence of functions. The left side is a function applied to a function. i.e. Reflect2DGraphics takes 2 vectors and “returns” a function that takes one graphics argument. (it doesn't actually return a function since it's written as pattern matching... but you can think of it as a function generator)
Here's the lispy form some lisper believe is easier to read:
The following are more code. They involve pure functions, function application, function mapping, function generator applied to functions... and basically all done with flat sequencing of functions when possible. (aka function chaining sans nesting). Whenever you see the ampersand sign &, its a pure function (aka lambda). Some pure function has pure function as its innards.
These are written in 1997, by yours truely. I would say, if you have not been coding lisp or Mathematica for, say, 40 hours a week for 4 years, you wouldn't understand these code when explained. (not considering the math it is doing)
Okie, here's a good one. Lots of sequencing of pure functions on the fly:
> "Robert D. Crawford" <rd...@comcast.net> writes: >> If it is emacs that makes you happy, then change the things you don't >> like and be happy but I fail to see how your whining diatribes serve >> any useful purpose. If you don't like lisp then by all means use >> something else.
> Xahlee likes to complain. That's the main factor here.
There is thought and intelligence in his posts. However they are provocative in both the good and the bad sense of the term, and rather eccentric.
>> How Lisp's Nested Notation Limits The Language's Utility >> (2) Arguably, the pure nested syntax is not natural for human to read. >> Long time lispers may disagree on this point.
>Programming language syntax shouldn't be natural for humans to read. >Or, rather, this shouldn't be a requirement which creates technical >compromises.
I couldn't disagree more. Occasionally you do need to use a language with no technical compromises whatsoever - pure assembly or machine code - but only rarely. Most of the time we accept some limitations for the sake of making things easier for the human programmer. That includes run-time efficiency, but also restrictions in the "power" of the language.
You might be interested in the page 10 Rules of Computer Programming on my website which deals with psychological issues in programming. Lisp breaks the rule of three in spades. -- Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
> > Yes. The Mathematica language really brings home the fact that non-trivial > > syntax is good. In particular, it does an excellent job of mimicking > > conventional mathematical notation. Arguing in favor of Lisp syntax is like > > advocating the use of cave painting...
> > Also, note that Mathematica provides strictly more in the way of macros.
> Sorry for double posting but I'm getting sick of Xah Lee and Jon > Harrop. > We all get their message :COMMON LISP SUCKS so please let us leave in > our misery > while you make all the great programms in F#, Mathematica or > whatever ... > >From now on I'll ignore both of them for good .
> cheers > bobi
I fully agree. Neither of them as any (!) clue about Lisp and programming in Lisp. Neither of them has written any significant or even non-significant Lisp program. Their postings are full of (wrong) assumptions and are mostly based on no experience and no knowledge of Lisp programming. Both are only trolling in comp.lang.lisp. Best to post a warning sign and other to ignore them...
Xah Lee wrote: > How Lisp's Nested Notation Limits The Language's Utility
> Xah Lee, 2007-05-03
> There is a common complain by programers about lisp's notation, of > nested parenthesis, being unnatural or difficult to read. Long time > lisp programers, often counter, that it is a matter of conditioning, > and or blaming the use of “inferior” text editors that are not > designed to display nested notations. In the following, i describe how > lisp notation is actually a problem, in several levels.
> (1) Some 99% of programers are not used to the nested parenthesis > syntax. This is a practical problem. On this aspect along, lisp's > syntax can be considered a problem.
Lisp doesn't have a problem here. Lisp is a programming language, an inanimate, dispassionate, virtual concept which doesn't (cannot!) "care" whether it is used at all.
Only people can have problems with something. For example, programmers who want some of the cool features of Lisp but don't want to put up with its syntax.
However, for decades, there have been programmers who have learned to prefer Lisp's syntax over anything else. As long as they continue to exist, Lisp dialects will continue to exist. Those people don't have a problem - to the contrary.
Leave them alone - they are happy with their choice.
If you don't like Lisp, there are numerous attempts to copy its features using other surface syntaxes. Just pick one.
"Malcolm McLean" <regniz...@btinternet.com> writes: > "Miles Bader" <mi...@gnu.org> wrote in message > news:873b2cxbxt.fsf@catnip.gol.com... >> "Robert D. Crawford" <rd...@comcast.net> writes: >>> If it is emacs that makes you happy, then change the things you don't >>> like and be happy but I fail to see how your whining diatribes serve >>> any useful purpose. If you don't like lisp then by all means use >>> something else.
>> Xahlee likes to complain. That's the main factor here.
> There is thought and intelligence in his posts. However they are > provocative in both the good and the bad sense of the term, and rather
Where is the good sense in there? We have (at c.l.f) people complaining about parenthesis in lisp every 3 months and the arguments never get any better or new. Rehashing all that once again doesn't attest to "thought and intelligence" but rather to a trollish streak.
Rayiner Hashem <rayi...@gmail.com> writes: >> (1) Some 99% of programers are not used to the nested parenthesis >> syntax. This is a practical problem. On this aspect along, lisp's >> syntax can be considered a problem.
> The first time I saw graph-theory notation, I thought it was > gibberish. I still think most mathematical notation is gibberish, but > I deal with it --- I don't turn in proofs written in prose.
Right.
>> (2) Arguably, the pure nested syntax is not natural for human to read.
And BTW, it's not natural for humans to read at all.
:-)
>> Long time lispers may disagree on this point.
> And mathematical notation is not natural for people to read, at least > not anybody who grew up learning a natural language. But people deal > with it. They're remarkably adaptable this way.
<development-2006-8ecbb5cc8aREMOVET...@ANDTHATm-e-leypold.de> writes: > Where is the good sense in there? We have (at c.l.f) people > complaining about parenthesis in lisp every 3 months and the arguments > never get any better or new. Rehashing all that once again doesn't > attest to "thought and intelligence" but rather to a trollish streak.
Indeed, and people have been saying what Xahlee's saying since the _1950s_! Lisp still has the parens, and there are good reasons for that.
-Miles -- [|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that will make every christian in the world foamm at the mouth? [iddt] nurg, that's the goal
"Malcolm McLean" <regniz...@btinternet.com> writes: > You might be interested in the page 10 Rules of Computer Programming on > my website which deals with psychological issues in programming. Lisp > breaks the rule of three in spades.
That suggests that the "rule of three" is wrong...
-Miles -- o The existentialist, not having a pillow, goes everywhere with the book by Sullivan, _I am going to spit on your graves_.
"Malcolm McLean" <regniz...@btinternet.com> writes: > You might be interested in the page 10 Rules of Computer Programming > on my website which deals with psychological issues in > programming. Lisp breaks the rule of three in spades.
Rule three is about indirection, not about nesting. The other rules suck also. If your "Refutation of Common Atheist Arguments" have a similar quality, the atheists will have a field day.
Xah Lee wrote: > Xah Lee wrote: > «(1) Some 99% of programers are not used to the nested parenthesis > syntax. This is a practical problem. On this aspect along, lisp's > syntax can be considered a problem.»
> Ken Tilton wrote: > «Simply wrong. What would be a problem would be if they tried it and > could not quickly get used to it.»
> I think what you said is part of what i said. But let me elaborate.
> Lisp's nested parenthesis certainly is a problem, if you want to > attract programers to lisp and programers are not attracted by sexp in > the first place.
Ah, but now you are talking about marketing, and I happen to believe that one does not win at marketing by throwing out one of the best features of the language.
Do things well and people will find you. Why else has Lisp recovered from the AI Winter? When has a computer language ever made a comeback?
Below you suggest I may be blinded by perspective. My question to you is, do /you/ appreciate the importance of parens? If not, your perspective is the problem.
> What you expressed, is to consider the question of whether people can > get used to sexp. ...snip... Then, that is rather not a interesting question i thinky. > Because, in general, people can adapt to all kind of wierd shits,
I understand how you went wrong, but you have read something into what I wrote and are now off on a tangent by yourself, complete with bibliography <g>. Nowhere did I say people would have to struggle to appreciate parens, what I said was that it is not interesting if people who have never tried Lisp complain about the parens. The only interesting repsondent is one who has tried Lisp for some reason, and no such person has ever had a problem with the parens. You are reacting to word of mouth from people who have never tried Lisp, and that means nothing. Give someone a microphone, they will say something.
But this is all Usenet hair-splitting. The bottom line is this: all Lispers learned parens at some point, and know from experience that it was easy for them, that it would be easy for anyone, and that parens are an absolute advantage. If you disagree on any of those points we likely will not find common ground.
[a bunch more on the mistaken idea that parens are an acquired taste]
> The interesting question would be, to what degree of botchedness of > computer language syntax can be, until programers will not be able to > adapt it and code it fruitfully? Suppose, for each paren in lisp, we > double it. So, “(+ 3 4)” will be written as “((+ 3 4))”. And suppose > we force this to be the new syntax for lisp. I will bet you one > hundred bucks, that all lispers will find in exactly as easy to read > as before.
You seem deeply convinced that parens /are/ a problem? Perhaps the story here is that they /do/ confuse you. Anyway, the above is thoroughly wrong. Lispers hate line noise, which is why they love parens and why they use macros such as my BIF, which changes:
(let ((x (look-up y))) (when x (print (list x 42))))
to: (bwhen (x (look-up y)) (print (list x 42)))
Come to think of it, one reason I like loop is that it lets me express iteration without so many parens. I guess I am making a tradeoff in which I accept locally a burden to think about syntax in return for being able to dash off commonly written code (which commonness means the syntax will be second-nature). And a big point you have missed: I still get decent auto indentation of my code even with the whacky loop syntax.
Note, btw, that your second set of parens adds nothing. The first brilliantly captures lexically that the operator along with its operands forms a meaningful semantic chunk....hang on.... eureka! So do the arguments, so (+ 2 3) should really be (+ (2 3)). Ah, but then (+ 40 (- 4 2)) becomes (+ (40 (- (4 2)))... well, I guess Lispers /do/ worry about readability. :)
Meanwhile, you owe me $100. Paul Graham, at ILC '2003 (? In NYC), said one problem he wanted to fix with Arc was that Lisp had too many parnetheses. He picked on COND as an example.
> How many level of parens do you think we can add till all lispers > abandon ship?
> How many?
> ---------------------------- > Xah Lee wrote: > «(2) Arguably, the pure nested syntax is not natural for human to > read. Long time lispers may disagree on this point.»
> Kenny wrote: > «No code is natural to read, and yes, I have written a ton of COBOL. > Neither are legal or scholarly natural language texts natural to > read.»
> Huh? surely you agree that there is at least some qualification as to > some written language being more natural or easier to read?
> For example, compare language A and B, where A is just lisp's sexp, > and B is sexp with every paren replaced by double parens. Now, which > is more “natural” or easy to read?
> So, likewise, compare Perl and Python. Which is easier to read in > general? You can't wax philosophy on this can you?
> Imagine a philosophical scenario, where a devil killed off all > pythoners on earth. Therefore perl code is easier to read, because > nobody would understand a fuck when shown a python code. So, the > question of whether Perl or Python code is easier to read, depends.
> Also, i mean, it depends on the programer!! Because, if i write Perl > code versus a moron writing in Python, then my Perl code will sure be > easier to read. So, it also depends on me.
> What a great tough undecidability!
But only because you think the only thing that makes a computer language readable is experience with it. And you are stuck on the idea of readability being important, another big mistake. We /write/ code, we do not read it. The important thing is to make the writing easy. The parens make writing code code (guessing) twice as easy, certainly refactoring.
Another mistake: code ever being as readable as Stephen King. Nope, with code one /always/ has to slow down to figure out what is going on.
I think you are also missing that the parens also mean there is a ton of syntax and precedence I do not need to learn or make mistakes on. One simple rule and I am good to go.
You need to remember, Xah, that any Lisper is master also of other computer languages, because we likely pay the bills with something else. You seem to have a mental model of us in which the only thing we know is Lisp.
> ---------------------------- > Xah Wrote: > «(3) Most importantly, a pure nested syntax discourages frequent or > advanced use of function sequencing or compositions. This aspect is > the most devastating.»
> Kenny wrote:
> «The example you chose was a command line, where conciseness rules and > where one is not likely to encounter refactoring or macros. ie, the > syntax for a command-line has nothing to do with the syntax for > serious programming.»
> Yes the example i gave was unix's shell. It is chosen because it is > simple to illustrate and widely known.
Well, the problem with examples is the problem with analogies: even if we agree with the proffered case, what does that add to the discussion? How well does it apply? What does it say? It just opens up a whole new thread. The second set of parens is different from the first, a command-line is not a 3gl with pages of text (and to head you off, if I was writing a ten-line shell script, yes, I would want sexprs).
> I could give Mathematica examples with explanations... but its not > suitable as the simple unix pipe example because then i'll have to > spend great space explaining Mathematica.
> Basically, you'll see on the right side are 3 sequence of functions. > The left side is a function applied to a function. i.e. > Reflect2DGraphics takes 2 vectors and “returns” a function that takes > one graphics argument. (it doesn't actually return a function since > it's written as pattern matching... but you can think of it as a > function generator)
> Here's the lispy form some lisper believe is easier to read:
> The following are more code. They involve pure functions, function > application, function mapping, function generator applied to > functions... and basically all done with flat sequencing of functions > when possible. (aka function chaining sans nesting). Whenever you see > the ampersand sign &, its a pure function (aka lambda). Some pure > function has pure function as its innards.
> These are written in 1997, by yours truely. I would say, if you have > not been coding lisp or Mathematica for, say, 40 hours a week for 4 > years, you wouldn't understand these code when explained. (not > considering the math it is doing)
> Okie, here's a good one. Lots of sequencing of pure functions on the > fly:
