Live data from Hacker News

Lisp has too many parentheses...

symbo1ics.com

71–80 of 81 posts

Re: Lisp has too many parentheses...

#71
post #40

Earlier quoted context omitted.

I find this amusing because I've always found "lisp has too many parenthesis" and "python has too much significant whitespace" to be roughly equivalent in terms of relevance.

Nobody writes tools that randomly shred parentheses, but this happens all the time with whitespace. I'm halfway convinced Ruby is encroaching on Python because you can't really talk about the latter on the web without ridiculous workarounds.

How so? I suppose if you paste Python code in a comment box that happens to eat whitespace, then there is a problem, yes... but for those cases there's pastebin and such. Other than that, if you're writing a blog post or article, then you can just slap the Python code in
 blocks, which preserves the whitespace; most "humane" text editing formats like Textile and Markdown have ways to preserve it as well.

Re: Lisp has too many parentheses...

#72
post #69
post #47

Earlier quoted context omitted.

Except you can, just use reader macros.

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 }

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.

Re: Lisp has too many parentheses...

#73

Earlier quoted context omitted.

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.…

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

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.

Re: Lisp has too many parentheses...

#74
post #3

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" l…

So when you call them first and rest, how do you destructure lists of lists? Actually, now that I think about it, "fire" is much cooler sounding than "cadr". But not as cool sounding as cadadr.

Or e.g. cadaadr -> frffrst, "first of rest of first of first of rest of" . I don't know if any Lisp uses composed first/rest that way, but if I were implementing a new Lisp from scratch I would probably use that rather than car / cdr.

(I prefer pattern matching / destructuring-bind, though.)

Re: Lisp has too many parentheses...

#75
post #69
post #47

Earlier quoted context omitted.

Except you can, just use reader macros.

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 }

I'm sure it's possible; lisp is very flexible.

But would your example code still be considered lisp?

Re: Lisp has too many parentheses...

#76
post #70

Earlier quoted context omitted.

By requiring parenthesis, indentation becomes so much simpler, the programmer doesn't even have to do it. It's done automagically.

It's done automagically for me in Python and Haskell, too. Instead of hitting the paren keys in Emacs, I just hit tab to cycle through the possibilities. Because the Lisps have such a canonical way to indent them, in practise it feels very similar to significant whitespace with a funny input method.

"automagically", "I just hit tab"

You and Understanding are not exactly on speaking terms, are you?

Re: Lisp has too many parentheses...

#77
post #70

Earlier quoted context omitted.

It's done automagically for me in Python and Haskell, too. Instead of hitting the paren keys in Emacs, I just hit tab to cycle through the possibilities. Because the Lisps have such a canonical way to indent them, in practise it feels very similar to significant whitespace with a funny input method.

"automagically", "I just hit tab" You and Understanding are not exactly on speaking terms, are you?

Normally, hitting tab just insert another \t wherever your cursor happens to be. Hitting tab in haskell-mode or python-mode just cycles through the two or three (or sometimes one) possibility for indentation for the current line. That's automagically enough for me.

Re: Lisp has too many parentheses...

#78

Earlier quoted context omitted.

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

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.

I don't speak for everyone but the reason I see lisp code as unreadable is that most of what I've seen is written like your example. That is, there is some indentation which helps, but it's as-if the coder is afraid to utilise vertical space so they put all the closing brackets on the same line, most of the opening ones in the middle of some lines. With that kind of formatting (for me at-least), it's not immediately clear which.

Re: Lisp has too many parentheses...

#79

Earlier quoted context omitted.

Nobody writes tools that randomly shred parentheses, but this happens all the time with whitespace. I'm halfway convinced Ruby is encroaching on Python because you can't really talk about the latter on the web without ridiculous workarounds.

How so? I suppose if you paste Python code in a comment box that happens to eat whitespace, then there is a problem, yes... but for those cases there's pastebin and such. Other than that, if you're writing a blog post or article, then you can just slap the Python code in blocks, which preserves the whitespace; most "humane" text editing formats like Textile and Markdown have ways to preserve it as well.

> comment box that happens to eat whitespace

In my experience, that's easily 2/3 of the web and half of all email and IM clients. It was so bad that I was surprised when it didn't fail somehow.

Pastebin is just the kind of workaround I would hate to be consigned to. Reading offline or printing becomes a huge headache because important details are constantly missing.

Re: Lisp has too many parentheses...

#80
post #66

Earlier quoted context omitted.

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 c…

What happens when a VP of Engineering decides that Cyclomatic complexity will be capped at 10: http://stackoverflow.com/questions/105852/conditional-loggin...

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.

Post reply on HN