5 ms·

The point is: Most of the parentheses are superfluous and removing them (in the right way) takes nothing away from the mind-boggling compositional utility.

by singularity2001 7y ago

dreamcompiler 7y ago
Parens are anything but superfluous. Substituting whitespace for parens is a net loss IMO because indentation errors become semantic rather than merely unaesthetic. And elegant composition is impossible with infix notation unless -- you add parens again.
- traderjane 7y ago
  Does the Python community struggle with indentation? I thought it was largely a non-issue.
  - singularity2001 7y ago
    Indentation is an occasional minor annoyance when copy pasting, but otherwise mostly solved by IDEs. In any case very acceptable given the much increased readability and esthetics. I'm not sure if semantic bugs from mixing tabs and spaces are even possible with modern python parsers. if 1: <tab>if 0: <tab><tab>print(1) <spaces*n>print(2) could print 2 if mixing tabs and spaces were allowed. was it ever?
  - thechao 7y ago
    There was a vertical-tab run in ‘13 that really hurt a lot of us; other than that, the Central Space Bank (at least in the US) has kept things fairly stable. (This is ignoring the doom-and-gloom quantitative-tab-easing conspiracy theory nuts.)
- singularity2001 7y ago
  You are possibly right about indentation errors, but the way I understood it, the Readable plugin does not take away any compositional powers. It's just equivalences: f(a b) == (f a b) {a f b} == (f a b) + some edge cases {a b}=(a b) {a}=(a) {}=() etc
- breck 7y ago
  > Substituting whitespace for parens is a net loss IMO because indentation errors become semantic rather than merely unaesthetic. With good tooling this is not a problem. Try the demos here: http://treenotation.org/sandbox/build/ http://treenotation.org/sandbox/build/. Make some indentation errors. It's very hard to ignore all the help the editor gives you. > And elegant composition is impossible with infix notation unless -- you add parens again. This is a valid criticism. I've seen some folks working on this though, and I expect we'll see a new elegant solution.
  - singularity2001 7y ago
    >> And elegant composition is impossible with infix notation unless -- you add parens again. > This is a valid criticism. Is it? What is an example? (One I could think of below seems solvable)
    - breck 7y ago
      Sorry, I actually think you are right and infix notation isn't a problem (Assigning priorities to operators solves many of the cases, for example). I was thinking of "elegant composition" of subexpressions. Or, in other words, inline Trees/S-Expressions.
      - TeMPOraL 7y ago
        Assigning priorities/precedence rules to operators is a problem. It's a hack to work around the paren-less infix notation not being able to fully describe a tree. It introduces complexity in parsing and it imposes mental overhead on programmers. You'll note that most code people write in almost any language is prefix anyway. `foo(bar, baz)` isn't infix; it's prefix with the operator placed to the left of the paren.
        breck 7y ago
        Agreed. Almost all the code I write is prefix notation. I do like to explore infix languages (and even postfix /concatenative languages as well).
- hn_dead_app 7y ago
  How about the opposite direction? Instead of needing parentheses in a language with infix notation, can parentheses be removed in a language with prefix notation (like Lisp)? Is elegant composition possible with prefix notation and some whitespace and indentation instead of parentheses everywhere? I think it might be.
  - singularity2001 7y ago
    That is exactly is the proposal discussed here.
nabla9 7y ago
There is no need to remove them. They are disturbing only people who don't program with Lisp a lot. It's possible to make Emacs to almost hide the parentheses using very low contrasts for "(" and ")" but even that is mostly useless once you are used to them. I parse Lisp similar ways and speed as Python. The indentation in Lisp code is works the the same way. Q: How can you tell when you've reached Lisp Enlightenment? A: The parentheses disappear. –– Anonymous
- singularity2001 7y ago
  They are disturbing only people who don't program with Lisp a lot. Which is about 99.9% of the population. It's good for Lispers that they can ignore braces, but why ignore them when you can just drop them (in many cases), and thereby increase it's chance of mass adaptation. BTW, this post was an outcrop of another article "Why Lisp Failed (2010)" https://news.ycombinator.com/item?id=20374782 https://news.ycombinator.com/item?id=20374782
  - breck 7y ago
    > Which is about 99.9% of the population. Agreed! For decades some people have said parens in S-Expressions are useless. But a key thing we're pushing, that's never been pushed before, is that the parens are worse than useless--they are harmful! They prevent easier program concatenation and ad hoc parser writing. And they make program synthesis, visual programming, and code analysis ~10x harder, for next to no gain. I'm hoping we'll start to turn the tide and bring the 99.9% of the population into the Tree Notation world, and those LISPers that love their parens can remain happily in their (world).
    - dreamcompiler 7y ago
      > But a key thing we're pushing, that's never been pushed before, is that the parens are worse than useless--they are harmful! They prevent easier program concatenation and ad hoc parser writing. And they make program synthesis, visual programming, and code analysis ~10x harder, for next to no gain. Almost everything you've said above is not just untrue, but the opposite of the truth. As such, your statements require supporting evidence. Please cite some. And who, by the way, is "we"?
ken 7y ago
I would hate to try to write a macro for "sweet expressions". The parens show the structure, and the whole point of representing programs as their own literal structure is that it's easy to manipulate. Without that, why am I using Lisp? If I just want a reasonably high-level language but don't care about macros (or other features that rely on seeing the actual structure clearly), why wouldn't I just use Ruby/Python/Smalltalk? They're pretty good, too. I can almost guarantee it's going to be more pleasant, down the road, using one of those languages as it's intended to be used, rather than trying to contort Lisp this way. Getting an answer to a Lisp question on StackOverflow is hard enough with standard syntax. No Lisp programmer is going to want to help with a program written like this.
- singularity2001 7y ago
  There might be situations like macros where the classical notation is easier to read and understand. Sweet expressions are an optional extension of the language so you can just use them in ‘normal' situations

The point is: Most of the parentheses are superfluous and removing them (in the right way) takes nothing away from the mind-boggling compositional utility.

dreamcompiler 7y ago

Parens are anything but superfluous. Substituting whitespace for parens is a net loss IMO because indentation errors become semantic rather than merely unaesthetic. And elegant composition is impossible with infix notation unless -- you add parens again.

traderjane 7y ago
Does the Python community struggle with indentation? I thought it was largely a non-issue.
- singularity2001 7y ago
  Indentation is an occasional minor annoyance when copy pasting, but otherwise mostly solved by IDEs. In any case very acceptable given the much increased readability and esthetics. I'm not sure if semantic bugs from mixing tabs and spaces are even possible with modern python parsers. if 1: <tab>if 0: <tab><tab>print(1) <spaces*n>print(2) could print 2 if mixing tabs and spaces were allowed. was it ever?
- thechao 7y ago
  There was a vertical-tab run in ‘13 that really hurt a lot of us; other than that, the Central Space Bank (at least in the US) has kept things fairly stable. (This is ignoring the doom-and-gloom quantitative-tab-easing conspiracy theory nuts.)
singularity2001 7y ago
You are possibly right about indentation errors, but the way I understood it, the Readable plugin does not take away any compositional powers. It's just equivalences: f(a b) == (f a b) {a f b} == (f a b) + some edge cases {a b}=(a b) {a}=(a) {}=() etc
breck 7y ago
> Substituting whitespace for parens is a net loss IMO because indentation errors become semantic rather than merely unaesthetic. With good tooling this is not a problem. Try the demos here: http://treenotation.org/sandbox/build/ http://treenotation.org/sandbox/build/. Make some indentation errors. It's very hard to ignore all the help the editor gives you. > And elegant composition is impossible with infix notation unless -- you add parens again. This is a valid criticism. I've seen some folks working on this though, and I expect we'll see a new elegant solution.
- singularity2001 7y ago
  >> And elegant composition is impossible with infix notation unless -- you add parens again. > This is a valid criticism. Is it? What is an example? (One I could think of below seems solvable)
  - breck 7y ago
    Sorry, I actually think you are right and infix notation isn't a problem (Assigning priorities to operators solves many of the cases, for example). I was thinking of "elegant composition" of subexpressions. Or, in other words, inline Trees/S-Expressions.
    - TeMPOraL 7y ago
      Assigning priorities/precedence rules to operators is a problem. It's a hack to work around the paren-less infix notation not being able to fully describe a tree. It introduces complexity in parsing and it imposes mental overhead on programmers. You'll note that most code people write in almost any language is prefix anyway. `foo(bar, baz)` isn't infix; it's prefix with the operator placed to the left of the paren.
      - breck 7y ago
        Agreed. Almost all the code I write is prefix notation. I do like to explore infix languages (and even postfix /concatenative languages as well).
hn_dead_app 7y ago
How about the opposite direction? Instead of needing parentheses in a language with infix notation, can parentheses be removed in a language with prefix notation (like Lisp)? Is elegant composition possible with prefix notation and some whitespace and indentation instead of parentheses everywhere? I think it might be.
- singularity2001 7y ago
  That is exactly is the proposal discussed here.

nabla9 7y ago

There is no need to remove them. They are disturbing only people who don't program with Lisp a lot. It's possible to make Emacs to almost hide the parentheses using very low contrasts for "(" and ")" but even that is mostly useless once you are used to them. I parse Lisp similar ways and speed as Python. The indentation in Lisp code is works the the same way. Q: How can you tell when you've reached Lisp Enlightenment? A: The parentheses disappear. –– Anonymous

singularity2001 7y ago
They are disturbing only people who don't program with Lisp a lot. Which is about 99.9% of the population. It's good for Lispers that they can ignore braces, but why ignore them when you can just drop them (in many cases), and thereby increase it's chance of mass adaptation. BTW, this post was an outcrop of another article "Why Lisp Failed (2010)" https://news.ycombinator.com/item?id=20374782 https://news.ycombinator.com/item?id=20374782
- breck 7y ago
  > Which is about 99.9% of the population. Agreed! For decades some people have said parens in S-Expressions are useless. But a key thing we're pushing, that's never been pushed before, is that the parens are worse than useless--they are harmful! They prevent easier program concatenation and ad hoc parser writing. And they make program synthesis, visual programming, and code analysis ~10x harder, for next to no gain. I'm hoping we'll start to turn the tide and bring the 99.9% of the population into the Tree Notation world, and those LISPers that love their parens can remain happily in their (world).
  - dreamcompiler 7y ago
    > But a key thing we're pushing, that's never been pushed before, is that the parens are worse than useless--they are harmful! They prevent easier program concatenation and ad hoc parser writing. And they make program synthesis, visual programming, and code analysis ~10x harder, for next to no gain. Almost everything you've said above is not just untrue, but the opposite of the truth. As such, your statements require supporting evidence. Please cite some. And who, by the way, is "we"?

ken 7y ago

I would hate to try to write a macro for "sweet expressions". The parens show the structure, and the whole point of representing programs as their own literal structure is that it's easy to manipulate. Without that, why am I using Lisp? If I just want a reasonably high-level language but don't care about macros (or other features that rely on seeing the actual structure clearly), why wouldn't I just use Ruby/Python/Smalltalk? They're pretty good, too. I can almost guarantee it's going to be more pleasant, down the road, using one of those languages as it's intended to be used, rather than trying to contort Lisp this way. Getting an answer to a Lisp question on StackOverflow is hard enough with standard syntax. No Lisp programmer is going to want to help with a program written like this.

singularity2001 7y ago
There might be situations like macros where the classical notation is easier to read and understand. Sweet expressions are an optional extension of the language so you can just use them in ‘normal' situations