Live data from Hacker News

Lisp has too many parentheses...

symbo1ics.com

31–40 of 81 posts

Re: Lisp has too many parentheses...

#31

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.

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.

Paul Graham says:

> We can get rid of (or make optional) a lot of parentheses by making indentation significant. That's how programmers read code anyway: when indentation says one thing and delimiters say another, we go by the indentation. Treating indentation as significant would eliminate this common source of bugs as well as making programs shorter.

http://www.paulgraham.com/popular.html

Re: Lisp has too many parentheses...

#32

Earlier quoted context omitted.

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

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.

  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.

Re: Lisp has too many parentheses...

#33

Earlier quoted context omitted.

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.

Paul Graham says: > We can get rid of (or make optional) a lot of parentheses by making indentation significant. That's how programmers read code anyway: when indentation says one thing and delimiters say another, we go by the indentation. Treating indentation as significant would eliminate this common source of bugs as well as making programs shorter. http://www.paulgraham.com/popular.html

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

Re: Lisp has too many parentheses...

#35
post #8

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.

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

Re: Lisp has too many parentheses...

#36

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.

I've fought Python's "semantic" indentation at least as much as I've fought ; : => , ( ) { } [ ] _ ' " $ | \ \\ \\\\ / ... et al.

Re: Lisp has too many parentheses...

#37
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.

Maybe im to inexperienced with classic lisps, or maybe im just spoiled by clojure, but i have no idea what cadadr means, is it the rest of the first, of the rest of the first, or the other way around?

Re: Lisp has too many parentheses...

#39

Earlier quoted context omitted.

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.

Maybe im to inexperienced with classic lisps, or maybe im just spoiled by clojure, but i have no idea what cadadr means, is it the rest of the first, of the rest of the first, or the other way around?

For things like cadadr, I just chop off the "c" and "r", and use the middle part to figure out the sequence of car and cdr calls. (cADADr x) = (cAr (cDr (cAr (cDr x)))), which would be (first (rest (first (rest x)))) in Clojure.

Re: Lisp has too many parentheses...

#40

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.

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.
Post reply on HN