7 ms·

Wish I could have Lisp without all the parentheses. Parentheses just sour the experience for me.

by m0zg 7y ago

97b683f8 7y ago
This probably means your "experience" of lisp was very short.
- m0zg 7y ago
  It admittedly is, just as it is for most other people: there are very few "serious" prorgams I can name that were written in Lisp, in spite of its venerated heritage. There's no shortage of options in the programming language field, so one would be a fool to stick with a language they don't enjoy working in.
dang 7y ago
The parens are the shadow cast by Lisp's consistency, which is the reason to wish for Lisp in the first place. The solution is not to look at the parens. It's a bit like not listening to tinnitus, which is harder for some than for others. Tools help.
- loevborg 7y ago
  > The parens are the shadow cast by Lisp's consistency, which is the reason to wish for Lisp in the first place. Beautiful. I'm stealing that, with your permission?
  - dang 7y ago
    Sure. But you should steal it without permission.
- m0zg 7y ago
  I get that, but I can't help but view them as visual noise.
  - capableweb 7y ago
    On the other hand, other languages use bunch of different characters and they all have different meanings and have to be in different places depending on lots of things. In Lisp, you just have () and they are always in the same place, meaning the same thing.
    - breck 7y ago
      This is a good point, in that Lisp is better than the other languages. But why not go all the way, and drop the parens? If the goal of Bel is to be a "good language", with shorter programs, why oh why not also strive for shorter syntax? I love Lisp and have gotten more good constructive feedback from the Lisp community than anywhere else (with the Haskell community being a close second), but I don't understand why there's only been a dozen or so serious attempts to do Lisp without parens (I-Expressions being the best so far, better than the subsequent Wisp, etc). There should be 1,000x attempts. This should be the top priority of most Lisp researchers. I of course think my Tree Notation is the solution, but I could easily be wrong, and there could be a better way, but the () need to go!
      - capableweb 7y ago
        "why not go all the way, and drop the parens?" because no one found something that is simpler and shorter than just using parens. I-expressions are made up of invisible characters and my feeling is that not a lot of people who write lisp likes any sort of invisibility in their software. For me, using parens is not a deal-breaker, as it's a relatively simple to use for dividing up things. Beats using invisible characters or many different characters.
      - sooheon 7y ago
        At bottom something is necessary to delimit expressions. Going from () to semantic indentation is trading one delimiter for another, isn't it? Not exactly dropping the parens for free.
        breck 7y ago
- breck 7y ago
  <beginExasperation> I don't understand how people who everywhere else love minimalism, refuse to give up the unnecessary parens (whitespace suffices). If the advice is not to look at them, and they are not needed, why have them at all! Every lisp program begins with a syntax error! That doesn't cause alarm bells to go off in people's heads? The commenter above says because parens-less lisp has been tried for 60 years and hasn't caught on it's evidence that it won't work. Sixty years is a blink! Binary notation is 330 years old. Indian numerals about 1,000 years old. Lisp is still in its infancy and things can be improved. </endExasperation> - cranky new lisper
  - krapp 7y ago
    I personally find significant whitespace to be even more annoying than superfluous parens, so no thank you.
    - breck 7y ago
      That’s a good point, without proper tooling it’s a toss up which is better (as in, they are both bad without proper tools).
  - dang 7y ago
    Who said they aren't needed? They are the structure that supports Lisp's simplicity and consistency, which is what the good things come from. If you take them out, it gets complicated and isn't worth it.
    - breck 7y ago
      > Who said they aren't needed? The first good implementation I'm aware of is Egil Möller's from 2003 (https://srfi.schemers.org/srfi-49/srfi-49.html https://srfi.schemers.org/srfi-49/srfi-49.html). My independently researched prediction in 2017 was that no one will ever discover a place where parens or other visible syntax is needed. That sets up an easy proof by contradiction (and I've built a database of over 10k languages so far, looking for a single scenario where you would need them, and haven't found one yet). Here are 19 demo languages covering lots of scenarios demonstrating utility without parens (https://github.com/treenotation/jtree/tree/master/langs https://github.com/treenotation/jtree/tree/master/langs). A glaring hole though, now that I think about it, is that I don't have a good Lisp-like Tree Language. I think a Bel Tree Language would be an excellent example project (and I'm happy to assist anyone who wants to make an attempt, and if no one has the bandwidth and it's not done by next year perhaps I'll find the time to give it a go). > They are the structure that supports Lisp's simplicity and consistency, which is what all the good things come from. I agree with this, but would say they are "one" structure, not "the", and that there are other options (I have one idea in tree notation, but not ruling out that there are more, perhaps better ones). > If you take them out, it gets complicated and isn't worth it. I agree with this, but think there is a future tipping point related to tooling. Tree Notation was quite terrible 2 years ago, but now with type checking, syntax highlighting, autocomplete, I hate to use Lisp and other languages (everything feels unfinished, because I know the syntax characters can be removed). I think we'll hit a tipping point where the tooling for Lisp without parens is good enough that the benefits of dropping them make dropping them a no-brainer. Could I be wrong? Sure, it's a forecast/prediction. But I want to encourage people to invent new alternatives, to try everything under the sun, and not to settle that they are somehow needed. We can make it better.
nabla9 7y ago
Here is old reply from pg to this very complaint. >More than anything else, I think it is the ability of Lisp programs to manipulate Lisp expressions that sets Lisp apart. And so no one who has not written a lot of macros is really in a position to compare Lisp to other languages. When I hear people complain about Lisp's parentheses, it sounds to my ears like someone saying: "I tried one of those bananas, which you say are so delicious. The white part was ok, but the yellow part was very tough and tasted awful." To make this more clear, lets' look at one example of pg's code. In verbatim it looks like this: (mac case (expr . args) (if (no (cdr args)) (car args) (let v (uvar) `(let ,v ,expr (if (= ,v ',(car args)) ,(cadr args) (case ,v ,@(cddr args))))))) For Lisp programmer it looks like this: mac case (expr . args) if no (cdr args) car args let v (uvar) `let ,v ,expr if = ,v ',(car args) ,cadr args case ,v ,(@cddr args) Lisp code relies on indentation for readability. Lisp aware editor knows how to automatically indent the code because it has been explicitly told. Only few of the inner parenthesis convey semantic information to the programmer.
deleted 7y ago
[deleted]
photon-torpedo 7y ago
The Julia language is very lispy at its heart, giving you access to the AST and having "true" macros. The surface syntax however is akin to Python or Matlab. Granted, doing AST manipulations in Julia is more cumbersome than in Lisp, but AFAIK the language creators actually discourage the (over)use of macros, as the resulting mini-languages can make it difficult for outsiders/newcomers to understand or maintain the code.
emmelaich 7y ago
Would you prefer indentations and newlines? https://chrisdone.com/posts/z/ https://chrisdone.com/posts/z/
AlexSolution 7y ago
Using a Lisp with Parinfer makes the parens automagic without taking away the benefits they provide. https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/ https://www.youtube.com/watch?v=K0Tsa3smr1w https://www.youtube.com/watch?v=K0Tsa3smr1w
mythz 7y ago
Here's a Lisp that's whitespace sensitive to avoid parens: http://dustycloud.org/blog/wisp-lisp-alternative/ http://dustycloud.org/blog/wisp-lisp-alternative/ Other techniques to make them less prominent is to use a text face or syntax highlighting to make them less prominent, e.g: https://github.com/tarsius/paren-face/ https://github.com/tarsius/paren-face/ It's not that Lisp has many more parens as that it's simplicity mandates only 1 block structure is used to define s-expressions (lisp's AST), whereas other languages adopt multiple syntaxes for defining their different blocks structures, e.g. () {} [] <>, lisp only uses ().
mikelevins 7y ago
I wished that, too, when I was first learning Lisp. Now, thirty years or so later, I like the parentheses. Lisp did something to me along the way. Syntax has some quality that affects what it feels like to write code. Call it flavor, maybe; or feeling. Lisp feels good to me. It didn't feel good at first, but it gradually won me over. I'm not the only one. Your perspective is valid, but most every Lisp programmer I've met shared it at some point, before Lisp changed their minds. Part of it is that lisp's syntax is simple and regular enough for editors to automate a bunch of simple editing tasks. They indent things for you in a standard way. They can grab whole subexpressions and move them around and transpose them whole and so forth. Most other languages are so syntactically complicated that it's hard to make an editor do that very well. Part of it is that the same simplicity and regularity make it tractable, even easy, to walk, transform, and generate code from Lisp expressions. That characteristic leads to things like this essay linked in another comment: http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.h... Nowadays Lisp expressions feel to me like strings of pearls, each one containing meaning, and each one composed fractally of other pearls of meaning. They are simultaneously structurally sound and malleable. I long ago stopped wanting to get rid of the parentheses. Some time around 1992 or so, Apple acquired a Lisp company named Coral Software and formed a team intended to invent a programming language for its research and development teams. the Advanced Technology Group and other research teams liked Lisp and Smalltalk and similar languages because of how quickly they could build working prototypes with them, but they didn't like the process of converting their successful experiments into Pascal, C, or C++ code. It was too hard, took too long, and lost too many features along the way. They wanted a new language; one that would be as flexible and congenial for experimentation as Lisp and Smalltalk, but that could also ship production code suitable for the more constrained systems that Apple customers mostly had. The Coral group, renamed Apple Cambridge, designed a language called Ralph. It was a Lisp. More specifically, it was Scheme, but built on a runtime and type system based on a subset of CLOS, with some influence from Smalltalk and functional languages, and with system features for cleanly separating the development environment from delivered programs. It was my favorite programming language ever. Eventually, amid some amusing shenanigans, Apple officially renamed it Dylan. Along the way, the Dylan team heard over and over and over from non-Lispers that they wanted a non-Lispy syntax. Initially, the compiler people sort of shrugged and said, "sure, that's easy enough to do." And it is. There's been no shortage of unparenthesized syntaxes designed for Lisp in the roughly sixty years since it was introduced. None of them has ever really caught on (and that should probably tell us something about what a good idea it is, but never mind). Dylan design meetings discussed creating a parser for an "infix syntax". The general idea was to create such a thing to mollify the non-Lispers. I even supported it. My argument was that it was a superficial matter, and if it attracted more users, it would be all to the good. I was wrong. I didn't appreciate just how helpful Lisp syntax is until I got hold of a Lisp that had an infix syntax. It was bulkier and more cumbersome. It was less pleasant to work with. It wasn't as easy to recognize the boundaries of expressions. Editors had a harder time working with it, so they weren't as nimble. Of course, I could always switch back to the parenthesized syntax...until that was removed. Okay, the surface syntax was clunkier, but it was still a Lisp underneath...until it wasn't. The separation between development environment and delivered program got harder and faster. That evolution increasingly restricted what you could accomplish in the repl, until, finally, the repl disappeared altogether. At that point, Dylan really wasn't a Lisp anymore. My favorite Lisp had evolved into just another batch application compiler. Moreover, it didn't work. The stated goal was to make the language more appealing to more working programmers, so that it would gain broader acceptance. It didn't. It lost the things that made Lisp and Smalltalk programmers happy, and it didn't gain broader acceptance in the process. I still like Ralph better than anything else, including Common Lisp, Scheme, Clojure, or Arc. But Ralph is extinct now, so I'll stick with those other Lisps until someone invents a better one. My new favorite will probably have the parentheses.
krapp 7y ago
I'm going to be honest, as a newbie to Lisp, I get it, but you can get get used to them in time.
breck 7y ago
You can! Our work is related: https://treenotation.org/ https://treenotation.org/ It would be straightforward to create a version of Bel that is a Tree Language without parens. I'd be happy to assist.

Wish I could have Lisp without all the parentheses. Parentheses just sour the experience for me.

by m0zg 7y ago

Wish I could have Lisp without all the parentheses. Parentheses just sour the experience for me.

97b683f8 7y ago

This probably means your "experience" of lisp was very short.

m0zg 7y ago
It admittedly is, just as it is for most other people: there are very few "serious" prorgams I can name that were written in Lisp, in spite of its venerated heritage. There's no shortage of options in the programming language field, so one would be a fool to stick with a language they don't enjoy working in.

dang 7y ago

The parens are the shadow cast by Lisp's consistency, which is the reason to wish for Lisp in the first place. The solution is not to look at the parens. It's a bit like not listening to tinnitus, which is harder for some than for others. Tools help.

loevborg 7y ago
> The parens are the shadow cast by Lisp's consistency, which is the reason to wish for Lisp in the first place. Beautiful. I'm stealing that, with your permission?
- dang 7y ago
  Sure. But you should steal it without permission.
m0zg 7y ago
I get that, but I can't help but view them as visual noise.
- capableweb 7y ago
  On the other hand, other languages use bunch of different characters and they all have different meanings and have to be in different places depending on lots of things. In Lisp, you just have () and they are always in the same place, meaning the same thing.
  - breck 7y ago
    This is a good point, in that Lisp is better than the other languages. But why not go all the way, and drop the parens? If the goal of Bel is to be a "good language", with shorter programs, why oh why not also strive for shorter syntax? I love Lisp and have gotten more good constructive feedback from the Lisp community than anywhere else (with the Haskell community being a close second), but I don't understand why there's only been a dozen or so serious attempts to do Lisp without parens (I-Expressions being the best so far, better than the subsequent Wisp, etc). There should be 1,000x attempts. This should be the top priority of most Lisp researchers. I of course think my Tree Notation is the solution, but I could easily be wrong, and there could be a better way, but the () need to go!
    - capableweb 7y ago
      "why not go all the way, and drop the parens?" because no one found something that is simpler and shorter than just using parens. I-expressions are made up of invisible characters and my feeling is that not a lot of people who write lisp likes any sort of invisibility in their software. For me, using parens is not a deal-breaker, as it's a relatively simple to use for dividing up things. Beats using invisible characters or many different characters.
    - sooheon 7y ago
      At bottom something is necessary to delimit expressions. Going from () to semantic indentation is trading one delimiter for another, isn't it? Not exactly dropping the parens for free.
      - breck 7y ago
breck 7y ago
<beginExasperation> I don't understand how people who everywhere else love minimalism, refuse to give up the unnecessary parens (whitespace suffices). If the advice is not to look at them, and they are not needed, why have them at all! Every lisp program begins with a syntax error! That doesn't cause alarm bells to go off in people's heads? The commenter above says because parens-less lisp has been tried for 60 years and hasn't caught on it's evidence that it won't work. Sixty years is a blink! Binary notation is 330 years old. Indian numerals about 1,000 years old. Lisp is still in its infancy and things can be improved. </endExasperation> - cranky new lisper
- krapp 7y ago
  I personally find significant whitespace to be even more annoying than superfluous parens, so no thank you.
  - breck 7y ago
    That’s a good point, without proper tooling it’s a toss up which is better (as in, they are both bad without proper tools).
- dang 7y ago
  Who said they aren't needed? They are the structure that supports Lisp's simplicity and consistency, which is what the good things come from. If you take them out, it gets complicated and isn't worth it.
  - breck 7y ago
    > Who said they aren't needed? The first good implementation I'm aware of is Egil Möller's from 2003 (https://srfi.schemers.org/srfi-49/srfi-49.html https://srfi.schemers.org/srfi-49/srfi-49.html). My independently researched prediction in 2017 was that no one will ever discover a place where parens or other visible syntax is needed. That sets up an easy proof by contradiction (and I've built a database of over 10k languages so far, looking for a single scenario where you would need them, and haven't found one yet). Here are 19 demo languages covering lots of scenarios demonstrating utility without parens (https://github.com/treenotation/jtree/tree/master/langs https://github.com/treenotation/jtree/tree/master/langs). A glaring hole though, now that I think about it, is that I don't have a good Lisp-like Tree Language. I think a Bel Tree Language would be an excellent example project (and I'm happy to assist anyone who wants to make an attempt, and if no one has the bandwidth and it's not done by next year perhaps I'll find the time to give it a go). > They are the structure that supports Lisp's simplicity and consistency, which is what all the good things come from. I agree with this, but would say they are "one" structure, not "the", and that there are other options (I have one idea in tree notation, but not ruling out that there are more, perhaps better ones). > If you take them out, it gets complicated and isn't worth it. I agree with this, but think there is a future tipping point related to tooling. Tree Notation was quite terrible 2 years ago, but now with type checking, syntax highlighting, autocomplete, I hate to use Lisp and other languages (everything feels unfinished, because I know the syntax characters can be removed). I think we'll hit a tipping point where the tooling for Lisp without parens is good enough that the benefits of dropping them make dropping them a no-brainer. Could I be wrong? Sure, it's a forecast/prediction. But I want to encourage people to invent new alternatives, to try everything under the sun, and not to settle that they are somehow needed. We can make it better.

nabla9 7y ago

Here is old reply from pg to this very complaint. >More than anything else, I think it is the ability of Lisp programs to manipulate Lisp expressions that sets Lisp apart. And so no one who has not written a lot of macros is really in a position to compare Lisp to other languages. When I hear people complain about Lisp's parentheses, it sounds to my ears like someone saying: "I tried one of those bananas, which you say are so delicious. The white part was ok, but the yellow part was very tough and tasted awful." To make this more clear, lets' look at one example of pg's code. In verbatim it looks like this: (mac case (expr . args) (if (no (cdr args)) (car args) (let v (uvar) `(let ,v ,expr (if (= ,v ',(car args)) ,(cadr args) (case ,v ,@(cddr args))))))) For Lisp programmer it looks like this: mac case (expr . args) if no (cdr args) car args let v (uvar) `let ,v ,expr if = ,v ',(car args) ,cadr args case ,v ,(@cddr args) Lisp code relies on indentation for readability. Lisp aware editor knows how to automatically indent the code because it has been explicitly told. Only few of the inner parenthesis convey semantic information to the programmer.

deleted 7y ago

[deleted]

photon-torpedo 7y ago

The Julia language is very lispy at its heart, giving you access to the AST and having "true" macros. The surface syntax however is akin to Python or Matlab. Granted, doing AST manipulations in Julia is more cumbersome than in Lisp, but AFAIK the language creators actually discourage the (over)use of macros, as the resulting mini-languages can make it difficult for outsiders/newcomers to understand or maintain the code.

emmelaich 7y ago

Would you prefer indentations and newlines? https://chrisdone.com/posts/z/ https://chrisdone.com/posts/z/

AlexSolution 7y ago

Using a Lisp with Parinfer makes the parens automagic without taking away the benefits they provide. https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/ https://www.youtube.com/watch?v=K0Tsa3smr1w https://www.youtube.com/watch?v=K0Tsa3smr1w

mythz 7y ago

Here's a Lisp that's whitespace sensitive to avoid parens: http://dustycloud.org/blog/wisp-lisp-alternative/ http://dustycloud.org/blog/wisp-lisp-alternative/ Other techniques to make them less prominent is to use a text face or syntax highlighting to make them less prominent, e.g: https://github.com/tarsius/paren-face/ https://github.com/tarsius/paren-face/ It's not that Lisp has many more parens as that it's simplicity mandates only 1 block structure is used to define s-expressions (lisp's AST), whereas other languages adopt multiple syntaxes for defining their different blocks structures, e.g. () {} [] <>, lisp only uses ().

mikelevins 7y ago

I wished that, too, when I was first learning Lisp. Now, thirty years or so later, I like the parentheses. Lisp did something to me along the way. Syntax has some quality that affects what it feels like to write code. Call it flavor, maybe; or feeling. Lisp feels good to me. It didn't feel good at first, but it gradually won me over. I'm not the only one. Your perspective is valid, but most every Lisp programmer I've met shared it at some point, before Lisp changed their minds. Part of it is that lisp's syntax is simple and regular enough for editors to automate a bunch of simple editing tasks. They indent things for you in a standard way. They can grab whole subexpressions and move them around and transpose them whole and so forth. Most other languages are so syntactically complicated that it's hard to make an editor do that very well. Part of it is that the same simplicity and regularity make it tractable, even easy, to walk, transform, and generate code from Lisp expressions. That characteristic leads to things like this essay linked in another comment: http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.html http://lists.warhead.org.uk/pipermail/iwe/2005-July/000130.h... Nowadays Lisp expressions feel to me like strings of pearls, each one containing meaning, and each one composed fractally of other pearls of meaning. They are simultaneously structurally sound and malleable. I long ago stopped wanting to get rid of the parentheses. Some time around 1992 or so, Apple acquired a Lisp company named Coral Software and formed a team intended to invent a programming language for its research and development teams. the Advanced Technology Group and other research teams liked Lisp and Smalltalk and similar languages because of how quickly they could build working prototypes with them, but they didn't like the process of converting their successful experiments into Pascal, C, or C++ code. It was too hard, took too long, and lost too many features along the way. They wanted a new language; one that would be as flexible and congenial for experimentation as Lisp and Smalltalk, but that could also ship production code suitable for the more constrained systems that Apple customers mostly had. The Coral group, renamed Apple Cambridge, designed a language called Ralph. It was a Lisp. More specifically, it was Scheme, but built on a runtime and type system based on a subset of CLOS, with some influence from Smalltalk and functional languages, and with system features for cleanly separating the development environment from delivered programs. It was my favorite programming language ever. Eventually, amid some amusing shenanigans, Apple officially renamed it Dylan. Along the way, the Dylan team heard over and over and over from non-Lispers that they wanted a non-Lispy syntax. Initially, the compiler people sort of shrugged and said, "sure, that's easy enough to do." And it is. There's been no shortage of unparenthesized syntaxes designed for Lisp in the roughly sixty years since it was introduced. None of them has ever really caught on (and that should probably tell us something about what a good idea it is, but never mind). Dylan design meetings discussed creating a parser for an "infix syntax". The general idea was to create such a thing to mollify the non-Lispers. I even supported it. My argument was that it was a superficial matter, and if it attracted more users, it would be all to the good. I was wrong. I didn't appreciate just how helpful Lisp syntax is until I got hold of a Lisp that had an infix syntax. It was bulkier and more cumbersome. It was less pleasant to work with. It wasn't as easy to recognize the boundaries of expressions. Editors had a harder time working with it, so they weren't as nimble. Of course, I could always switch back to the parenthesized syntax...until that was removed. Okay, the surface syntax was clunkier, but it was still a Lisp underneath...until it wasn't. The separation between development environment and delivered program got harder and faster. That evolution increasingly restricted what you could accomplish in the repl, until, finally, the repl disappeared altogether. At that point, Dylan really wasn't a Lisp anymore. My favorite Lisp had evolved into just another batch application compiler. Moreover, it didn't work. The stated goal was to make the language more appealing to more working programmers, so that it would gain broader acceptance. It didn't. It lost the things that made Lisp and Smalltalk programmers happy, and it didn't gain broader acceptance in the process. I still like Ralph better than anything else, including Common Lisp, Scheme, Clojure, or Arc. But Ralph is extinct now, so I'll stick with those other Lisps until someone invents a better one. My new favorite will probably have the parentheses.

krapp 7y ago

I'm going to be honest, as a newbie to Lisp, I get it, but you can get get used to them in time.

breck 7y ago

You can! Our work is related: https://treenotation.org/ https://treenotation.org/ It would be straightforward to create a version of Bel that is a Tree Language without parens. I'd be happy to assist.