3 ms·

BTW, tell me which of these makes more sense: (+ 3 4 (- 1 (/ 3 4)) (* (- 9 2) 8 3)) +(3 4 -(1 /(3 4)) *(-(9 2) 8 3)) why oh why would you want a function to

by curi 19y ago

BTW, tell me which of these makes more sense: (+ 3 4 (- 1 (/ 3 4)) (* (- 9 2) 8 3)) +(3 4 -(1 /(3 4)) *(-(9 2) 8 3)) why oh why would you want a function to be in the same grouping (set of paren) with arguments to another function, instead of grouped with its own arguments? the less you nest, the less it matters. but it is not a matter of taste which way makes more sense and scales better.

greendestiny 19y ago
Most people find infix easier to read. I really think the idea that lisp's advantage comes from having operators in the same group as parameters is ridiculous. To me lisp's power is in the orthogonality of statements, functions (and anonymous functions), data and lists. You could make a language that had very lisp like syntax but didn't support things like lists and lamda functions and it would equally clearly define a tree. That language would be just about completely useless.
- curi 19y ago
  infix and whether to call functions like foo(x y) or (foo x y) are separate issues. if infix is C's advantage, that is pretty silly. because first of all there is only a limited number of infix operators, and when you make your own constructs they are prefix, but different from s-expressions in the kinda silly way i illustrated. anyway, you can put infix into a lisp. people don't usually want to because it kinda sucks. unless you're working in certain domains. infix means: - memorizing order of operations and remembering it whenever reading code (does == or && have higher precedence? they didn't drill that one into us in middle school, so it doesn't feel quite so obvious as arithmetic order of operations) - losing characters for use in identifiers - commas in argument lists - paren for changing order of operations - functions that take a predefined number of arguments that has to be 1 or 2 - infix only works with a limited number of built in things, it doesn't scale nicely. i suppose you could change this, e.g. make # a special character, and then you can define infix foo then write arg1#foo#arg2. but like, that's ridiculous. no one wants to do that with functions in general. they only want to do it with math because they hate math and don't want to have to understand anything about it, they just want to use it mechanically like they memorized in school. - infix is an approach with less generality
  - greendestiny 19y ago
    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.
    - brlewis 19y ago
      Where on earth did you get those function names? Perhaps you meant (sum 3 4 (difference 1 (division 3 4)) (product (difference 9 2) 8 3)) 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".
      - airhadoken 19y ago
        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.
        curi 19y ago
        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 :)
ph0rque 19y ago
I realize this is an aside, but when I started thinking about learning lisp, I really wished the latter notation existed. After thinking about it, I realized why: it's in essence the Excel syntax, something that a lot of computer-literate people are familiar with.
WilliamLP 19y ago
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?
- brlewis 19y ago
  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.
- anamax 19y ago
  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.)
  - curi 19y ago
    not only that, 2 of the 3 sets of paren were not needed, the order of operations already would have gotten it right
    - anamax 19y ago
      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.
      - curi 19y ago
        cool. which of the basic arithmetic operators have difference precedence in which languages? what i am used to is * and / first, then + and -.

by curi 19y ago

greendestiny 19y ago

Most people find infix easier to read. I really think the idea that lisp's advantage comes from having operators in the same group as parameters is ridiculous. To me lisp's power is in the orthogonality of statements, functions (and anonymous functions), data and lists. You could make a language that had very lisp like syntax but didn't support things like lists and lamda functions and it would equally clearly define a tree. That language would be just about completely useless.

curi 19y ago
infix and whether to call functions like foo(x y) or (foo x y) are separate issues. if infix is C's advantage, that is pretty silly. because first of all there is only a limited number of infix operators, and when you make your own constructs they are prefix, but different from s-expressions in the kinda silly way i illustrated. anyway, you can put infix into a lisp. people don't usually want to because it kinda sucks. unless you're working in certain domains. infix means: - memorizing order of operations and remembering it whenever reading code (does == or && have higher precedence? they didn't drill that one into us in middle school, so it doesn't feel quite so obvious as arithmetic order of operations) - losing characters for use in identifiers - commas in argument lists - paren for changing order of operations - functions that take a predefined number of arguments that has to be 1 or 2 - infix only works with a limited number of built in things, it doesn't scale nicely. i suppose you could change this, e.g. make # a special character, and then you can define infix foo then write arg1#foo#arg2. but like, that's ridiculous. no one wants to do that with functions in general. they only want to do it with math because they hate math and don't want to have to understand anything about it, they just want to use it mechanically like they memorized in school. - infix is an approach with less generality
- greendestiny 19y ago
  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.
  - brlewis 19y ago
    Where on earth did you get those function names? Perhaps you meant (sum 3 4 (difference 1 (division 3 4)) (product (difference 9 2) 8 3)) 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".
    - airhadoken 19y ago
      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.
      - curi 19y ago
        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 :)

ph0rque 19y ago

I realize this is an aside, but when I started thinking about learning lisp, I really wished the latter notation existed. After thinking about it, I realized why: it's in essence the Excel syntax, something that a lot of computer-literate people are familiar with.

WilliamLP 19y ago

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?

brlewis 19y ago
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.
anamax 19y ago
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.)
- curi 19y ago
  not only that, 2 of the 3 sets of paren were not needed, the order of operations already would have gotten it right
  - anamax 19y ago
    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.
    - curi 19y ago
      cool. which of the basic arithmetic operators have difference precedence in which languages? what i am used to is * and / first, then + and -.