I note that infix was so natural that you resorted to parens.
Infix looks reasonable until one has more than 2 operators. Then people start making mistakes. To combat those mistakes, they start parenthesizing. The number of mistakes goes down but there's still confusion. (Some folks know more precedence levels than others and many folks think that they know precedence levels that they don't know.)
Another way to put that is that Lisp is so natural it resorts to forcing parens everywhere even when I don't want them! I'd never deny that confusion about order of operations between &, |, ==, <<, %, and so on, is a major source of bugs. (But I'd blame poor coding style for that, in any language, in the first place.)
However, in every field besides this niche of computer science, including almost all of math, finance, science, and engineering, infix is used. This means that it is at least good enough and I suspect it has advantages.
Many math operations really are just fundamentally unary or binary. Generalizing - or / or x^y or mod to lists is just silly as far as I can see, and adds confusion. I don't need to see parens around the outermost operation. For the two most common associative operations, + and *, order of operations is quite good enough and it has the advantage that everyone since grade 6 has been working with it.
(I'll give you that there are very many cases where list notation is great, but I don't think it's common that they help very much in science, business, or engineering.)
> However, in every field besides this niche of computer science, including almost all of math, finance, science, and engineering, infix is used.
The reason is that the "reader" in all of those domains is another human and humans do error correction almost without thinking.
Also, each of those domains has a very small number of operators - programming languages have lots of operators.
Feel free to demonstrate that you know the precedence/associativity rules for your favorite programming language by typing them without looking them up. (I know two people who can do that for C; the vast majority can't.)
I'm only trying to defend a very narrow point, that when coding mathematical expressions, infix isn't bad.
Code is read by human beings too (perhaps just the person who wrote it) and more find infix arithmetic more natural looking.
I see the appeal in the idea that arithmetic is really just a very special case of a programming structure and should be treated as such, but on the other hand, I and many others can instantly see what a + bc/d - d(e+f)*g means and would like equation-heavy pieces of my programs to somewhat resemble equations everywhere else in life.
Does you have the quadratic formula memorized in list notation? How about the sum of an arithmetic or geometric series, or a formula for an inverse square law force?
> I'm only trying to defend a very narrow point, that when coding mathematical expressions, infix isn't bad.
Programming isn't math.
> Code is read by human beings too (perhaps just the person who wrote it) and more find infix arithmetic more natural looking.
And that's how infix causes bugs. The human reader error corrects and the compiler doesn't.
My goal is correct programs. What's yours?
Lisp notation eliminates a whole class of bugs.
Bugs are expensive - what are you getting for the ability to have more of them?
> I and many others can instantly see what a + bc/d - d(e+f)*g means
Really? It has at least two meanings. Which one is correct?
Yes, I do memorize formulas in a form that doesn't allow for precedence/associativity errors. Why I should prefer a form that does allow for such errors?
Programming isn't math, but mathematical expressions are often found in programs, more or less so depending on the domain. My preference is to have readable mathematical expressions in programs that resemble the forms in which I see or use them elsewhere.
In the general case of complex logical and bitwise expressions, order of operations can cause a tremendous number of bugs. I like to use parentheses to make these cases absolutely unambiguous anyway. But I can't remember introducing a serious bug because I messed up order of operations between +- and X. Anyway, if it's such a problem, there's nothing to say you can't put parentheses around every operation in infix notation, at least in any language that I know of!
Maybe my preference relates to having a fairly visual memory for formulas and such. If I want to find a root of a quadratic equation, I do (-b + sqrt(b * b - 4 * a * c))/(2 * a), and that is easy, and anyone with high school math sees that in someone's code they know what it is. (I probably have to check for a zero denominator and also look at the discriminant unless I'm directly using complex numbers, and there's also the conjugate root, but that doesn't change much.)
If I have to write (/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a)) then I can do it, but it takes a lot of thought and it doesn't go along with the way I think about the quadratic formula. Granted, this is because I learned it the way I did, but I also know I'm not the only one.
A footnote to that is that to my mathematical sensibilities, in list notation, using the same symbol for negation and subtraction is hideous!
> Anyway, if it's such a problem, there's nothing to say you can't put parentheses around every operation in infix notation, at least in any language that I know of!
Most of us have to read code written by other people. Those other people don't have exactly the same precedence defense habits that we do.
No, we don't have to end up in the nasty middle ground where the paretheization is inconsistent and buggy, but we do. Since the "infix is good" theories and argument predict otherwise, how much weight should we give them?
Forgive my total ignorance; do the kids today not use HP calculators? When I was in college (+/- 1990), we all had HP calculators, and so thinking in terms of (+ 1 2 3 4) felt pretty natural.
Nope. TI graphing calculators are basically standard. TI-83 is standard in high school and a TI-89 is preferred by those who know how much symbolic manipulation and calculus can improve their grades. They both do infix order of operations.
I believe what is popular right now with new calculator buyers are the versions of the TI-83 and TI-89 with USB connectors and faster processors, I think they're called the TI-84 and TI-89 Titanium.
Not necessarily. Infix precedence/associativity is so "natural" that different languages have have different precedences or associativity for the same operator.
If one works in multiple languages, the only safe thing is to ignore precedence and associativity and parethesize everything.
And then there's associativity. It doesn't much matter for * and +, but it matters a lot for / and -, and if you think that * and / have the same precedence, it matters for .
And, you're continuing to ignore the fact that there are far more infix operators. Even if infix worked for +-/, that doesn't tell us that it works when there's .,->,<, &, ?, %, $, #, @, ~, ^, |, \, =, and so on (such as digraphs).
No language that uses infix has resisted the temptation to extend it past the point where it causes more problems than it solves.
I think you may have mixed people up, I've been arguing against infix, so I'm not continuing to ignore that ;p
I believe I posted a comment pointing out that lots of people aren't completely sure, offhand, if && or == has higher precedence.
And even in this branch of the thread, when I said he could have omitted some of the parentheses, I didn't mean to say infix is powerful because it can use less parenthesis. it gets rid of them with a dirty trick that doesn't scale. What I was pointing out is that people don't actually know the infix precedence rules by heart (like they try to say they do. they say it's so natural...). so they end up putting parenthesis frequently just cause they aren't sure.
It becomes just as natural, and it's easier to debug. You can drop down lines and autoindent to see the structure of the mathematical forumula. I don't know of any editors that will do that sort of thing for infix.
Comments
I know I'm not as smart as you guys, but I very strongly prefer 3 + 4 + (1 - 3/4) + ((9-2) * 8 * 3)
If you code Lisp long enough does your first expression becomes as natural to read as my expression is for me?
Prefix arithmetic is easier to read:
You can see straight away that the whole thing is one big addition; that the third summand is a subtraction, etc..Also, a lot of math is prefix: f(x,y) ; d/dx (...) etc..
I never understood why this was an issue. People are really used to writing prefix functions in all languages def foo( bar, baz):
And I've never really had a hard time with reading arithmatic, so the debate really leaves me scratching my head.
I note that infix was so natural that you resorted to parens.
Infix looks reasonable until one has more than 2 operators. Then people start making mistakes. To combat those mistakes, they start parenthesizing. The number of mistakes goes down but there's still confusion. (Some folks know more precedence levels than others and many folks think that they know precedence levels that they don't know.)
Another way to put that is that Lisp is so natural it resorts to forcing parens everywhere even when I don't want them! I'd never deny that confusion about order of operations between &, |, ==, <<, %, and so on, is a major source of bugs. (But I'd blame poor coding style for that, in any language, in the first place.)
However, in every field besides this niche of computer science, including almost all of math, finance, science, and engineering, infix is used. This means that it is at least good enough and I suspect it has advantages.
Many math operations really are just fundamentally unary or binary. Generalizing - or / or x^y or mod to lists is just silly as far as I can see, and adds confusion. I don't need to see parens around the outermost operation. For the two most common associative operations, + and *, order of operations is quite good enough and it has the advantage that everyone since grade 6 has been working with it.
(I'll give you that there are very many cases where list notation is great, but I don't think it's common that they help very much in science, business, or engineering.)
> However, in every field besides this niche of computer science, including almost all of math, finance, science, and engineering, infix is used.
The reason is that the "reader" in all of those domains is another human and humans do error correction almost without thinking.
Also, each of those domains has a very small number of operators - programming languages have lots of operators.
Feel free to demonstrate that you know the precedence/associativity rules for your favorite programming language by typing them without looking them up. (I know two people who can do that for C; the vast majority can't.)
I'm only trying to defend a very narrow point, that when coding mathematical expressions, infix isn't bad.
Code is read by human beings too (perhaps just the person who wrote it) and more find infix arithmetic more natural looking.
I see the appeal in the idea that arithmetic is really just a very special case of a programming structure and should be treated as such, but on the other hand, I and many others can instantly see what a + bc/d - d(e+f)*g means and would like equation-heavy pieces of my programs to somewhat resemble equations everywhere else in life.
Does you have the quadratic formula memorized in list notation? How about the sum of an arithmetic or geometric series, or a formula for an inverse square law force?
> I'm only trying to defend a very narrow point, that when coding mathematical expressions, infix isn't bad.
Programming isn't math.
> Code is read by human beings too (perhaps just the person who wrote it) and more find infix arithmetic more natural looking.
And that's how infix causes bugs. The human reader error corrects and the compiler doesn't.
My goal is correct programs. What's yours?
Lisp notation eliminates a whole class of bugs.
Bugs are expensive - what are you getting for the ability to have more of them?
> I and many others can instantly see what a + bc/d - d(e+f)*g means
Really? It has at least two meanings. Which one is correct?
Yes, I do memorize formulas in a form that doesn't allow for precedence/associativity errors. Why I should prefer a form that does allow for such errors?
Programming isn't math, but mathematical expressions are often found in programs, more or less so depending on the domain. My preference is to have readable mathematical expressions in programs that resemble the forms in which I see or use them elsewhere.
In the general case of complex logical and bitwise expressions, order of operations can cause a tremendous number of bugs. I like to use parentheses to make these cases absolutely unambiguous anyway. But I can't remember introducing a serious bug because I messed up order of operations between +- and X. Anyway, if it's such a problem, there's nothing to say you can't put parentheses around every operation in infix notation, at least in any language that I know of!
Maybe my preference relates to having a fairly visual memory for formulas and such. If I want to find a root of a quadratic equation, I do (-b + sqrt(b * b - 4 * a * c))/(2 * a), and that is easy, and anyone with high school math sees that in someone's code they know what it is. (I probably have to check for a zero denominator and also look at the discriminant unless I'm directly using complex numbers, and there's also the conjugate root, but that doesn't change much.)
If I have to write (/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a)) then I can do it, but it takes a lot of thought and it doesn't go along with the way I think about the quadratic formula. Granted, this is because I learned it the way I did, but I also know I'm not the only one.
A footnote to that is that to my mathematical sensibilities, in list notation, using the same symbol for negation and subtraction is hideous!
> Anyway, if it's such a problem, there's nothing to say you can't put parentheses around every operation in infix notation, at least in any language that I know of!
Most of us have to read code written by other people. Those other people don't have exactly the same precedence defense habits that we do.
No, we don't have to end up in the nasty middle ground where the paretheization is inconsistent and buggy, but we do. Since the "infix is good" theories and argument predict otherwise, how much weight should we give them?
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
Forgive my total ignorance; do the kids today not use HP calculators? When I was in college (+/- 1990), we all had HP calculators, and so thinking in terms of (+ 1 2 3 4) felt pretty natural.
Nope. TI graphing calculators are basically standard. TI-83 is standard in high school and a TI-89 is preferred by those who know how much symbolic manipulation and calculus can improve their grades. They both do infix order of operations.
I believe what is popular right now with new calculator buyers are the versions of the TI-83 and TI-89 with USB connectors and faster processors, I think they're called the TI-84 and TI-89 Titanium.
not only that, 2 of the 3 sets of paren were not needed, the order of operations already would have gotten it right
Not necessarily. Infix precedence/associativity is so "natural" that different languages have have different precedences or associativity for the same operator.
If one works in multiple languages, the only safe thing is to ignore precedence and associativity and parethesize everything.
cool. which of the basic arithmetic operators have difference precedence in which languages?
what i am used to is * and / first, then + and -.
apl for one.
And then there's associativity. It doesn't much matter for * and +, but it matters a lot for / and -, and if you think that * and / have the same precedence, it matters for .
And, you're continuing to ignore the fact that there are far more infix operators. Even if infix worked for +-/, that doesn't tell us that it works when there's .,->,<, &, ?, %, $, #, @, ~, ^, |, \, =, and so on (such as digraphs).
No language that uses infix has resisted the temptation to extend it past the point where it causes more problems than it solves.
I think you may have mixed people up, I've been arguing against infix, so I'm not continuing to ignore that ;p
I believe I posted a comment pointing out that lots of people aren't completely sure, offhand, if && or == has higher precedence.
And even in this branch of the thread, when I said he could have omitted some of the parentheses, I didn't mean to say infix is powerful because it can use less parenthesis. it gets rid of them with a dirty trick that doesn't scale. What I was pointing out is that people don't actually know the infix precedence rules by heart (like they try to say they do. they say it's so natural...). so they end up putting parenthesis frequently just cause they aren't sure.
It becomes just as natural, and it's easier to debug. You can drop down lines and autoindent to see the structure of the mathematical forumula. I don't know of any editors that will do that sort of thing for infix.
not if you used infix notation for + - * / as a child e.g. in school and learned Lisp after age 16 -- at least that is my experience.