11 ms·

>> 1 - All those parenthesis. (Still a top objection) > If you actually count parens fairly you will find that Lisp has no more than any other language Bull.

>> 1 - All those parenthesis. (Still a top objection) > If you actually count parens fairly you will find that Lisp has no more than any other language Bull. For example, compare the Lisp factorial function from the article: (define (fact x) (if (zero? x) 1 (* x (fact (- x 1))))) with the corresponding F# implementation: let rec fact x = if x = 0 then 1 else x * fact (x - 1) That's 7 vs. 1 pair of parens. Also, the problem isn't just that Lisp has so many parens, but that they nest so deeply and quickly. Five nested levels of parens for factorial alone.

Roboprog 9y ago
Try putting the closing parens on a line aligned with the opening one, as if they were K&R style closing braces (ignoring that open-paren goes before keyword/func-name, rather than after) (define (fact x) (if (zero? x) 1 (* x (fact (- x 1))) ) ) Square brackets work in some dialects, as well: [define (fact x) (if (zero? x) 1 (* x (fact (- x 1 ]
- sigjuice 9y ago
  Almost all Lisp code will put the closing parens all together at the end. And the idea is to not care about how many there are by using an editor that provides the appropriate assistance.
  - tomjakubowski 9y ago
    > by using an editor that provides the appropriate assistance. To spell it out: this means Emacs with Paredit, or an imitation thereof.
    - krapp 9y ago
      Having to depend on an editor to make your code legible seems like a bad thing.
      - lisper 9y ago
        Why? (And what language do you use where you don't have to rely on the editor to format your code?)
        krapp 9y ago
        To me, that's a sign that maybe a language has too little syntax. I can read C++, Javascript and PHP just as well in plain text because the other non-paren elements provide necessary contextual cues, along with nesting. Syntax coloring is helpful, but it shouldn't be necessary. I can at least understand nesting closing parens on their own lines, the way Roboprog did above, but throwing all of them on a single line just seems like needless noise.
        KingMob 9y ago
        It's not something we ever really think about. That list of closing parentheses just signals termination of the top-level S-expression. And there's virtually nobody coding in a Lisp that doesn't use a structural editing mode (like Paredit or SmartParens). E.g., any time you type "(", you get "()", enforcing balance. What we rely on is proper indentation to indicate the important groupings.
        sigjuice 9y ago
        Exactly. IMHO, this is quite similar to Python indentation rules, except it is up to writers of Lisp code to be disciplined enough to maintain the proper indentation.
        lisper 9y ago
        No. Our editors auto-indent the code for us. This is one of the reasons Lisp syntax is better than python. Python syntax does not have enough information to auto-indent so it really is up to the programmer. Not so with Lisp.
        9y ago
    - dTal 9y ago
      To any lisp enthusiasts who wonder why the language family isn't more popular: this is 99% of why. You have to use an editor where "copy" is called "Kill-ring-save" is invoked with "Meta-w". Any attempt to use any other tool will be met with incredulous responses to "just use Emacs". It's such a shame because the development environment for Lisp could be so much better than other languages. It could be mindblowingly futuristic, instead of mindblowingly archaic.
      - lispm 9y ago
        > You have to use an editor where "copy" is called "Kill-ring-save" is invoked with "Meta-w" You are misinformed. I'm using a GNU Emacs (-> Aquamacs) on the Mac and cut/paste/copy are invoked with the usual command keys. But usually I use the LispWorks editor, which is also in the Emacs family, and even there cut/copy/paste is the usual command sequence... Both editors are built with excellent Lisp support. One is written in C + Emacs Lisp and the other one in Common Lisp. > mindblowingly archaic You haven't even understood the old part, how would you be able to deal with the futuristic part?
        fao_ 9y ago
        > You haven't even understood the old part, how would you be able to deal with the futuristic part? "You haven't used a PDP-10, how would you be able to deal with a smartphone?"
        lispm 9y ago
        He didn't talk about old technology like 'smartphones', which existed as products (Nokia Communicator, ...) 20 years ago, but claimed that much better 'futuristic' IDEs for Lisp are possible, though what he claims may currently only exist in his imagination...
      - kazinator 9y ago
        I've been programming in Lisp for 17 years now. I've always done it in Vim.
  - tomjakubowski 9y ago
    > by using an editor that provides the appropriate assistance. To spell it out: this means Emacs with Paredit, or an imitation thereof.
Frondo 9y ago
Yeah, you know what else I'm realizing? All the different kinds of punctuation let my eyes skim over different parts of code so easily, and lisp doesn't give me that. You know how, when you're reading natural language, you don't actually read individual letters, not once you have any reading fluency? That's how I read code, too, I'm realizing. When I see the parentheses in C#, my brain just goes "oh that's a method/function call" and I can either skip over the contents of the parens or read them if I need to. Reading comprehension is pretty quick. Looking at all the parens of even that simple lisp factorial, and I realize that I'm feeling a lot of cognitive load that would simply never go away, because the punctuation doesn't let me filter any of it out. I'd have to read everything more carefully.
- lisper 9y ago
  Focus on the words, not the punctuation, just like you do when reading natural language.
- Volt 9y ago
  >You know how, when you're reading natural language, you don't actually read individual letters, not once you have any reading fluency? As difficult as it is to imagine, you can indeed achieve fluency in reading Lisp code. Like with everything else, it takes time and practice.
- spacemanmatt 9y ago
  You get used to reading lisp, the same as you get used to reading all that boilerplate syntax.
- shakna 9y ago
  > Looking at all the parens of even that simple lisp factorial, and I realize that I'm feeling a lot of cognitive load that would simply never go away, because the punctuation doesn't let me filter any of it out. I'd have to read everything more carefully. Completely the opposite here. Parens means function call or list. Lists usually denoted by a quote first. I don't read the parens, I skim everything, reading words. And the punctuation is really simple. For example: if (number? a) + a b error "Not A Number" a I stripped most of the parens there, (like Wisp [0] does), because I don't really see them. I see function call and arguments, because there isn't anything else. Scheme has the very least syntax out of just about any programming language I've used. It has a tiny cognitive load compared to most. [0] http://dustycloud.org/blog/wisp-lisp-alternative/ http://dustycloud.org/blog/wisp-lisp-alternative/
lisper 9y ago
F# and all ML derivatives are an aberration because they use juxtaposition to denote function calls. That eliminates a lot of parens but personally I find the result less readable. But compare to, say, C where no one complains about the parens: int fact(int n) { if (n==0) { return 1 } else { return n*fact(n-1); } } That's six pairs of parens. The only reason it's not more is because some function calls in C are disguised as operators, and those just happen to be the functions that factorial uses. If we wanted a semantically equivalent function that handled bignums you'd have to write: bignum fact(bignum n) { if (bignum_is_zero(n)) { return n; else { return bignum_multiply(n, fact(bignum_subtract_1(n))); } } Now you've got nine parens. But still no one complains about C because of that.
- brianberns 9y ago
  Only if you assume that curly braces function as parens in C, which isn't true.
  - lisper 9y ago
    It's not an assumption, it's a fact. Curly braces serve the same function in C as (some of the) parens do in Lisp.
- chriswarbo 9y ago
  > F# and all ML derivatives are an aberration because they use juxtaposition to denote function calls. That eliminates a lot of parens but personally I find the result less readable. It makes a lot of sense when all functions are curried. Parenthesised function calls treat all of these as different things: f(a, b, c, d) f(a, b, c)(d) f(a, b)(c, d) f(a, b)(c)(d) f(a)(b, c, d) f(a)(b, c)(d) f(a)(b)(c, d) f(a)(b)(c)(d) If functions aren't curried, then these all mean different things. When functions are curried, all of these have the same semantics (call `f` with `a`, call the result with `b`, call that result with `c` and call that result with `d`); ML's juxtaposition syntax makes these semantically-identical expressions syntactically-identical too: f a b c d
Johnny_Brahms 9y ago
You can replace parens with indentation, yes. There are lisps that do this, like WISP for guile,which provides "implicit parens through indentation". Then you get the same amount of parens as fsharp. It is even standardised as an SRFI (although not widely.implemented)

Roboprog 9y ago

Try putting the closing parens on a line aligned with the opening one, as if they were K&R style closing braces (ignoring that open-paren goes before keyword/func-name, rather than after) (define (fact x) (if (zero? x) 1 (* x (fact (- x 1))) ) ) Square brackets work in some dialects, as well: [define (fact x) (if (zero? x) 1 (* x (fact (- x 1 ]

sigjuice 9y ago
Almost all Lisp code will put the closing parens all together at the end. And the idea is to not care about how many there are by using an editor that provides the appropriate assistance.
- tomjakubowski 9y ago
  > by using an editor that provides the appropriate assistance. To spell it out: this means Emacs with Paredit, or an imitation thereof.
  - krapp 9y ago
    Having to depend on an editor to make your code legible seems like a bad thing.
    - lisper 9y ago
      Why? (And what language do you use where you don't have to rely on the editor to format your code?)
      - krapp 9y ago
        To me, that's a sign that maybe a language has too little syntax. I can read C++, Javascript and PHP just as well in plain text because the other non-paren elements provide necessary contextual cues, along with nesting. Syntax coloring is helpful, but it shouldn't be necessary. I can at least understand nesting closing parens on their own lines, the way Roboprog did above, but throwing all of them on a single line just seems like needless noise.
        KingMob 9y ago
        It's not something we ever really think about. That list of closing parentheses just signals termination of the top-level S-expression. And there's virtually nobody coding in a Lisp that doesn't use a structural editing mode (like Paredit or SmartParens). E.g., any time you type "(", you get "()", enforcing balance. What we rely on is proper indentation to indicate the important groupings.
        sigjuice 9y ago
        Exactly. IMHO, this is quite similar to Python indentation rules, except it is up to writers of Lisp code to be disciplined enough to maintain the proper indentation.
        lisper 9y ago
        No. Our editors auto-indent the code for us. This is one of the reasons Lisp syntax is better than python. Python syntax does not have enough information to auto-indent so it really is up to the programmer. Not so with Lisp.
        9y ago
  - dTal 9y ago
    To any lisp enthusiasts who wonder why the language family isn't more popular: this is 99% of why. You have to use an editor where "copy" is called "Kill-ring-save" is invoked with "Meta-w". Any attempt to use any other tool will be met with incredulous responses to "just use Emacs". It's such a shame because the development environment for Lisp could be so much better than other languages. It could be mindblowingly futuristic, instead of mindblowingly archaic.
    - lispm 9y ago
      > You have to use an editor where "copy" is called "Kill-ring-save" is invoked with "Meta-w" You are misinformed. I'm using a GNU Emacs (-> Aquamacs) on the Mac and cut/paste/copy are invoked with the usual command keys. But usually I use the LispWorks editor, which is also in the Emacs family, and even there cut/copy/paste is the usual command sequence... Both editors are built with excellent Lisp support. One is written in C + Emacs Lisp and the other one in Common Lisp. > mindblowingly archaic You haven't even understood the old part, how would you be able to deal with the futuristic part?
      - fao_ 9y ago
        > You haven't even understood the old part, how would you be able to deal with the futuristic part? "You haven't used a PDP-10, how would you be able to deal with a smartphone?"
        lispm 9y ago
        He didn't talk about old technology like 'smartphones', which existed as products (Nokia Communicator, ...) 20 years ago, but claimed that much better 'futuristic' IDEs for Lisp are possible, though what he claims may currently only exist in his imagination...
    - kazinator 9y ago
      I've been programming in Lisp for 17 years now. I've always done it in Vim.
- tomjakubowski 9y ago
  > by using an editor that provides the appropriate assistance. To spell it out: this means Emacs with Paredit, or an imitation thereof.

Frondo 9y ago

Yeah, you know what else I'm realizing? All the different kinds of punctuation let my eyes skim over different parts of code so easily, and lisp doesn't give me that. You know how, when you're reading natural language, you don't actually read individual letters, not once you have any reading fluency? That's how I read code, too, I'm realizing. When I see the parentheses in C#, my brain just goes "oh that's a method/function call" and I can either skip over the contents of the parens or read them if I need to. Reading comprehension is pretty quick. Looking at all the parens of even that simple lisp factorial, and I realize that I'm feeling a lot of cognitive load that would simply never go away, because the punctuation doesn't let me filter any of it out. I'd have to read everything more carefully.

lisper 9y ago
Focus on the words, not the punctuation, just like you do when reading natural language.
Volt 9y ago
>You know how, when you're reading natural language, you don't actually read individual letters, not once you have any reading fluency? As difficult as it is to imagine, you can indeed achieve fluency in reading Lisp code. Like with everything else, it takes time and practice.
spacemanmatt 9y ago
You get used to reading lisp, the same as you get used to reading all that boilerplate syntax.
shakna 9y ago
> Looking at all the parens of even that simple lisp factorial, and I realize that I'm feeling a lot of cognitive load that would simply never go away, because the punctuation doesn't let me filter any of it out. I'd have to read everything more carefully. Completely the opposite here. Parens means function call or list. Lists usually denoted by a quote first. I don't read the parens, I skim everything, reading words. And the punctuation is really simple. For example: if (number? a) + a b error "Not A Number" a I stripped most of the parens there, (like Wisp [0] does), because I don't really see them. I see function call and arguments, because there isn't anything else. Scheme has the very least syntax out of just about any programming language I've used. It has a tiny cognitive load compared to most. [0] http://dustycloud.org/blog/wisp-lisp-alternative/ http://dustycloud.org/blog/wisp-lisp-alternative/

lisper 9y ago

F# and all ML derivatives are an aberration because they use juxtaposition to denote function calls. That eliminates a lot of parens but personally I find the result less readable. But compare to, say, C where no one complains about the parens: int fact(int n) { if (n==0) { return 1 } else { return n*fact(n-1); } } That's six pairs of parens. The only reason it's not more is because some function calls in C are disguised as operators, and those just happen to be the functions that factorial uses. If we wanted a semantically equivalent function that handled bignums you'd have to write: bignum fact(bignum n) { if (bignum_is_zero(n)) { return n; else { return bignum_multiply(n, fact(bignum_subtract_1(n))); } } Now you've got nine parens. But still no one complains about C because of that.

brianberns 9y ago
Only if you assume that curly braces function as parens in C, which isn't true.
- lisper 9y ago
  It's not an assumption, it's a fact. Curly braces serve the same function in C as (some of the) parens do in Lisp.
chriswarbo 9y ago
> F# and all ML derivatives are an aberration because they use juxtaposition to denote function calls. That eliminates a lot of parens but personally I find the result less readable. It makes a lot of sense when all functions are curried. Parenthesised function calls treat all of these as different things: f(a, b, c, d) f(a, b, c)(d) f(a, b)(c, d) f(a, b)(c)(d) f(a)(b, c, d) f(a)(b, c)(d) f(a)(b)(c, d) f(a)(b)(c)(d) If functions aren't curried, then these all mean different things. When functions are curried, all of these have the same semantics (call `f` with `a`, call the result with `b`, call that result with `c` and call that result with `d`); ML's juxtaposition syntax makes these semantically-identical expressions syntactically-identical too: f a b c d

Johnny_Brahms 9y ago

You can replace parens with indentation, yes. There are lisps that do this, like WISP for guile,which provides "implicit parens through indentation". Then you get the same amount of parens as fsharp. It is even standardised as an SRFI (although not widely.implemented)