8 ms·

Please don't format code with ))))))) at the end for the love of code! Use readable indentation instead as your whole point is to make things look simple to und

Please don't format code with ))))))) at the end for the love of code! Use readable indentation instead as your whole point is to make things look simple to understand. That actually warrants a slap the back of your head from a team of onlookers, one at a time.

pg314 10y ago
The collection of closing parentheses at the end is considered good style for all of the Lisp languages I'm familiar with (Scheme, Common Lisp, Elisp). Here's an example of the style in a file from the SBCL implementation of Common Lisp: https://github.com/sbcl/sbcl/blob/master/src/code/bignum-random.lisp https://github.com/sbcl/sbcl/blob/master/src/code/bignum-ran... Any decent editor will balance the parentheses for you.
- sebringj 10y ago
  There goes taste.
  - veddox 10y ago
    If you're willing to accuse the authors of SICP (and every Lisp developer since) of bad taste, then so be it...
    - sebringj 10y ago
      My common-sensometer demands it.
actsasbuffoon 10y ago
Once you look at enough of it, your brain starts to see lisps differently. The parens fade away, and you mostly just see the indentation. It looks a little like Python once you adjust.
- peatmoss 10y ago
  That's exactly right--kind of like working with an RPN calculator or staring at one of those "is it a vase or two faces?" pictures. Further, once the brain flip happens, languages that don't use S-expressions start to feel uncomfortably... uncontained.
  - hashkb 10y ago
    Lisp critics have heard this argument, and are choosing to continue hating on the parens. It's easy to find a superficial reason to hate things.
    - kazinator 10y ago
      Yes; that argument actually has to be experienced and no only heard. In my experience, the parens nonsense comes almost entirely from programmers with no Lisp coding experience. It's based on "that looks as if it might be hard to edit".
    - peatmoss 10y ago
      Which is why lisp proponents have such a hard time understanding lisp critics: "Wait, you mean you were willing to reason through pointer arithmetic, monads, implementing a b-tree, etc. but you simply saw the parens and decided that would forever be the thing that you cannot, will not overcome? I mean in spite of all the fairly objective benefits of having a perfectly regular syntax, and code that can be processed by computers?"
- qwertyuiop924 10y ago
  Indeed. And with wisp (a scheme preprocessor/language extension), you can even write indentation-sensitive code, like it's python.
  - actsasbuffoon 10y ago
    Parinfer explores some of the same ideas, but as an editor extension: https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/
veddox 10y ago
That is actually perfectly well formatted Lisp/Scheme code, indented exactly the way Emacs does it for you. Presumably you would want to close of one paren per line (C-style), but speaking as a Lisp programmer I would say that that just wastes vertical space while not improving legibility. Compare these two links: https://www.emacswiki.org/emacs/CodingStyle https://www.emacswiki.org/emacs/CodingStyle http://stackoverflow.com/questions/2207255/lisp-parentheses http://stackoverflow.com/questions/2207255/lisp-parentheses
kazinator 10y ago
Clueless or crazy? It works like this: suppose you have an expression all in one line: (and (or (foo) (bar)) (not (xyzzy))) Of course you close the parens together; just like in any other notation that uses parens. When the line is broken into mutiple lines, the parens just stay where they are: (and (or (foo) (bar)) (not (xyzzy))) ^ ^ arbitrarily, let's break here (and (or (foo) (bar)) (not (xyzzy))) Beauty. This does not require additional editing to make: (and (or (foo) (bar) ) (not (xyzzy)) ) Yikes! If you do this you will get flak from almost every Lisp programmer. (Why piss off those nice five or six people?) This is done the same way in common coding styles in other languages, like, C: if ((cond1 || cond2) && (cond3 || cond4)) // oh look stmt; It's not commonly done with braces in C-family languages, but that is neither here nor there; and it can be done fairly nicely with those braces.
- sebringj 10y ago
  The wonderful thing about "or" is that you can keep adding on to it and only one statement has to be true. "or not". I'll go with "or not". In any world where you have beginning programmers, or programmers not used to Lisp seeing ))))))))) at the end of a line, this is cognitively difficult to keep track of the number of closing braces without having some editor assist you doing the counting for you. This reminds me of indenting in python being touted as easier than having brackets as whitespace matters but editing is terrible without having line guides turned on when any deeper nesting arises.
  - veddox 10y ago
    > without having some editor assist you doing the counting for you The problem with your statement is in just this point: everybody does have an editor that does this for you ;-) Unless you write code with ed, or Windows Notepad, I don't know of a single editor out there that doesn't do this.
  - deleted 10y ago
    [deleted]
  - 10y ago
Johnny_Brahms 10y ago
Let me guess: you don't program lisps much? This is the preferred style of almost every lisp. After a week of it you don't see the parens, and after learning to program using paredit you won't even have to bother with them ever again. I write object pascal for a living, and every second of it makes me long for the comfort of parens everywhere.
- deleted 10y ago
  [deleted]
sebringj 10y ago
Interestingly enough, a comment above well taken by qwertyuiop924 rewrote the example who is well versed in Lisp. Hmmm. Isn't that interesting?
Johnny_Brahms 10y ago
I think the reason you are being downvoted is because you obviously never spent much time learning scheme (or even looked at much scheme code). Yet you still condemn the code and say the person deserves "slaps". To anyone that actually knows scheme, this comes off as pretty ignorant, and _very_ arrogant. This is the way people write lisps, and using tools like paredit, you don't really notice (or deal with) parentheses at all. They just end up there, and that's much better than having them on a new line. They are unimportant. If the code is properly aligned, having the parens on a new line would just be line noise.

pg314 10y ago

The collection of closing parentheses at the end is considered good style for all of the Lisp languages I'm familiar with (Scheme, Common Lisp, Elisp). Here's an example of the style in a file from the SBCL implementation of Common Lisp: https://github.com/sbcl/sbcl/blob/master/src/code/bignum-random.lisp https://github.com/sbcl/sbcl/blob/master/src/code/bignum-ran... Any decent editor will balance the parentheses for you.

sebringj 10y ago
There goes taste.
- veddox 10y ago
  If you're willing to accuse the authors of SICP (and every Lisp developer since) of bad taste, then so be it...
  - sebringj 10y ago
    My common-sensometer demands it.

actsasbuffoon 10y ago

Once you look at enough of it, your brain starts to see lisps differently. The parens fade away, and you mostly just see the indentation. It looks a little like Python once you adjust.

peatmoss 10y ago
That's exactly right--kind of like working with an RPN calculator or staring at one of those "is it a vase or two faces?" pictures. Further, once the brain flip happens, languages that don't use S-expressions start to feel uncomfortably... uncontained.
- hashkb 10y ago
  Lisp critics have heard this argument, and are choosing to continue hating on the parens. It's easy to find a superficial reason to hate things.
  - kazinator 10y ago
    Yes; that argument actually has to be experienced and no only heard. In my experience, the parens nonsense comes almost entirely from programmers with no Lisp coding experience. It's based on "that looks as if it might be hard to edit".
  - peatmoss 10y ago
    Which is why lisp proponents have such a hard time understanding lisp critics: "Wait, you mean you were willing to reason through pointer arithmetic, monads, implementing a b-tree, etc. but you simply saw the parens and decided that would forever be the thing that you cannot, will not overcome? I mean in spite of all the fairly objective benefits of having a perfectly regular syntax, and code that can be processed by computers?"
qwertyuiop924 10y ago
Indeed. And with wisp (a scheme preprocessor/language extension), you can even write indentation-sensitive code, like it's python.
- actsasbuffoon 10y ago
  Parinfer explores some of the same ideas, but as an editor extension: https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/

veddox 10y ago

That is actually perfectly well formatted Lisp/Scheme code, indented exactly the way Emacs does it for you. Presumably you would want to close of one paren per line (C-style), but speaking as a Lisp programmer I would say that that just wastes vertical space while not improving legibility. Compare these two links: https://www.emacswiki.org/emacs/CodingStyle https://www.emacswiki.org/emacs/CodingStyle http://stackoverflow.com/questions/2207255/lisp-parentheses http://stackoverflow.com/questions/2207255/lisp-parentheses

kazinator 10y ago

Clueless or crazy? It works like this: suppose you have an expression all in one line: (and (or (foo) (bar)) (not (xyzzy))) Of course you close the parens together; just like in any other notation that uses parens. When the line is broken into mutiple lines, the parens just stay where they are: (and (or (foo) (bar)) (not (xyzzy))) ^ ^ arbitrarily, let's break here (and (or (foo) (bar)) (not (xyzzy))) Beauty. This does not require additional editing to make: (and (or (foo) (bar) ) (not (xyzzy)) ) Yikes! If you do this you will get flak from almost every Lisp programmer. (Why piss off those nice five or six people?) This is done the same way in common coding styles in other languages, like, C: if ((cond1 || cond2) && (cond3 || cond4)) // oh look stmt; It's not commonly done with braces in C-family languages, but that is neither here nor there; and it can be done fairly nicely with those braces.

sebringj 10y ago
The wonderful thing about "or" is that you can keep adding on to it and only one statement has to be true. "or not". I'll go with "or not". In any world where you have beginning programmers, or programmers not used to Lisp seeing ))))))))) at the end of a line, this is cognitively difficult to keep track of the number of closing braces without having some editor assist you doing the counting for you. This reminds me of indenting in python being touted as easier than having brackets as whitespace matters but editing is terrible without having line guides turned on when any deeper nesting arises.
- veddox 10y ago
  > without having some editor assist you doing the counting for you The problem with your statement is in just this point: everybody does have an editor that does this for you ;-) Unless you write code with ed, or Windows Notepad, I don't know of a single editor out there that doesn't do this.
- deleted 10y ago
  [deleted]
- 10y ago

Johnny_Brahms 10y ago

Let me guess: you don't program lisps much? This is the preferred style of almost every lisp. After a week of it you don't see the parens, and after learning to program using paredit you won't even have to bother with them ever again. I write object pascal for a living, and every second of it makes me long for the comfort of parens everywhere.

deleted 10y ago
[deleted]

sebringj 10y ago

Interestingly enough, a comment above well taken by qwertyuiop924 rewrote the example who is well versed in Lisp. Hmmm. Isn't that interesting?

Johnny_Brahms 10y ago

I think the reason you are being downvoted is because you obviously never spent much time learning scheme (or even looked at much scheme code). Yet you still condemn the code and say the person deserves "slaps". To anyone that actually knows scheme, this comes off as pretty ignorant, and _very_ arrogant. This is the way people write lisps, and using tools like paredit, you don't really notice (or deal with) parentheses at all. They just end up there, and that's much better than having them on a new line. They are unimportant. If the code is properly aligned, having the parens on a new line would just be line noise.