> people know the rules for maths, and Python's function call notation is the same, so it's familiar and unambiguous to outsiders Personally I'm really not a f

> people know the rules for maths, and Python's function call notation is the same, so it's familiar and unambiguous to outsiders Personally I'm really not a fan of relying on operator precedence. Even in that Python example I would write it `(5 - 4) - 1` to disambiguate. I have a few issues: - Firstly, parsing combinations with varying precedence is something that computers are good at but people not so much, so I see no reason to force readers to juggle this sort of stuff. - Second, mathematical precedence rules are overly complicated. Trying to support them can make a language overly complicated. Languages like Smalltalk prefer to remain simple, even if that "breaks" standard mathematical expressions https://en.wikipedia.org/wiki/Smalltalk#Expressions https://en.wikipedia.org/wiki/Smalltalk#Expressions - Finally, arithmetic is a tiny part of a programming language. There's no "standard" way to extend operator precedence to include, say, 3D rendering operations, or parser combinators, or attaching event handlers, etc. All we can do is give each operator a number, at which point we're just exacerbating the "humans aren't good at precedence tables" problem. This has also been discussed elsewhere, e.g. at http://wiki.c2.com/?OperatorPrecedenceConsideredHarmful http://wiki.c2.com/?OperatorPrecedenceConsideredHarmful PS: I prefer the `f a b c` function call syntax to `f(a, b, c)`, but prefer s-expressions to both. Scheme is really nice, but I don't want to live without currying and laziness by default. I have high hopes for https://lexi-lambda.github.io/hackett https://lexi-lambda.github.io/hackett :)