People prefer infix with arithmetic operators. Why? Probably because thats what they know. If your example used named functions it would look like this:
Anyway none of this has anything to do with the assertion that people only use explicit state in procedural languages because the languages don't support nesting well. I prefer functional programming to procedural but that doesn't ring true for me at all. As a matter of fact I prefer functional languages that don't have lisp's bracketing syntax.
You are the first person I've ever heard to pronounce < as "ascending". Really, gt/lt functions are my biggest tripover point when doing prefix-everything expressions, because they work in the opposite way of how we were taught as children to interpret them. a<b is true if b is greater than a, and we can evaluate it visually by looking at the expanded side of the operator versus the pinched side of the operator (the former being greater than the latter iff true). In (< a b), the expanded side is pointing at exactly the element which it does not represent, meaning that we can't use those nice optimized mental pathways which are devoted to visually evaluating the expression.
It's logically consistent with how the rest of the system works, but it sucks because having to unlearn anything sucks. Personally, I just imagine it being rewritten as infix.
The "ascending" tip is from experience. It's really easier than moving operators around in your head.
The human mind is good at overloading operators. Especially since the infix < never appears after an open paren, it takes little time to teach yourself to read it as "ascending". It even looks small on the left and big on the right, visualizing an ascending list. Once you learn it that way, shortcuts like (<= 1 n 10) to see if a number is between one and ten come naturally.
True that infix < doesn't appear right after parens, but in the minds of most people, there isn't really a notion of "infix" as an entity unto itself. The alligator just eats the bigger fish.
Really, the problem is that a small amount of whitespace can change the meaning of the code.
(< 1 2) => #t
(<1 2) => #f
...for a convenience function <1 that semantically means "is less than 1". Maybe you wouldn't define such a function, but having to think about it at all or having to mentally redefine < somewhat validates the idea that the syntax here is a stumbling point.
regarding state, see the other example above. then post saying you meant infix math, not state.
edit: and state is not only used to avoid nesting. that is just common. i do it myself in ruby. too much chaining stuff is confusing in ruby, even with OO shortcuts (which are how people actually avoid using the crappy function call syntax too much, even more than via infix math). so you save to a variable and split it up.
Comments
People prefer infix with arithmetic operators. Why? Probably because thats what they know. If your example used named functions it would look like this:
(plus 3 4 (minus 1 (divide 3 4)) (times (minus 9 2) 8 3))
plus(3, 4, minus(1, divide(3, 4)), times(minus(9, 2), 8, 3))
Anyway none of this has anything to do with the assertion that people only use explicit state in procedural languages because the languages don't support nesting well. I prefer functional programming to procedural but that doesn't ring true for me at all. As a matter of fact I prefer functional languages that don't have lisp's bracketing syntax.
Where on earth did you get those function names? Perhaps you meant
Moving the function name outside the parens makes as much sense as moving a verb outside a sentence.P.S. The way to pronounce the < function is "ascending".
You are the first person I've ever heard to pronounce < as "ascending". Really, gt/lt functions are my biggest tripover point when doing prefix-everything expressions, because they work in the opposite way of how we were taught as children to interpret them. a<b is true if b is greater than a, and we can evaluate it visually by looking at the expanded side of the operator versus the pinched side of the operator (the former being greater than the latter iff true). In (< a b), the expanded side is pointing at exactly the element which it does not represent, meaning that we can't use those nice optimized mental pathways which are devoted to visually evaluating the expression.
It's logically consistent with how the rest of the system works, but it sucks because having to unlearn anything sucks. Personally, I just imagine it being rewritten as infix.
I'm a big believe in lifelong unlearning.
The "ascending" tip is from experience. It's really easier than moving operators around in your head.
The human mind is good at overloading operators. Especially since the infix < never appears after an open paren, it takes little time to teach yourself to read it as "ascending". It even looks small on the left and big on the right, visualizing an ascending list. Once you learn it that way, shortcuts like (<= 1 n 10) to see if a number is between one and ten come naturally.
True that infix < doesn't appear right after parens, but in the minds of most people, there isn't really a notion of "infix" as an entity unto itself. The alligator just eats the bigger fish.
Really, the problem is that a small amount of whitespace can change the meaning of the code.
(< 1 2) => #t
(<1 2) => #f
...for a convenience function <1 that semantically means "is less than 1". Maybe you wouldn't define such a function, but having to think about it at all or having to mentally redefine < somewhat validates the idea that the syntax here is a stumbling point.
I do remember stumbling on < early on, but now I don't get it wrong any more often than I do with infix.
you could just rename the operators to lt and gt, so there is no visual cue either way.
you could also change the argument order, but that's probably not a good idea :)
regarding state, see the other example above. then post saying you meant infix math, not state.
edit: and state is not only used to avoid nesting. that is just common. i do it myself in ruby. too much chaining stuff is confusing in ruby, even with OO shortcuts (which are how people actually avoid using the crappy function call syntax too much, even more than via infix math). so you save to a variable and split it up.