6 ms·

I'd like to find out how people tolerate ()[]{};,. in their programming, in far greater quantities and in more complex interspersal than Lisp's parens. )]];));

I'd like to find out how people tolerate ()[]{};,. in their programming, in far greater quantities and in more complex interspersal than Lisp's parens. )]];));}}};

moxious 9y ago
I think it's about visual parsing. They may be greater in number in C derived languages but it's not idiomatic or considered clean by anyone to write it as you did, where it's typical to see things like )))))) in lisp. If there were multiple markers stacked up in a C based language they'd be visually distinguished from one another ];} and you'd at least have a chance. Look, we can get used to anything so clearly the lisp way can work. But it seems pretty straightforward to me why people think it's visually confusing and why lisp gets made fun of. Simplicity in syntax is great but lisp really overdid it. If you invented a human language that could get by with only 12 letters, I wouldn't give you kudos for that because of the general principle that simplicity is good...
- agumonkey 9y ago
  I understand and appreciate syntactic classification. But it's a false thing. It makes you care about syntax more than semantics.
- DonaldFisk 9y ago
  There have been at least three attempts to change the syntax of Lisp, so that it looks more like Algol: Lisp 2, CGOL, and Dylan. None of these gained much traction. Lisp programmers prefer the parentheses. When you autoindent, the indentation of the code makes its underlying structure (AST) clear without having to count either parentheses in Lisp or braces in C. By the 1970s, autoindenting editors (EMACS) and structure editors had been developed for Lisp. In the C/Unix world, until recently, indentation and parenthesis/brace counting had to be done by hand. Among C programmers (but not, to their credit, Java programmers) there are still arguments about code layout, a problem solved decades ago for Lisp.
  - kazinator 9y ago
    > In the C/Unix world, until recently, indentation and parenthesis/brace counting had to be done by hand. Nope! The vi editor has a :set lisp mode, and a % command to jump to matching parens. I think that was already in vi in the 1980's. FWIW, % is described in POSIX; Lisp mode isn't.
    - DonaldFisk 9y ago
      Ta. I just tried it. If it's all the same with you I think I'll stick with Emacs. :-) What I was trying to say is that these things are easier to do by hand in C than in Lisp, but more difficult to do algorithmically, and this discouraged people developing syntax-aware editors, and encouraged the plethora of competing C styles. In the Lisp world, the difficulty of doing these by hand resulted in earlier syntax aware editors and the consensus on style.
      - kazinator 9y ago
        In Lisp style, there is a "local maximum" (global?). Deviations from the style are obvious losers. In C, there are many choices, which are all viable. int main(void) { FILE *f = fopen("commands", "r"); if (f) { char line[512]; while (fgets(line, sizeof line, f)) { ... } fclose(f); return 0; } else { printf("failed to open file\n"); exit(EXIT_FAILURE); } }
        DonaldFisk 9y ago
        The many choices available for C are the problem. I write C in K&R style, but that makes me a heretic in many places. Java programmers have sensibly agreed on a single style, despite there being as many choices for Java as there are for C.
- flavio81 9y ago
  The thing is, if you actually set yourself out to create an application in Lisp, and you do learn the language and the tools made for programming in that language, not only you will have no problem with parentheses... ... but you also will find that most of your code is highly readable! Lisp code (or at least Common Lisp code) can be highly readable. I never need to count parenthesis to understand code. The indentation itself makes the structure obvious. And if there is any doubt, the editor (say, Emacs) will tell me where each expression ends. > "But it seems pretty straightforward to me why people think it's visually confusing and why lisp gets made fun of." "Appearances" are not the same as "reality".
munificent 9y ago
You know, I think it's a fine argument to say, "Yes, Lisp has a lot of parentheses but we like how it looks." I don't think it makes sense to say, "No, other languages have more punctuation characters than Lisp." The latter is an objective statement that can be actually tested. I went to Rosetta Code and grabbed the implementations of Conway's Game of Life in Racket, Ruby, Python, and Java. For each one, I manually removed comments and string literals. Then I wrote a little script. It looks at each character in the file and groups them into categories: bracket: ()[]{} whitespace: space\t\r\n text: a-zA-Z01-9_ punctuation: =,;<>-'!|?:#/*%+. Then I looked at each file to see what fraction of non-whitespace characters are brackets or punctuation (including brackets). Here's the results: bracket punctuation life.java 13.25% 27.52% life.py 13.27% 21.95% life.rb 9.56% 23.73% life.scm 22.29% 28.30% The Racket implementation has roughly twice as many bracketing characters as the other languages, and more of all kinds of punctuation than any of them. It may be that the languages and example programs I chose aren't representative, but I'd be surprised if another corpus was significantly different. Most languages have multiple levels of precedence. The entire point of that is to allow eliding explicit bracketing characters for commonly nested subexpressions. You may dislike that feature, which is reasonable. But I don't think you can argue that it doesn't exist and doesn't accomplish what it intends to do. Consider: var isCloser = x1 * x1 + y1 * y1 < x2 * x2 + y2 * y2 // 0 brackets (define is-closer (< (+ (* x1 x1) (* y1 y1)) (+ (* x2 x2) (* y2 y2)))) ; 16 brackets
- yorwba 9y ago
  I think most of the non-bracket "punctuation" in Racket is caused by the kebab-case identifiers and to a lesser degree by ? and ! in function names. So in fact "Other languages have more punctuation characters than Lisp." is not an objective statement at all, since it relies on the definition of punctuation, which is subjective or at least language-specific.
  - munificent 9y ago
    Good point. I updated my little script to (roughly) take each language's identifier rules into account. Now "?" is considered an identifier character in Ruby and "-", "!", and "?" are punctuation in Racket. It gets a little fuzzy, of course because ">" works like punctuation in "(> 1 2)" but less so in "(number->string 123)". bracket punctuation life.java 13.25% 27.52% life.py 13.27% 21.95% life.rb 9.56% 23.29% life.scm 22.29% 24.81% This gets Racket down to having similar levels of punctuation but note that, of course, brackets are still significantly more common than other languages.

I'd like to find out how people tolerate ()[]{};,. in their programming, in far greater quantities and in more complex interspersal than Lisp's parens. )]];));}}};

moxious 9y ago

I think it's about visual parsing. They may be greater in number in C derived languages but it's not idiomatic or considered clean by anyone to write it as you did, where it's typical to see things like )))))) in lisp. If there were multiple markers stacked up in a C based language they'd be visually distinguished from one another ];} and you'd at least have a chance. Look, we can get used to anything so clearly the lisp way can work. But it seems pretty straightforward to me why people think it's visually confusing and why lisp gets made fun of. Simplicity in syntax is great but lisp really overdid it. If you invented a human language that could get by with only 12 letters, I wouldn't give you kudos for that because of the general principle that simplicity is good...

agumonkey 9y ago
I understand and appreciate syntactic classification. But it's a false thing. It makes you care about syntax more than semantics.
DonaldFisk 9y ago
There have been at least three attempts to change the syntax of Lisp, so that it looks more like Algol: Lisp 2, CGOL, and Dylan. None of these gained much traction. Lisp programmers prefer the parentheses. When you autoindent, the indentation of the code makes its underlying structure (AST) clear without having to count either parentheses in Lisp or braces in C. By the 1970s, autoindenting editors (EMACS) and structure editors had been developed for Lisp. In the C/Unix world, until recently, indentation and parenthesis/brace counting had to be done by hand. Among C programmers (but not, to their credit, Java programmers) there are still arguments about code layout, a problem solved decades ago for Lisp.
- kazinator 9y ago
  > In the C/Unix world, until recently, indentation and parenthesis/brace counting had to be done by hand. Nope! The vi editor has a :set lisp mode, and a % command to jump to matching parens. I think that was already in vi in the 1980's. FWIW, % is described in POSIX; Lisp mode isn't.
  - DonaldFisk 9y ago
    Ta. I just tried it. If it's all the same with you I think I'll stick with Emacs. :-) What I was trying to say is that these things are easier to do by hand in C than in Lisp, but more difficult to do algorithmically, and this discouraged people developing syntax-aware editors, and encouraged the plethora of competing C styles. In the Lisp world, the difficulty of doing these by hand resulted in earlier syntax aware editors and the consensus on style.
    - kazinator 9y ago
      In Lisp style, there is a "local maximum" (global?). Deviations from the style are obvious losers. In C, there are many choices, which are all viable. int main(void) { FILE *f = fopen("commands", "r"); if (f) { char line[512]; while (fgets(line, sizeof line, f)) { ... } fclose(f); return 0; } else { printf("failed to open file\n"); exit(EXIT_FAILURE); } }
      - DonaldFisk 9y ago
        The many choices available for C are the problem. I write C in K&R style, but that makes me a heretic in many places. Java programmers have sensibly agreed on a single style, despite there being as many choices for Java as there are for C.
flavio81 9y ago
The thing is, if you actually set yourself out to create an application in Lisp, and you do learn the language and the tools made for programming in that language, not only you will have no problem with parentheses... ... but you also will find that most of your code is highly readable! Lisp code (or at least Common Lisp code) can be highly readable. I never need to count parenthesis to understand code. The indentation itself makes the structure obvious. And if there is any doubt, the editor (say, Emacs) will tell me where each expression ends. > "But it seems pretty straightforward to me why people think it's visually confusing and why lisp gets made fun of." "Appearances" are not the same as "reality".

munificent 9y ago

You know, I think it's a fine argument to say, "Yes, Lisp has a lot of parentheses but we like how it looks." I don't think it makes sense to say, "No, other languages have more punctuation characters than Lisp." The latter is an objective statement that can be actually tested. I went to Rosetta Code and grabbed the implementations of Conway's Game of Life in Racket, Ruby, Python, and Java. For each one, I manually removed comments and string literals. Then I wrote a little script. It looks at each character in the file and groups them into categories: bracket: ()[]{} whitespace: space\t\r\n text: a-zA-Z01-9_ punctuation: =,;<>-'!|?:#/*%+. Then I looked at each file to see what fraction of non-whitespace characters are brackets or punctuation (including brackets). Here's the results: bracket punctuation life.java 13.25% 27.52% life.py 13.27% 21.95% life.rb 9.56% 23.73% life.scm 22.29% 28.30% The Racket implementation has roughly twice as many bracketing characters as the other languages, and more of all kinds of punctuation than any of them. It may be that the languages and example programs I chose aren't representative, but I'd be surprised if another corpus was significantly different. Most languages have multiple levels of precedence. The entire point of that is to allow eliding explicit bracketing characters for commonly nested subexpressions. You may dislike that feature, which is reasonable. But I don't think you can argue that it doesn't exist and doesn't accomplish what it intends to do. Consider: var isCloser = x1 * x1 + y1 * y1 < x2 * x2 + y2 * y2 // 0 brackets (define is-closer (< (+ (* x1 x1) (* y1 y1)) (+ (* x2 x2) (* y2 y2)))) ; 16 brackets

yorwba 9y ago
I think most of the non-bracket "punctuation" in Racket is caused by the kebab-case identifiers and to a lesser degree by ? and ! in function names. So in fact "Other languages have more punctuation characters than Lisp." is not an objective statement at all, since it relies on the definition of punctuation, which is subjective or at least language-specific.
- munificent 9y ago
  Good point. I updated my little script to (roughly) take each language's identifier rules into account. Now "?" is considered an identifier character in Ruby and "-", "!", and "?" are punctuation in Racket. It gets a little fuzzy, of course because ">" works like punctuation in "(> 1 2)" but less so in "(number->string 123)". bracket punctuation life.java 13.25% 27.52% life.py 13.27% 21.95% life.rb 9.56% 23.29% life.scm 22.29% 24.81% This gets Racket down to having similar levels of punctuation but note that, of course, brackets are still significantly more common than other languages.