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.
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.
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).
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.
> 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.
If I have to write 1 + 2 * 5 - 3, I'm not going to "start" with *.
I will type:
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:
(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.