7 ms·

Lisp has too many parentheses...

66 points by zephyrfalcon 16y ago

Jach 16y ago
I've posted this here before, I'll post it again: http://img264.imageshack.us/img264/1397/lispnd7.png http://img264.imageshack.us/img264/1397/lispnd7.png In practice, I don't find it has many more parens or angle-brackets than, say, C++ or Java. Considering (), {}, and <> in those two languages, I'd bet Lisp wins.
- arethuza 16y ago
  I spent maybe five years being paid to write Lisp code in the early '90s and I can remember what a lot of the code looked like and, just your like that image, I really don't recall the parens that distinctly.
- thesz 16y ago
  Languages with juxtaposed argument application (Haskell, OCaml) and meaningful indentation (Python, Haskell) will win over Lisp. Mixfix-based languages like Agda2 or Maude will win even more. BTW, while Halstead metric predict various things about imperative languages like Algol/PL/1/C/C++/Java quite well, it fails when applied to Haskell: http://www.cs.stir.ac.uk/~kjt/techreps/pdf/TR141.pdf http://www.cs.stir.ac.uk/~kjt/techreps/pdf/TR141.pdf And fail spectacularly - they have to introduce special "invisible apply" operator to make Haskell to be closer to imperative languages, just to do not look like they are cheating. This is attributed to juxtaposition as application (as it reduces number of lexems) and to definition of functions by pattern matching. I think other languages with those two features would have same effect over predictive force of Halstead metric.
eru 16y ago
Nice article. Though a bit smug; Forth (or even Scheme) have a much cleaner syntax than the Lisp advertised here.
mahmud 16y ago
Gaaah, knock off the CAPSLOCK and the machismo, please. Also, you don't need to invent backcronyms for CAR/CDR, they're now called first/rest. Having said that, I really like the presentation of your blog, nice typography. And after skimming your book[1] in progress, and noting your obvious theoretical bent and taste for rigor, I can only anticipate to read more of your future posts (latch on to something "obscure" like ACL2 and make something fun with it.) [1] http://symbo1ics.com/blog/?page_id=77 http://symbo1ics.com/blog/?page_id=77 [Edit: The book has code samples in 4 different languages; LISP (the ancient cap-cased "one"), ML, C, and what looks like Pascal. If you want to learn about the axiomatic specification of computer programs, specially for "structured" programming, then look into the works of Gries and others, specially in the silver "Texts and Monographs In Computer Science" books (the entire series is a feast of delight that should be devoured, and washed down with heirloom, stolen wine): The Science of Programming, Gries. The Design of Well-Structured and Correct Programs, Alagic and Arbib. The selection Programming Methodology edited by Gries has various approaches to the structured method, with contributions from Dijkstra, Hoare, Wirth, Reynolds and other rock-stars of axiomatic semantics and verification.]
- ihodes 16y ago
  Exactly what I was thinking, though I do still enjoy seeing CAR and CDR. But I'm the kind of guy who likes steampunk, and it's in the same vein. I, too, am looking forward to more posts; it's worth checking out the posts that are up already. Definitely my kind of thing (see my http://copperthoughts.com/p/set-theory-and-lisp/ http://copperthoughts.com/p/set-theory-and-lisp/). This is where I'll refer people who know nothing about Lisp when they complain about it; not too self-righteous, pleasantly informative, and theoretically interesting.
- angrycoder 16y ago
  The bigger problem is that CAR and CDR actually mean something without the silly anatomy analogies.
  - deleted 16y ago
    [deleted]
  - 16y ago
koenigdavidmj 16y ago
Anyone manage to build a Lisp that used semantic indentation (like Python)? You could make it optional and just have it function as a preprocessor that generates the real thing.
- eru 16y ago
  Perhaps Haskell can be an inspiration?
  - mahmud 16y ago
    A cheap hack many have used is to customize their emacs high-lighting so the parens are shown only a shade away from the background color.
- leif 16y ago
  There's an emacs mode for that. (http://www.emacswiki.org/emacs/UnParenMode http://www.emacswiki.org/emacs/UnParenMode) It hides the parentheses, and emacs by default will indent your lisp correctly. Just like the real thing (except you can't edit while in UnParenMode...minor issue). I do enjoy the irony in commenting with "can we get rid of the paretheses" on a post explaining why the parentheses are not important. When you truly understand lisp, you will no longer see the parentheses. They aren't real.
- burgerbrain 16y ago
  Are you kidding? Mandating whitespace is possibly the single worse feature of python. Lisp editing is an extremely mature topic, and rarely does a lisp programmer have to actually deal with code formatting. To turn that on it's head would be madness. A complete step backward.
  - Locke1689 16y ago
    You both have stupid arguments which basically boil down to "I don't like it because I prefer it the other way." This stupid flamewar has been fought countless times on countless online forums, let's not do this.
philwelch 16y ago
"Dorsal" means "top", like where the dorsal fin on a fish is. It doesn't even remotely mean "everything except the front". (The belly of a fish is "ventral".)
- jamesbritt 16y ago
  "Dorsal" means "top", like where the dorsal fin on a fish is. http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=dorsal http://www.google.com/search?sourceid=chrome&ie=UTF-8&#3... e.g. "of, pertaining to, or situated at the back, or dorsum." Seems fish are the oddball, in a way. Their top is basically their back.
- gaelian 16y ago
  dictionary.com seems to think you're kind of both right[1]. [1] http://dictionary.reference.com/browse/dorsal http://dictionary.reference.com/browse/dorsal
- alextgordon 16y ago
  There's an incongruity between animal and human anatomy. In humans, dorsal does indeed mean back, not top. Wikipedia has a wall of text by way of explanation: http://en.wikipedia.org/wiki/Anatomical_terms_of_location#Why_zootomy_and_androtomy_terms_differ http://en.wikipedia.org/wiki/Anatomical_terms_of_location#Wh...
  - philwelch 16y ago
    Except, as far as humans are concerned, "dorsal" and "posterior" are synonymous.
brendano 16y ago
This argument/response comes up every time.... Argument: "Lisp has too many parentheses. It's unreadable." Response: "It's conceptually elegant that everything is parentheses." This doesn't address the real point -- you can't read it well. You do get advantages for macros and symbolic processing. But the cost in readability is still there.
- fogus 16y ago
  This doesn't address the real point -- you can't read it well. By "you", don't you mean you?
- swannodette 16y ago
  I've yet to find Lisp any more or less readable then anything else I write day-to-day (Python, Ruby, JavaScript, CSS, HTML). In all these languages I find myself constantly fighting to find a readable and reasonable formatting. I certainly won't argue that I find myself doing this less in Lisp, but the readability argument is just something that continues to be bandied about by people who haven't spent much time programming in Lisp. Here's a DSL I'm working on for CouchDB: (defmapping post :pre-commit timestamp :fields {:author-id :string :title :string :created :date-time :modified :date-time :body :string :tags [:string] :meta {:copyright :string :href :string}}) I wish my work in other languages had this kind of structural clarity all the time! In constrast my favorite Python lib for CouchDB work looks like this: creators = ListField(DictField(Mapping.build( name = DictField(Mapping.build( name_authority = TextField(), name_authority_id = IntegerField(), display_string = TextField() )), user_id = IntegerField(), roles = ListField(TextField()), attrs = ListField(TextField()), xts = ListField(TextField()), ))) Just look at all those parens!
  - DannoHung 16y ago
Yeroc 16y ago
And machine code printed in binary is all 1's & 0's. What could be more elegant than that?
- burgerbrain 16y ago
  Lisp.
agentultra 16y ago
Fantastic article, though the analogy to the Eiffel tower is a bit weak. It's a good exposition into the argument as to why "code is data," is a relevant and valuable argument. Lisp is a wonderful language and I love those damn parenthesis. :)
sz 16y ago
Man all the hype about Lisp just suddenly made sense to me. Why do we need all this other stuff? Loved the simple exposition and backronyms, contrary to some other opinions here.
- tlack 16y ago
  We definitely don't need all the fluff, and I like the philosophical cleanliness of Lisp (from a distance), but to me it seems like too basic of a building block to think with. Haskell's point free style and K's vector building blocks seem more useful to me for use in philosophical reasoning about algorithms.
kraynar 16y ago
I always liked the way Larry Wall put it: "Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in." http://groups.google.com/group/comp.lang.lisp/msg/7700fb02a2750032 http://groups.google.com/group/comp.lang.lisp/msg/7700fb02a2...
- lispm 16y ago
  then he went on and desi^h^h^h^h ... crea^h^h^h^h ... hacked Perl...
crux_ 16y ago
Money quote for the non-lisper: > For simplicity, let’s use the notation Yes, let's! Except in lisp, you can't. ;) (Yes, feeling snarky.)
- jpr 16y ago
  Except you can, just use reader macros.
  - prodigal_erik 16y ago
    Lisp is a remarkable toolkit for creating domain-specific languages with any syntax you happen to need. It amazes me how many people try to use it as an ordinary programming language without modifying it at all, and then give up because they found nothing special about it. I think they're missing the point.
  - vorg 16y ago
    With these reader macros, can the code in the blog example be rewritten as below, so it still directly maps to the Lisp tree-like semantics, but be more readable? defun diff(expr, x){ if(expr == x) 1 else if(car(expr) == 'plus') ['plus', diff(cadr(expr), x), caddr(expr), x] else if(car(expr) == 'times')[ 'plus', ['times', cadr(expr), diff(caddr(expr), x)], ['times', diff(cadr(expr), x), caddr(expr)] ]else 0 }
    - jpr 16y ago
      I have to admit that I'm not an expert on reader macros, so I can't say for sure. Your example seems to map some already used characters, so it wouldn't be a pure extension of the reader. I guess you could make a readtable that recognizes that syntax and transforms it to the tree-like semantics. FWIW, I don't find it more readable than the standard notation. Maybe I have become too accustomed to the standard CL-notation.
    - crux_ 16y ago
      I'm sure it's possible; lisp is very flexible. But would your example code still be considered lisp?
ohyes 16y ago
Does anyone else have trouble with making the distinction between curly braces and parenthesis? I'm pretty near sighted, so I always have to squint to figure out if something is a brace or a paren. I think it is one of the main reasons I like lisp... There are no braces, and all I have to do is make sure that emacs indents everything properly (ctrl+alt+q at top of form... in my head I call it 'regrinding') so I know that the forms I've written have the closing parens in the proper places. I know people complain about the parens, but I spend literally no time fudging with the formatting of my lisp code.. emacs just does it. Java and C code, however I always end up fiddling with (even with an 'advanced' IDE like eclipse).
jpr 16y ago
"too many parenthesis" is simply a flag that someone is speaking only about his initial emotional response, not out of actual use experience or measurement. When you actually count parenthesis in equivalent programs in C (or C-like syntax) and Lisp, they are almost exactly the same. When you include the ;.->*& -stuff, C starts to lose because `foo.bar();´ in C becomes simply `(bar foo)´ in Lisp.
deleted 16y ago
[deleted]
partition 16y ago
Those who keep going on and on about parentheses in Lisp should try Haskell, which is basically* Lisp, except everything has one argument and is left associative. This simple rule removes a TON of parens. Add in the $, . operators and a bunch of other potential parentheses are eliminated. *Except also that Haskell is typed and does not include code quoting/eval. But that's what Template Haskell is for :)
- petdog 16y ago
  Except that I find myself adding tons of parens to my haskell to be able to read it. Lisp may have spoiled me.
qu1j0t3 16y ago
@mahmud I don't have to invent backronyms for urmom.

66 points by zephyrfalcon 16y ago

Jach 16y ago

I've posted this here before, I'll post it again: http://img264.imageshack.us/img264/1397/lispnd7.png http://img264.imageshack.us/img264/1397/lispnd7.png In practice, I don't find it has many more parens or angle-brackets than, say, C++ or Java. Considering (), {}, and <> in those two languages, I'd bet Lisp wins.

arethuza 16y ago
I spent maybe five years being paid to write Lisp code in the early '90s and I can remember what a lot of the code looked like and, just your like that image, I really don't recall the parens that distinctly.
thesz 16y ago
Languages with juxtaposed argument application (Haskell, OCaml) and meaningful indentation (Python, Haskell) will win over Lisp. Mixfix-based languages like Agda2 or Maude will win even more. BTW, while Halstead metric predict various things about imperative languages like Algol/PL/1/C/C++/Java quite well, it fails when applied to Haskell: http://www.cs.stir.ac.uk/~kjt/techreps/pdf/TR141.pdf http://www.cs.stir.ac.uk/~kjt/techreps/pdf/TR141.pdf And fail spectacularly - they have to introduce special "invisible apply" operator to make Haskell to be closer to imperative languages, just to do not look like they are cheating. This is attributed to juxtaposition as application (as it reduces number of lexems) and to definition of functions by pattern matching. I think other languages with those two features would have same effect over predictive force of Halstead metric.

eru 16y ago

Nice article. Though a bit smug; Forth (or even Scheme) have a much cleaner syntax than the Lisp advertised here.

mahmud 16y ago

Gaaah, knock off the CAPSLOCK and the machismo, please. Also, you don't need to invent backcronyms for CAR/CDR, they're now called first/rest. Having said that, I really like the presentation of your blog, nice typography. And after skimming your book[1] in progress, and noting your obvious theoretical bent and taste for rigor, I can only anticipate to read more of your future posts (latch on to something "obscure" like ACL2 and make something fun with it.) [1] http://symbo1ics.com/blog/?page_id=77 http://symbo1ics.com/blog/?page_id=77 [Edit: The book has code samples in 4 different languages; LISP (the ancient cap-cased "one"), ML, C, and what looks like Pascal. If you want to learn about the axiomatic specification of computer programs, specially for "structured" programming, then look into the works of Gries and others, specially in the silver "Texts and Monographs In Computer Science" books (the entire series is a feast of delight that should be devoured, and washed down with heirloom, stolen wine): The Science of Programming, Gries. The Design of Well-Structured and Correct Programs, Alagic and Arbib. The selection Programming Methodology edited by Gries has various approaches to the structured method, with contributions from Dijkstra, Hoare, Wirth, Reynolds and other rock-stars of axiomatic semantics and verification.]

ihodes 16y ago
Exactly what I was thinking, though I do still enjoy seeing CAR and CDR. But I'm the kind of guy who likes steampunk, and it's in the same vein. I, too, am looking forward to more posts; it's worth checking out the posts that are up already. Definitely my kind of thing (see my http://copperthoughts.com/p/set-theory-and-lisp/ http://copperthoughts.com/p/set-theory-and-lisp/). This is where I'll refer people who know nothing about Lisp when they complain about it; not too self-righteous, pleasantly informative, and theoretically interesting.
angrycoder 16y ago
The bigger problem is that CAR and CDR actually mean something without the silly anatomy analogies.
- deleted 16y ago
  [deleted]
- 16y ago

koenigdavidmj 16y ago

Anyone manage to build a Lisp that used semantic indentation (like Python)? You could make it optional and just have it function as a preprocessor that generates the real thing.

eru 16y ago
Perhaps Haskell can be an inspiration?
- mahmud 16y ago
  A cheap hack many have used is to customize their emacs high-lighting so the parens are shown only a shade away from the background color.
leif 16y ago
There's an emacs mode for that. (http://www.emacswiki.org/emacs/UnParenMode http://www.emacswiki.org/emacs/UnParenMode) It hides the parentheses, and emacs by default will indent your lisp correctly. Just like the real thing (except you can't edit while in UnParenMode...minor issue). I do enjoy the irony in commenting with "can we get rid of the paretheses" on a post explaining why the parentheses are not important. When you truly understand lisp, you will no longer see the parentheses. They aren't real.
burgerbrain 16y ago
Are you kidding? Mandating whitespace is possibly the single worse feature of python. Lisp editing is an extremely mature topic, and rarely does a lisp programmer have to actually deal with code formatting. To turn that on it's head would be madness. A complete step backward.
- Locke1689 16y ago
  You both have stupid arguments which basically boil down to "I don't like it because I prefer it the other way." This stupid flamewar has been fought countless times on countless online forums, let's not do this.

philwelch 16y ago

"Dorsal" means "top", like where the dorsal fin on a fish is. It doesn't even remotely mean "everything except the front". (The belly of a fish is "ventral".)

jamesbritt 16y ago
"Dorsal" means "top", like where the dorsal fin on a fish is. http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=dorsal http://www.google.com/search?sourceid=chrome&ie=UTF-8&#3... e.g. "of, pertaining to, or situated at the back, or dorsum." Seems fish are the oddball, in a way. Their top is basically their back.
gaelian 16y ago
dictionary.com seems to think you're kind of both right[1]. [1] http://dictionary.reference.com/browse/dorsal http://dictionary.reference.com/browse/dorsal
alextgordon 16y ago
There's an incongruity between animal and human anatomy. In humans, dorsal does indeed mean back, not top. Wikipedia has a wall of text by way of explanation: http://en.wikipedia.org/wiki/Anatomical_terms_of_location#Why_zootomy_and_androtomy_terms_differ http://en.wikipedia.org/wiki/Anatomical_terms_of_location#Wh...
- philwelch 16y ago
  Except, as far as humans are concerned, "dorsal" and "posterior" are synonymous.

brendano 16y ago

This argument/response comes up every time.... Argument: "Lisp has too many parentheses. It's unreadable." Response: "It's conceptually elegant that everything is parentheses." This doesn't address the real point -- you can't read it well. You do get advantages for macros and symbolic processing. But the cost in readability is still there.

fogus 16y ago
This doesn't address the real point -- you can't read it well. By "you", don't you mean you?
swannodette 16y ago
I've yet to find Lisp any more or less readable then anything else I write day-to-day (Python, Ruby, JavaScript, CSS, HTML). In all these languages I find myself constantly fighting to find a readable and reasonable formatting. I certainly won't argue that I find myself doing this less in Lisp, but the readability argument is just something that continues to be bandied about by people who haven't spent much time programming in Lisp. Here's a DSL I'm working on for CouchDB: (defmapping post :pre-commit timestamp :fields {:author-id :string :title :string :created :date-time :modified :date-time :body :string :tags [:string] :meta {:copyright :string :href :string}}) I wish my work in other languages had this kind of structural clarity all the time! In constrast my favorite Python lib for CouchDB work looks like this: creators = ListField(DictField(Mapping.build( name = DictField(Mapping.build( name_authority = TextField(), name_authority_id = IntegerField(), display_string = TextField() )), user_id = IntegerField(), roles = ListField(TextField()), attrs = ListField(TextField()), xts = ListField(TextField()), ))) Just look at all those parens!
- DannoHung 16y ago

Yeroc 16y ago

And machine code printed in binary is all 1's & 0's. What could be more elegant than that?

burgerbrain 16y ago
Lisp.

agentultra 16y ago

Fantastic article, though the analogy to the Eiffel tower is a bit weak. It's a good exposition into the argument as to why "code is data," is a relevant and valuable argument. Lisp is a wonderful language and I love those damn parenthesis. :)

sz 16y ago

Man all the hype about Lisp just suddenly made sense to me. Why do we need all this other stuff? Loved the simple exposition and backronyms, contrary to some other opinions here.

tlack 16y ago
We definitely don't need all the fluff, and I like the philosophical cleanliness of Lisp (from a distance), but to me it seems like too basic of a building block to think with. Haskell's point free style and K's vector building blocks seem more useful to me for use in philosophical reasoning about algorithms.

kraynar 16y ago

I always liked the way Larry Wall put it: "Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in." http://groups.google.com/group/comp.lang.lisp/msg/7700fb02a2750032 http://groups.google.com/group/comp.lang.lisp/msg/7700fb02a2...

lispm 16y ago
then he went on and desi^h^h^h^h ... crea^h^h^h^h ... hacked Perl...

crux_ 16y ago

Money quote for the non-lisper: > For simplicity, let’s use the notation Yes, let's! Except in lisp, you can't. ;) (Yes, feeling snarky.)

jpr 16y ago
Except you can, just use reader macros.
- prodigal_erik 16y ago
  Lisp is a remarkable toolkit for creating domain-specific languages with any syntax you happen to need. It amazes me how many people try to use it as an ordinary programming language without modifying it at all, and then give up because they found nothing special about it. I think they're missing the point.
- vorg 16y ago
  With these reader macros, can the code in the blog example be rewritten as below, so it still directly maps to the Lisp tree-like semantics, but be more readable? defun diff(expr, x){ if(expr == x) 1 else if(car(expr) == 'plus') ['plus', diff(cadr(expr), x), caddr(expr), x] else if(car(expr) == 'times')[ 'plus', ['times', cadr(expr), diff(caddr(expr), x)], ['times', diff(cadr(expr), x), caddr(expr)] ]else 0 }
  - jpr 16y ago
    I have to admit that I'm not an expert on reader macros, so I can't say for sure. Your example seems to map some already used characters, so it wouldn't be a pure extension of the reader. I guess you could make a readtable that recognizes that syntax and transforms it to the tree-like semantics. FWIW, I don't find it more readable than the standard notation. Maybe I have become too accustomed to the standard CL-notation.
  - crux_ 16y ago
    I'm sure it's possible; lisp is very flexible. But would your example code still be considered lisp?

ohyes 16y ago

Does anyone else have trouble with making the distinction between curly braces and parenthesis? I'm pretty near sighted, so I always have to squint to figure out if something is a brace or a paren. I think it is one of the main reasons I like lisp... There are no braces, and all I have to do is make sure that emacs indents everything properly (ctrl+alt+q at top of form... in my head I call it 'regrinding') so I know that the forms I've written have the closing parens in the proper places. I know people complain about the parens, but I spend literally no time fudging with the formatting of my lisp code.. emacs just does it. Java and C code, however I always end up fiddling with (even with an 'advanced' IDE like eclipse).

jpr 16y ago

"too many parenthesis" is simply a flag that someone is speaking only about his initial emotional response, not out of actual use experience or measurement. When you actually count parenthesis in equivalent programs in C (or C-like syntax) and Lisp, they are almost exactly the same. When you include the ;.->*& -stuff, C starts to lose because `foo.bar();´ in C becomes simply `(bar foo)´ in Lisp.

deleted 16y ago

[deleted]

partition 16y ago

Those who keep going on and on about parentheses in Lisp should try Haskell, which is basically* Lisp, except everything has one argument and is left associative. This simple rule removes a TON of parens. Add in the $, . operators and a bunch of other potential parentheses are eliminated. *Except also that Haskell is typed and does not include code quoting/eval. But that's what Template Haskell is for :)

petdog 16y ago
Except that I find myself adding tons of parens to my haskell to be able to read it. Lisp may have spoiled me.

qu1j0t3 16y ago

@mahmud I don't have to invent backronyms for urmom.