8 ms·

Add "SweetExpressions" and I wonder how far from coffeescript it would get. "SweetExpressions" is probably the best method so far to get rid of excessive paren

Add "SweetExpressions" and I wonder how far from coffeescript it would get. "SweetExpressions" is probably the best method so far to get rid of excessive parentheses in lisp. See http://readable.sourceforge.net/ http://readable.sourceforge.net/

timcameronryan 14y ago
I experimented with a CoffeeScript-like Lisp in JavaScript once. It's pretty opinionated, but provides interesting syntax possibilities (infix notation, non-significant parentheses and commas for clarity, JSON-compatible syntax): https://github.com/tcr/syrup https://github.com/tcr/syrup range = fn: [i] loop: [i, r = []] if: (i == 0) r continue: (i - 1), concat: (i - 1), r print: range: 5 # [0, 1, 2, 3, 4]
lowboy 14y ago
I was just coming here to wonder at the need for those chubby little lines with their quadruple chins. Seems like if you have blocks of regular indention you should be able to trim some of the fat. I'm not a lisp guy though, so I'm sure that sentiment is naive.
Homunculiheaded 14y ago
As someone who has done a fair bit of lisp hacking I'll never really understand the paren-hate. Yes it's weird the first few times but I have never met anyone who has coded a significant amount of lisp who sees them as anything but an asset. In lisp you're essentially hacking at the AST level, this is precisely where a huge chunk of lisp's power comes from, and parens are an incredibly natural and concise way to express this structure. I have also written a lot of Python and I can honestly say significant white space as been an issue for me far more often than parens in Lisp (and I don't find significant white space to be an issue at all).
- wes-exp 14y ago
  I've coded a significant amount of lisp, and I agree the parentheses are completely an asset.
- rtfeldman 14y ago
  Sadly, the vast majority of coders never make it to "a significant amount of Lisp". Most who do tend to be very positive about Lisp, so it's not that the language veterans give it a bad word-of-mouth reputation. Quite the opposite. There is clearly an "approachability problem" to Lisp, and it seems worth trying to solve. (If nothing else, the more popular a language gets, the more opportunities you will have to get paid to write in it for a living.) Parens come up every single time the word Lisp is mentioned in "mixed company"--that is, both Lispers and non-Lispers. It's not just the most common complaint about the language, but the dominant complaint. (Thought experiment: What's the #2 complaint newbies make about Lisp? And how much longer did it take you to answer that question than #1?) Originally John McCarthy had intended to use M-Expressions for Lisp, e.g. "car[cons[(A . B); x]]", but programmers preferred the parens-and-whitespace of S-Expressions instead, so they became the default. There's no reason to dismiss the possibility of another such evolution, again based on nothing more than programmer preference. No matter how familiar or useful you might find the existing approach, it's always possible that it can be improved.
  - ScottBurson 14y ago
    There have been many attempts to solve the approachability problem by creating alternate syntaxes. Vaughan Pratt's CGOL, written almost 40 years ago, was perhaps one of the best. Although these alternate syntaxes may be helpful to newcomers, they have never caught on. Expert users actually prefer the parenthesized form; so anyone working in Lisp for very long has to learn to deal with it -- and usually, once they do, they find it preferable. You said it yourself: programmers preferred S-expressions, so they became the default. The other important point here is that the non-Lispers are right, in a sense: editing Lisp without a paren-counting editor is just as tedious as one would expect. But with a paren-counting editor -- and even better, with something like Paredit that keeps the parens balanced at all times -- editing actually becomes easier, more fluid, and more pleasant than in other languages. That is why expert Lisp users prefer the parens.
    - erichocean 14y ago
      editing Lisp without a paren-counting editor is just as tedious as one would expect That's the real barrier, IMO. Who wants to switch editors just to learn a new language with an (apparently) impoverished syntax?
- lowboy 14y ago
  I appreciate the need to have parens to remove ambiguity and for something like an AST it is a very concise expression. It just seems like there are common patterns that could be abstracted out, such as the code at the bottom of this lispyscript example[0]. Every new line gets a open paren, LF + tab indicates another open paren on next line, otherwise LF is a closed paren. Again, I'm not a lisp guy (could you tell?) and maybe this is just because it's a js variant and not pure lisp code. I appreciate when languages don't make me insert/edit/move over/count/deal with/etc. more characters than necessary. Maybe there's a good vim setup to do that already - that would go a long way to alleviate my concerns. [0]: https://github.com/santoshrajan/lispyscript/blob/master/examples/twitter.ls https://github.com/santoshrajan/lispyscript/blob/master/exam...
  - wonderzombie 14y ago
    Abstract out how? For instance, this is valid code: (if (empty? x) foo bar) edit: lolz. failed at example. fixed. foo is the result of if x is empty, and you can tell it is not a function call because it has no parens. Whitespace is merely a style consideration, as it is in C++ or Java. There are ways to save time/trouble within the language. For instance, in Clojure (foo (bar (baz (quux x)))) can be rewritten as ((comp foo bar baz quux) x) There's also stuff like apply, ->, and ->> in Clojure, which have similar purposes (flattening out the nesting a bit). And for anything particularly syntactically onerous, you can always add sugar with macros. Ultimately syntax is more about ease than it is about power or simplicity. I think it's worthwhile to try to look beyond that into what the code is saying rather than how it's saying it. You have to do this anytime you learn a significantly different language anyway, right?
    - lowboy 14y ago
      True, and to me the ease of use increases by getting rid of what I perceive to be superfluous parens. I'd rather write the first code block and have mean the same as the second. This is a trivial example, but when LF + indentation become significant it eases deep nesting. Ideal: if (empty? x) foo bar Less ideal: (if (empty? x) foo bar) The clojure comp shortcut looks good to me, but why even need the outside parens if it was the only line in that block? (comp foo bar baz quux) x Ideally, that should be valid as well. I know this kind of reduction won't work in a lot of cases, but I appreciate syntax sugaring like this where I can get it.
- zem 14y ago
  well, read some ML or Haskell code to see how much more pleasant it looks than the equivalent lisp code. i don't hate parentheses per se; i just think you miss out on a lot when they're your only syntactic construct. (of course, as you point out, you gain a lot too, but that is orthogonal to the basic experience of reading and writing code)
  - wes-exp 14y ago
    Considering the "readable" example: (define (factorial n) (if (<= n 1) 1 (* n (factorial (- n 1))))) define factorial(n) if {n <= 1} 1 {n * factorial{n - 1}} The first one looks more pleasant to me. The second one looks broken and disorganized. My brain can't parse it as easily without the visual cues provided by the parens. Of course, it looks better to me because I'm used to lisp. When I first saw lisp I thought the syntax was nuts. Point being - what looks "good" can simply be a matter of what you're used to.
    - zem 14y ago
      pseudo-ml factorial n = case | n <= 1 -> 1 | else -> n * factorial (n - 1) i can see what's going on at a glance - the syntax and layout of the code are a positive help to understanding it.
      - saurik 14y ago
        You changed the structure, though, to use something much closer to a cond instead of an if. Also, there are variants that require fewer ()s for this. clisp: (defun factorial (n) (cond ((<= n 1) 1) (T (* n (factorial (- n 1)))))) Clojure (which I believe is similar to Ark with respect to not using extra parentheses around cond clauses, but I don't have Ark setup to verify that that's actually the case and then to test my demonstration with, so I'm going to do it with Clojure, despite the "weird" [] syntax, as it is orthogonal to the demonstration): (defn factorial [n] (cond (<= n 1) 1 :else (* n (factorial (dec n)))))
        14y ago
- wonderzombie 14y ago
  People don't like what's unfamiliar and a lot of parens are unfamiliar. That's mostly OK with me; people need to evaluate what they think is worth their time. But typically this evaluation manifests as a gripe about syntax. Syntax does matter but not nearly as much as we like to talk about it! Myself, I only picked up Clojure a couple of weeks ago, give or take. I don't use it at work so this is in my spare time (which seems ever more shrinking). Parens aren't a big deal, and it's kind of crazy we spend this much time talking about them instead of something more significant. (Hell, maybe people just enjoy trolling.) Omit all indentation in Java or C++ and you'll be doing the bracket-counting that you assume Lispers spend their time doing.
sedachv 14y ago
If you're looking at parentheses instead of using indentation effectively and looking at the first thing in the list you haven't learned how to read Lisp code yet. People look at Lisp and think that because of the parentheses they don't have to bother thinking about the typographic layout of the code like they do in C, so their code ends up with shitty formatting and they think it's because of the parentheses, when in reality it is because they didn't bother formatting it. Getting rid of parentheses means you cannot use structured editing tools like Paredit anymore (http://emacswiki.org/emacs/ParEdit http://emacswiki.org/emacs/ParEdit). You can't appreciate how slow and clumsy it is to edit code in other languages until you've been using Paredit for a while. One sometimes valid argument against prefix notation is for expressions primarily involving binary math operations (+ * - / etc.). In some cases it's true, in other cases the Lisp code looks gnarly because people try to write the formula out without introducing intermediate variables. There's macros out there that will parse infix arithmetic (http://cliki.net/Infix http://cliki.net/Infix); I've never used them so I can't comment on whether they improve code readability or not.
- lowboy 14y ago
  I don't see how the lack of (IMO) optional parens would prevent tools from working - they'd just have to be adjusted. Assuming this example from the ParEdit page is well-formed lisp: (defun paredit-barf-all-the-way-forward () (interactive) (paredit-split-sexp) (paredit-forward-down) (paredit-splice-sexp) (if (eolp) (delete-horizontal-space))) It doesn't seem that hard to rework a tool to use sig whitespace as indicating parens to have it operate the same over this code: defun paredit-barf-all-the-way-forward () interactive paredit-split-sexp paredit-forward-down paredit-splice-sexp if (eolp) (delete-horizontal-space)

timcameronryan 14y ago

I experimented with a CoffeeScript-like Lisp in JavaScript once. It's pretty opinionated, but provides interesting syntax possibilities (infix notation, non-significant parentheses and commas for clarity, JSON-compatible syntax): https://github.com/tcr/syrup https://github.com/tcr/syrup range = fn: [i] loop: [i, r = []] if: (i == 0) r continue: (i - 1), concat: (i - 1), r print: range: 5 # [0, 1, 2, 3, 4]

lowboy 14y ago

I was just coming here to wonder at the need for those chubby little lines with their quadruple chins. Seems like if you have blocks of regular indention you should be able to trim some of the fat. I'm not a lisp guy though, so I'm sure that sentiment is naive.

Homunculiheaded 14y ago

As someone who has done a fair bit of lisp hacking I'll never really understand the paren-hate. Yes it's weird the first few times but I have never met anyone who has coded a significant amount of lisp who sees them as anything but an asset. In lisp you're essentially hacking at the AST level, this is precisely where a huge chunk of lisp's power comes from, and parens are an incredibly natural and concise way to express this structure. I have also written a lot of Python and I can honestly say significant white space as been an issue for me far more often than parens in Lisp (and I don't find significant white space to be an issue at all).

wes-exp 14y ago
I've coded a significant amount of lisp, and I agree the parentheses are completely an asset.
rtfeldman 14y ago
Sadly, the vast majority of coders never make it to "a significant amount of Lisp". Most who do tend to be very positive about Lisp, so it's not that the language veterans give it a bad word-of-mouth reputation. Quite the opposite. There is clearly an "approachability problem" to Lisp, and it seems worth trying to solve. (If nothing else, the more popular a language gets, the more opportunities you will have to get paid to write in it for a living.) Parens come up every single time the word Lisp is mentioned in "mixed company"--that is, both Lispers and non-Lispers. It's not just the most common complaint about the language, but the dominant complaint. (Thought experiment: What's the #2 complaint newbies make about Lisp? And how much longer did it take you to answer that question than #1?) Originally John McCarthy had intended to use M-Expressions for Lisp, e.g. "car[cons[(A . B); x]]", but programmers preferred the parens-and-whitespace of S-Expressions instead, so they became the default. There's no reason to dismiss the possibility of another such evolution, again based on nothing more than programmer preference. No matter how familiar or useful you might find the existing approach, it's always possible that it can be improved.
- ScottBurson 14y ago
  There have been many attempts to solve the approachability problem by creating alternate syntaxes. Vaughan Pratt's CGOL, written almost 40 years ago, was perhaps one of the best. Although these alternate syntaxes may be helpful to newcomers, they have never caught on. Expert users actually prefer the parenthesized form; so anyone working in Lisp for very long has to learn to deal with it -- and usually, once they do, they find it preferable. You said it yourself: programmers preferred S-expressions, so they became the default. The other important point here is that the non-Lispers are right, in a sense: editing Lisp without a paren-counting editor is just as tedious as one would expect. But with a paren-counting editor -- and even better, with something like Paredit that keeps the parens balanced at all times -- editing actually becomes easier, more fluid, and more pleasant than in other languages. That is why expert Lisp users prefer the parens.
  - erichocean 14y ago
    editing Lisp without a paren-counting editor is just as tedious as one would expect That's the real barrier, IMO. Who wants to switch editors just to learn a new language with an (apparently) impoverished syntax?
lowboy 14y ago
I appreciate the need to have parens to remove ambiguity and for something like an AST it is a very concise expression. It just seems like there are common patterns that could be abstracted out, such as the code at the bottom of this lispyscript example[0]. Every new line gets a open paren, LF + tab indicates another open paren on next line, otherwise LF is a closed paren. Again, I'm not a lisp guy (could you tell?) and maybe this is just because it's a js variant and not pure lisp code. I appreciate when languages don't make me insert/edit/move over/count/deal with/etc. more characters than necessary. Maybe there's a good vim setup to do that already - that would go a long way to alleviate my concerns. [0]: https://github.com/santoshrajan/lispyscript/blob/master/examples/twitter.ls https://github.com/santoshrajan/lispyscript/blob/master/exam...
- wonderzombie 14y ago
  Abstract out how? For instance, this is valid code: (if (empty? x) foo bar) edit: lolz. failed at example. fixed. foo is the result of if x is empty, and you can tell it is not a function call because it has no parens. Whitespace is merely a style consideration, as it is in C++ or Java. There are ways to save time/trouble within the language. For instance, in Clojure (foo (bar (baz (quux x)))) can be rewritten as ((comp foo bar baz quux) x) There's also stuff like apply, ->, and ->> in Clojure, which have similar purposes (flattening out the nesting a bit). And for anything particularly syntactically onerous, you can always add sugar with macros. Ultimately syntax is more about ease than it is about power or simplicity. I think it's worthwhile to try to look beyond that into what the code is saying rather than how it's saying it. You have to do this anytime you learn a significantly different language anyway, right?
  - lowboy 14y ago
    True, and to me the ease of use increases by getting rid of what I perceive to be superfluous parens. I'd rather write the first code block and have mean the same as the second. This is a trivial example, but when LF + indentation become significant it eases deep nesting. Ideal: if (empty? x) foo bar Less ideal: (if (empty? x) foo bar) The clojure comp shortcut looks good to me, but why even need the outside parens if it was the only line in that block? (comp foo bar baz quux) x Ideally, that should be valid as well. I know this kind of reduction won't work in a lot of cases, but I appreciate syntax sugaring like this where I can get it.
zem 14y ago
well, read some ML or Haskell code to see how much more pleasant it looks than the equivalent lisp code. i don't hate parentheses per se; i just think you miss out on a lot when they're your only syntactic construct. (of course, as you point out, you gain a lot too, but that is orthogonal to the basic experience of reading and writing code)
- wes-exp 14y ago
  Considering the "readable" example: (define (factorial n) (if (<= n 1) 1 (* n (factorial (- n 1))))) define factorial(n) if {n <= 1} 1 {n * factorial{n - 1}} The first one looks more pleasant to me. The second one looks broken and disorganized. My brain can't parse it as easily without the visual cues provided by the parens. Of course, it looks better to me because I'm used to lisp. When I first saw lisp I thought the syntax was nuts. Point being - what looks "good" can simply be a matter of what you're used to.
  - zem 14y ago
    pseudo-ml factorial n = case | n <= 1 -> 1 | else -> n * factorial (n - 1) i can see what's going on at a glance - the syntax and layout of the code are a positive help to understanding it.
    - saurik 14y ago
      You changed the structure, though, to use something much closer to a cond instead of an if. Also, there are variants that require fewer ()s for this. clisp: (defun factorial (n) (cond ((<= n 1) 1) (T (* n (factorial (- n 1)))))) Clojure (which I believe is similar to Ark with respect to not using extra parentheses around cond clauses, but I don't have Ark setup to verify that that's actually the case and then to test my demonstration with, so I'm going to do it with Clojure, despite the "weird" [] syntax, as it is orthogonal to the demonstration): (defn factorial [n] (cond (<= n 1) 1 :else (* n (factorial (dec n)))))
      - 14y ago
wonderzombie 14y ago
People don't like what's unfamiliar and a lot of parens are unfamiliar. That's mostly OK with me; people need to evaluate what they think is worth their time. But typically this evaluation manifests as a gripe about syntax. Syntax does matter but not nearly as much as we like to talk about it! Myself, I only picked up Clojure a couple of weeks ago, give or take. I don't use it at work so this is in my spare time (which seems ever more shrinking). Parens aren't a big deal, and it's kind of crazy we spend this much time talking about them instead of something more significant. (Hell, maybe people just enjoy trolling.) Omit all indentation in Java or C++ and you'll be doing the bracket-counting that you assume Lispers spend their time doing.

sedachv 14y ago

If you're looking at parentheses instead of using indentation effectively and looking at the first thing in the list you haven't learned how to read Lisp code yet. People look at Lisp and think that because of the parentheses they don't have to bother thinking about the typographic layout of the code like they do in C, so their code ends up with shitty formatting and they think it's because of the parentheses, when in reality it is because they didn't bother formatting it. Getting rid of parentheses means you cannot use structured editing tools like Paredit anymore (http://emacswiki.org/emacs/ParEdit http://emacswiki.org/emacs/ParEdit). You can't appreciate how slow and clumsy it is to edit code in other languages until you've been using Paredit for a while. One sometimes valid argument against prefix notation is for expressions primarily involving binary math operations (+ * - / etc.). In some cases it's true, in other cases the Lisp code looks gnarly because people try to write the formula out without introducing intermediate variables. There's macros out there that will parse infix arithmetic (http://cliki.net/Infix http://cliki.net/Infix); I've never used them so I can't comment on whether they improve code readability or not.

lowboy 14y ago
I don't see how the lack of (IMO) optional parens would prevent tools from working - they'd just have to be adjusted. Assuming this example from the ParEdit page is well-formed lisp: (defun paredit-barf-all-the-way-forward () (interactive) (paredit-split-sexp) (paredit-forward-down) (paredit-splice-sexp) (if (eolp) (delete-horizontal-space))) It doesn't seem that hard to rework a tool to use sig whitespace as indicating parens to have it operate the same over this code: defun paredit-barf-all-the-way-forward () interactive paredit-split-sexp paredit-forward-down paredit-splice-sexp if (eolp) (delete-horizontal-space)