4 ms·

I love prefix-notation for arithmetic, not just because it prevents the need for disambiguating precedence. Subjective, I know, but I think (+ 1 2 3 4) is way

I love prefix-notation for arithmetic, not just because it prevents the need for disambiguating precedence. Subjective, I know, but I think (+ 1 2 3 4) is way nicer than (1 + 2 + 3 + 4).

Zambyte 2y ago
When dealing with pure functions, there is also no ambiguity for f(g(1), h(i(2), 3), j(4)). In both cases, prefix notation removes ambiguity.
johnnyjeans 2y ago
For me, it's concatenative languages. Grammar so simple that BNF is of dubious usage. 4 3 2 1 + + +
whartung 2y ago
My problem with prefix, is simply that my mind does not think in prefix. If I have to write 1 + 2 * 5 - 3, I'm not going to "start" with *. I will type: (+ 1 2<-<-(* ^E 5) <-<-<-<-<-<-<-(- ^E 3)) It indicative of how I'm thinking about it (regardless of how the navigation is done). I just have a lot of those starts and stops when converting infix to prefix in my tiny Piglet brain. That said, as a general rule, yea, I like (+ 1 2 3 4) and its ilk. It takes a bit of exploration to read. For example, I need to transit the entire list of 1 2 3 4 to understand all that is being added, which can be more difficult with longer expressions. But that can be mitigated with formatting: (+ (this that) (func zzz) (if (< v q) 1 3)) (Function conditions are also fun to intermix into things!) I think just as a rule, I find formatting more important in general with s-expr systems than algolesque systems.
- gorjusborg 2y ago
  > If I have to write 1 + 2 * 5 - 3 That's a great example of an expression that can be ambiguous, but not with prefix/suffix notation. Most people that write lisp-like code use an editor that helps with s-exp editing (like paredit), so that isn't really a significant issue. In fact, I think it is faster to write s-exp code than algol-likes once you've become accustomed. I agree that formatting is very important w/ parens langs, but there are many languages that consider formatting a high concern. I would also argue that reading code is harder than writing it. Optimizations that speed up writing code is less interesting to me than ones the help reading/understanding/making assertions easier about code. Finally, infix notation is available in lisp/scheme, it's just a macro away (but seriously, don't).
  - koito17 2y ago
    I find value in ease of "local" modifications to code. My editor being able to indent as soon as I type or paste code is a huge time saver. What's an even bigger time saver is my editor being able to perform tree operations on tree-like data. When using "curly brace languages", what I really miss is structural editing. I often deal with tree-like structures in any language, and being unable to simply cut a node, move my cursor to the start/end of a node, nest something, etc. is really inconvenient. These are operations that take me at most a second when using Emacs with smartparens. In JSX, for example, these one-second operations need me to imitate smartparens' behavior by hand then run Prettier since indenting by hand is an even bigger waste of time. Transforming e.g. <Foo> <Bar> <Baz /> </Bar> </Foo> to <Foo> <Bar /> <Baz /> </Foo> takes *seconds* even though the equivalent operation with S-expressions is a single keybind in Emacs.
- JonChesterfield 2y ago
  Where this happy infix world goes wrong is precedence rules, especially where they're different between different languages. The numerical operators, with the Boolean operators, negation, comparisons, maybe implicit type conversions as well. Maybe && as separate from &. Maybe user defined operators with different precedence to the builtin ones. Maybe the large precedence table you have to keep in working memory to use the infix conventions is still simpler. Maybe even when there's a style guide saying to put lots of parentheses in as well. It starts to be difficult to fit a definition of simple to the observations though.
- eadmund 2y ago
  > My problem with prefix, is simply that my mind does not think in prefix. Mine, neither, for maths. But for everything else, we’re both already used to prefix: fprintf(STDOUT, "foo %d", 3); is prefix, just as much as this is: (format *standard-output* "foo ~d" 3) And it turns out that the advantages of a single homoiconic notation are so compelling that it’s worth a little bit of mild ugliness when dealing with maths.
psychoslave 2y ago
I prefer [1,2,3,4].sum that you can get in ruby out of the box, but `1 2 3 4 sum` would look great too. Now if we want to handle compounded expression, you need either a given constant finite number of argument, or have a reserved word to mark grouping, much like `)`. A bit like stack based programming languages.
agumonkey 2y ago
That's the usual issue, people want their language to be a glorified pocket calculator, so they can type their usual formulas as-is, while lisp rapidly grew a culture of searching for new and larger abstractions. I know some people who would die writing an imperative for loop over an external accumulator rather than (+ nums...) of (fold, +, nums). I keep trying to pin point the psychology of it. Cause even as a kid, I was more attracted toward HP calcs even though I never heard of lisp at this point, but RPL felt like infinite magic. And of course when I ran into emacs, I felt the same strange feeling.. there's something.
- fuzztester 2y ago
  FORTH go PROSPER and

I love prefix-notation for arithmetic, not just because it prevents the need for disambiguating precedence. Subjective, I know, but I think (+ 1 2 3 4) is way nicer than (1 + 2 + 3 + 4).

Zambyte 2y ago

When dealing with pure functions, there is also no ambiguity for f(g(1), h(i(2), 3), j(4)). In both cases, prefix notation removes ambiguity.

johnnyjeans 2y ago

For me, it's concatenative languages. Grammar so simple that BNF is of dubious usage. 4 3 2 1 + + +

whartung 2y ago

My problem with prefix, is simply that my mind does not think in prefix. If I have to write 1 + 2 * 5 - 3, I'm not going to "start" with *. I will type: (+ 1 2<-<-(* ^E 5) <-<-<-<-<-<-<-(- ^E 3)) It indicative of how I'm thinking about it (regardless of how the navigation is done). I just have a lot of those starts and stops when converting infix to prefix in my tiny Piglet brain. That said, as a general rule, yea, I like (+ 1 2 3 4) and its ilk. It takes a bit of exploration to read. For example, I need to transit the entire list of 1 2 3 4 to understand all that is being added, which can be more difficult with longer expressions. But that can be mitigated with formatting: (+ (this that) (func zzz) (if (< v q) 1 3)) (Function conditions are also fun to intermix into things!) I think just as a rule, I find formatting more important in general with s-expr systems than algolesque systems.

gorjusborg 2y ago
> If I have to write 1 + 2 * 5 - 3 That's a great example of an expression that can be ambiguous, but not with prefix/suffix notation. Most people that write lisp-like code use an editor that helps with s-exp editing (like paredit), so that isn't really a significant issue. In fact, I think it is faster to write s-exp code than algol-likes once you've become accustomed. I agree that formatting is very important w/ parens langs, but there are many languages that consider formatting a high concern. I would also argue that reading code is harder than writing it. Optimizations that speed up writing code is less interesting to me than ones the help reading/understanding/making assertions easier about code. Finally, infix notation is available in lisp/scheme, it's just a macro away (but seriously, don't).
- koito17 2y ago
  I find value in ease of "local" modifications to code. My editor being able to indent as soon as I type or paste code is a huge time saver. What's an even bigger time saver is my editor being able to perform tree operations on tree-like data. When using "curly brace languages", what I really miss is structural editing. I often deal with tree-like structures in any language, and being unable to simply cut a node, move my cursor to the start/end of a node, nest something, etc. is really inconvenient. These are operations that take me at most a second when using Emacs with smartparens. In JSX, for example, these one-second operations need me to imitate smartparens' behavior by hand then run Prettier since indenting by hand is an even bigger waste of time. Transforming e.g. <Foo> <Bar> <Baz /> </Bar> </Foo> to <Foo> <Bar /> <Baz /> </Foo> takes *seconds* even though the equivalent operation with S-expressions is a single keybind in Emacs.
JonChesterfield 2y ago
Where this happy infix world goes wrong is precedence rules, especially where they're different between different languages. The numerical operators, with the Boolean operators, negation, comparisons, maybe implicit type conversions as well. Maybe && as separate from &. Maybe user defined operators with different precedence to the builtin ones. Maybe the large precedence table you have to keep in working memory to use the infix conventions is still simpler. Maybe even when there's a style guide saying to put lots of parentheses in as well. It starts to be difficult to fit a definition of simple to the observations though.
eadmund 2y ago
> My problem with prefix, is simply that my mind does not think in prefix. Mine, neither, for maths. But for everything else, we’re both already used to prefix: fprintf(STDOUT, "foo %d", 3); is prefix, just as much as this is: (format *standard-output* "foo ~d" 3) And it turns out that the advantages of a single homoiconic notation are so compelling that it’s worth a little bit of mild ugliness when dealing with maths.

psychoslave 2y ago

I prefer [1,2,3,4].sum that you can get in ruby out of the box, but `1 2 3 4 sum` would look great too. Now if we want to handle compounded expression, you need either a given constant finite number of argument, or have a reserved word to mark grouping, much like `)`. A bit like stack based programming languages.

agumonkey 2y ago

That's the usual issue, people want their language to be a glorified pocket calculator, so they can type their usual formulas as-is, while lisp rapidly grew a culture of searching for new and larger abstractions. I know some people who would die writing an imperative for loop over an external accumulator rather than (+ nums...) of (fold, +, nums). I keep trying to pin point the psychology of it. Cause even as a kid, I was more attracted toward HP calcs even though I never heard of lisp at this point, but RPL felt like infinite magic. And of course when I ran into emacs, I felt the same strange feeling.. there's something.

fuzztester 2y ago
FORTH go PROSPER and