3 ms·

What's the difference with pareinfer? https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/ It seems mostly similar, except you hide

What's the difference with pareinfer? https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/ It seems mostly similar, except you hide the parenthesis inference.

breck 7y ago
It's a neat idea, and pareinfer just looks beautiful, but why even infer them at all if you don't need them? My long term plan is to get a lot of resources dedicated to this initiative, and even though I think it's possible you could accomplish the same thing with S-Expressions, I think it's simpler and cheaper by a significant amount to just drop the parens. I think the number of folks who are comfortable with parens (I'd count myself in that category) is a lot smaller than the folks who don't like parens or don't have a preference.
- didibus 7y ago
  I think the advantage is backwards compatibility. I use pareinfer with Clojure and Emacs Lisp for example, though generally I'm more a fan of paredit. I did think of making an Emacs plugin that could hide the parens when using pareinfer. They'd still be in the code, say for others who choose to use a different editing style, but hidden to me. Another aspect for Lisps is that single line code blocks at the REPL are quite useful. Not all shell have good support for multi-line, so being able to inline tree like code does come in handy there. I've also personally found the parens sometimes help with readability, indent can be hard to tell where the block starts and ends sometimes in deep nested scenarios which is more common in immutable expression only languages. Lastly, I'd say copy/pasting can be annoying in whitespace sensitive syntaxes. Pareinfer suffer from this issue as well. But I'm biased, I like the parens and love S-expressions. I'm one of those who started like everyone else hating them, trying to look for alternatives, but one month later of using Clojure at work it all changed, my brain adapted and now I find S-expressions superior in all ways to all other syntaxes I've ever used. I even find myself writing other language with S-expressions by accident. I often put the parenthesis before the method by accident now when going back to Java for example.
  - breck 7y ago
    > Another aspect for Lisps is that single line code blocks at the REPL are quite useful. Not all shell have good support for multi-line, so being able to inline tree like code does come in handy there. This is a really good point. I'm thinking of experimenting with a convention for doing inline trees using Tree Notation. In the code itself the delimiters are called YI (newline) and XI/ZI (space), so potentially could do something like this for the REPL: (set YI="|" ... "def square x|return|* x x " > Lastly, I'd say copy/pasting can be annoying in whitespace sensitive syntaxes. This is true. Things that minimize it in Tree Notation: no ambiguity with spaces/tabs/indent levels--one space is the only way to indent things; great syntax highlighters & automatic suggested fixes (I've got a todo to add autosuggested fix the common case where subsequent lines are de-dented after a paste); and the ubiquity of multi/vertical cursors in editors nowadays. Still, whether I'm using Sublime or VS Code or vim, indent can sometimes be an issue. I think it's just a matter of having all the grunt work done for the modes in these languages to ensure things work as you'd expect. I bet we get that all done by end of year at latest. > my brain adapted and now I find S-expressions superior in all ways to all other syntaxes I've ever used. I think largely the same way, except to me just swap S-Expressions with Tree Notation (which is just SE w/o parens). But that's only because the tooling is getting there now. When I look back at where things were in 2017, wow, Tree Notation was very hard to use back then.

What's the difference with pareinfer? https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/ It seems mostly similar, except you hide the parenthesis inference.

breck 7y ago

It's a neat idea, and pareinfer just looks beautiful, but why even infer them at all if you don't need them? My long term plan is to get a lot of resources dedicated to this initiative, and even though I think it's possible you could accomplish the same thing with S-Expressions, I think it's simpler and cheaper by a significant amount to just drop the parens. I think the number of folks who are comfortable with parens (I'd count myself in that category) is a lot smaller than the folks who don't like parens or don't have a preference.

didibus 7y ago
I think the advantage is backwards compatibility. I use pareinfer with Clojure and Emacs Lisp for example, though generally I'm more a fan of paredit. I did think of making an Emacs plugin that could hide the parens when using pareinfer. They'd still be in the code, say for others who choose to use a different editing style, but hidden to me. Another aspect for Lisps is that single line code blocks at the REPL are quite useful. Not all shell have good support for multi-line, so being able to inline tree like code does come in handy there. I've also personally found the parens sometimes help with readability, indent can be hard to tell where the block starts and ends sometimes in deep nested scenarios which is more common in immutable expression only languages. Lastly, I'd say copy/pasting can be annoying in whitespace sensitive syntaxes. Pareinfer suffer from this issue as well. But I'm biased, I like the parens and love S-expressions. I'm one of those who started like everyone else hating them, trying to look for alternatives, but one month later of using Clojure at work it all changed, my brain adapted and now I find S-expressions superior in all ways to all other syntaxes I've ever used. I even find myself writing other language with S-expressions by accident. I often put the parenthesis before the method by accident now when going back to Java for example.
- breck 7y ago
  > Another aspect for Lisps is that single line code blocks at the REPL are quite useful. Not all shell have good support for multi-line, so being able to inline tree like code does come in handy there. This is a really good point. I'm thinking of experimenting with a convention for doing inline trees using Tree Notation. In the code itself the delimiters are called YI (newline) and XI/ZI (space), so potentially could do something like this for the REPL: (set YI="|" ... "def square x|return|* x x " > Lastly, I'd say copy/pasting can be annoying in whitespace sensitive syntaxes. This is true. Things that minimize it in Tree Notation: no ambiguity with spaces/tabs/indent levels--one space is the only way to indent things; great syntax highlighters & automatic suggested fixes (I've got a todo to add autosuggested fix the common case where subsequent lines are de-dented after a paste); and the ubiquity of multi/vertical cursors in editors nowadays. Still, whether I'm using Sublime or VS Code or vim, indent can sometimes be an issue. I think it's just a matter of having all the grunt work done for the modes in these languages to ensure things work as you'd expect. I bet we get that all done by end of year at latest. > my brain adapted and now I find S-expressions superior in all ways to all other syntaxes I've ever used. I think largely the same way, except to me just swap S-Expressions with Tree Notation (which is just SE w/o parens). But that's only because the tooling is getting there now. When I look back at where things were in 2017, wow, Tree Notation was very hard to use back then.