4 ms·

This argument/response comes up every time.... Argument: "Lisp has too many parentheses. It's unreadable." Response: "It's conceptually elegant that everythi

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
  That honestly looks more like a failure on the part of the Python library maintainer to create a pleasant way to create record prototypes. I mean, all you're doing in your list example is creating dictionary and list examples of the mapping you want. There is literally nothing stopping you from doing that in Python.
  - swannodette 16y ago
    creators = [{"name" :{"name_authority" :TextField, "name_authority_id" :IntegerField, "display_string" :TextField}, "user_id" :IntegerField, "roles" :[TextField], "attrs" :[TextField], "xts" :[TextField]}] Yes you could do something like this. But the lack of keywords does reintroduces some noise via the quotes around strings. Moving the colons around like this to give visual alignment would probably be frowned upon. So my sense is that this would be considered "un-Pythonic" but I could be wrong.
    - cma 16y ago
      Use single quotes; less noise.
    - DisposaBoy 16y ago
      who writes code like that? creators = [ { "name": { "name_authority": TextField, "name_authority_id": IntegerField, "display_string": TextField }, "user_id" :IntegerField, "roles": [TextField], "attrs": [TextField], "xts": [TextField] } ] anyway
      - swannodette 16y ago
        I certainly don't write Python code that looks like what I wrote. My point was that the various idiomatic versions, including yours, certainly isn't any more readable than the Clojure version.
tung 16y ago
My guess is that what people complain about isn't really the parentheses, but rather heavy nesting of Lisp programs compared to other languages. If parentheses were replaced with something else, they'd probably complain about that something else.
- KirinDave 16y ago
  Except that most modern lisps don't even nest that deeply anymore. At least, not anymore than every functional language that uses nesting to offer new immutable lexical scopes does. Seriously, the average nesting depth of a C program is maybe 3-4 (function, conditional, loop, etc), and C programs are simple. More complex languages like Java and C++ will easily have 4-7 levels of nesting on average. Clojure and Arc code are probably right on par with that.
  - gtani 16y ago
    What happens when a VP of Engineering decides that Cyclomatic complexity will be capped at 10: http://stackoverflow.com/questions/105852/conditional-logging-with-minimal-cyclomatic-complexity http://stackoverflow.com/questions/105852/conditional-loggin...
    - KirinDave 16y ago
      It seems pointless to mandate it, but I don't think it'd really cause a problem for most real-world clojure programs. For one, cyclomatic complexicty measures independent paths, and I don't think that's what most people are complaining about when they say "lisp has too many parenthesis". They're complaining about how the structures expected require a lot of (sometimes arduous-seeming) complexity. Indeed, I suspect that the cyclomatic complexity of an average lisp function will be less than that of, say, the average Python function. It'd be the same with any functional language; they encourage you to only have one or two conditionals per function.
- wtracy 16y ago
  Indeed. It took me a long time to get used to this in functional programming, and I got annoyed with how deeply nested my code got. Then I learned that it was just the language telling me to decompose my functions! :-)
derefr 16y ago
I think the real point here—the one that half the article was spent in making—is that Lisp (the grammar that uses lots of parentheses) isn't the same as Lisp (the concept). Lisp (the concept) isn't a language at all, as far as we use the term to describe something that humans can use to communicate information serially. Lisp is actually a model for representing a transformation of an AST as an AST—no more, and no less. To communicate a Lisp transformation model, we must encode it as a stream of characters—and that stream, if we don't do anything to make it readable, becomes the "degenerate case" of programming languages: pure S-expression syntax. However, there's no need for Lisp and S-expressions to go hand-in-hand. For decades we've known that programming languages have UX considerations every bit as important as those of the programs made with them. Lisp precedes that realization, but even when Lisp was first invented, S-expressions were never intended to be its primary encoding (search "M-expressions".) It just turned out that Lisp was such a powerful model that it was immediately put to use before a nicer syntax could be wrapped around it. (Also, its core user-base were mathematicians, who already had the isomorphic Lambda-calculus notation to think in terms of, so the learning curve wasn't evident to them.) The point I'm getting at, here, is that any programming language syntax can have Lisp-transformation-model semantics. As long as `read` and `eval` are separate functions of your compiler+runtime, and the AST that normally travels between the two can be manipulated by your own code, you have a Lisp. That's what people mean when they say that "the parentheses don't matter."
anon_d 16y ago
It's not a problem at all, there is zero readability cost to all of those parens. Nobody with any experience coding lisp has any trouble reading it. Personally, I find lisp code to be considerably easier to read than other languages that I otherwise prefer.

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
That honestly looks more like a failure on the part of the Python library maintainer to create a pleasant way to create record prototypes. I mean, all you're doing in your list example is creating dictionary and list examples of the mapping you want. There is literally nothing stopping you from doing that in Python.
- swannodette 16y ago
  creators = [{"name" :{"name_authority" :TextField, "name_authority_id" :IntegerField, "display_string" :TextField}, "user_id" :IntegerField, "roles" :[TextField], "attrs" :[TextField], "xts" :[TextField]}] Yes you could do something like this. But the lack of keywords does reintroduces some noise via the quotes around strings. Moving the colons around like this to give visual alignment would probably be frowned upon. So my sense is that this would be considered "un-Pythonic" but I could be wrong.
  - cma 16y ago
    Use single quotes; less noise.
  - DisposaBoy 16y ago
    who writes code like that? creators = [ { "name": { "name_authority": TextField, "name_authority_id": IntegerField, "display_string": TextField }, "user_id" :IntegerField, "roles": [TextField], "attrs": [TextField], "xts": [TextField] } ] anyway
    - swannodette 16y ago
      I certainly don't write Python code that looks like what I wrote. My point was that the various idiomatic versions, including yours, certainly isn't any more readable than the Clojure version.

tung 16y ago

My guess is that what people complain about isn't really the parentheses, but rather heavy nesting of Lisp programs compared to other languages. If parentheses were replaced with something else, they'd probably complain about that something else.

KirinDave 16y ago
Except that most modern lisps don't even nest that deeply anymore. At least, not anymore than every functional language that uses nesting to offer new immutable lexical scopes does. Seriously, the average nesting depth of a C program is maybe 3-4 (function, conditional, loop, etc), and C programs are simple. More complex languages like Java and C++ will easily have 4-7 levels of nesting on average. Clojure and Arc code are probably right on par with that.
- gtani 16y ago
  What happens when a VP of Engineering decides that Cyclomatic complexity will be capped at 10: http://stackoverflow.com/questions/105852/conditional-logging-with-minimal-cyclomatic-complexity http://stackoverflow.com/questions/105852/conditional-loggin...
  - KirinDave 16y ago
    It seems pointless to mandate it, but I don't think it'd really cause a problem for most real-world clojure programs. For one, cyclomatic complexicty measures independent paths, and I don't think that's what most people are complaining about when they say "lisp has too many parenthesis". They're complaining about how the structures expected require a lot of (sometimes arduous-seeming) complexity. Indeed, I suspect that the cyclomatic complexity of an average lisp function will be less than that of, say, the average Python function. It'd be the same with any functional language; they encourage you to only have one or two conditionals per function.
wtracy 16y ago
Indeed. It took me a long time to get used to this in functional programming, and I got annoyed with how deeply nested my code got. Then I learned that it was just the language telling me to decompose my functions! :-)

derefr 16y ago

I think the real point here—the one that half the article was spent in making—is that Lisp (the grammar that uses lots of parentheses) isn't the same as Lisp (the concept). Lisp (the concept) isn't a language at all, as far as we use the term to describe something that humans can use to communicate information serially. Lisp is actually a model for representing a transformation of an AST as an AST—no more, and no less. To communicate a Lisp transformation model, we must encode it as a stream of characters—and that stream, if we don't do anything to make it readable, becomes the "degenerate case" of programming languages: pure S-expression syntax. However, there's no need for Lisp and S-expressions to go hand-in-hand. For decades we've known that programming languages have UX considerations every bit as important as those of the programs made with them. Lisp precedes that realization, but even when Lisp was first invented, S-expressions were never intended to be its primary encoding (search "M-expressions".) It just turned out that Lisp was such a powerful model that it was immediately put to use before a nicer syntax could be wrapped around it. (Also, its core user-base were mathematicians, who already had the isomorphic Lambda-calculus notation to think in terms of, so the learning curve wasn't evident to them.) The point I'm getting at, here, is that any programming language syntax can have Lisp-transformation-model semantics. As long as `read` and `eval` are separate functions of your compiler+runtime, and the AST that normally travels between the two can be manipulated by your own code, you have a Lisp. That's what people mean when they say that "the parentheses don't matter."

anon_d 16y ago

It's not a problem at all, there is zero readability cost to all of those parens. Nobody with any experience coding lisp has any trouble reading it. Personally, I find lisp code to be considerably easier to read than other languages that I otherwise prefer.