Live data from Hacker News

Why Operators Are Useful

neopythonic.blogspot.com

11–20 of 173 posts

Re: Why Operators Are Useful

#11
post #7

Earlier quoted context omitted.

You don't have to do it like that. You could do: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (+ (* x z) (* y z)) (* x (+ y z))) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) I think the last one makes the relationships quite clear. Writing legible equations is an art form, as is writing sexps. Ed…

Some would argue that the fact that you have all of those alternative forms is part of the problem. Lisp is one of the (if not the) most individualistic programming languages around. Lisp makes it easy for a programmer to create their very own impenetrable, arcane, domain specific languages. This causes large organizations to avoid it like the plague. Large teams don't want artists, they want replaceable parts.

Are you talking about macro or formatting?

If it's about formatting, given that this is what this thread is about, you can use code formatter for lisp languages exactly like for any other language, in fact they are even easier to write for lisp because of the consistency of S expressions.

If you are talking about macro, then you're in the same boat as other languages that have macros, C, Rust, ect... And remember that the first rule of macros is to not use macros, except for when you absolutely have to, and in those cases it is the most elegant solution. If you have devs inventing DSLs for everything, then lisp isn't your problem.

Re: Why Operators Are Useful

#12
post #2

This is much less confusing than (2), and leads to the observation that the parentheses are redundant, so now we can write "x + y + z" This is a non-problem if you're using Lisp. (+ x y z) accepts an arbitary number of arguments and the operator precedence problem does not exist since there is no operator precedence.

If this is so obviously preferable, why have mathematicians so obdurately not adopted this style?

Mathematical notation is not an archaic practice that is followed out of a respect for tradition, or a doctrine that has been developed from first principles, it is something that has evolved (and continues to do so) because it has been useful.

Re: Why Operators Are Useful

#13

Earlier quoted context omitted.

Lisp is pretty ugly :) (eql (* x (+ y z)) (+ (* x y) (* x z))) I wonder if its famed sense of enlightenment is partly just overcoming the mental hurdle of it's syntax. Edit: typo fix, had x/z mixed up

You don't have to do it like that. You could do: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (+ (* x z) (* y z)) (* x (+ y z))) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) I think the last one makes the relationships quite clear. Writing legible equations is an art form, as is writing sexps. Ed…

For comparison infix notation with the same precedence for all operators:

    (x * (y + z)) eql ((x * z) + (y * z))
Or:

    (y + z * x) eql (x * z + (y * z))
With different precedence:

    x * (y + z) eql x * z + y * z
But now you have to remember precedences and mentally regroup the expression.

Re: Why Operators Are Useful

#14
he doesn’t make any coherent argument as to why one is more clear or preferred than the other. he simply states it and moves on with this bias. for example, when he compares 2 to 2a, i feel he doesn’t really address anything and just states his preference as the more clear one.

plus, he of course seems to know nothing about lisp (or just ignores it) where you might have:

  (+ a (+ b c)) = (+ (+ a b) c) = (+ a b c)
all three are valid lisp syntax and represent associativity of addition well, including “dropping the parentheses”. the thing is, procedure notation as opposed to infix operators actually make it more explicit by what is meant by associativity. this is because it makes explicit about what comes first because of how procedures are evaluated. this is much more explicit than conventions of what parentheses mean in infix operator expressions. even his python procedure example in (2) demonstrates this property.

the distributive law is:

(* a (+ b c)) = (+ (* a b) (* a c))

that seems pretty clear to me. and with this, you can of course extend the language such that the +, , etc. procedures operate on new data types or heterogeneous data types like ( c v) where c is a constant and v is a vector and you get scalar multiplication.

it is also funny to me that he considers readability over performance. well, i do too, but you can have both. see lisps, schemes, and sml dialects, all languages he seems to ignore the existence of.

another thought is that i recall gerald sussman saying in a talk that mathematical notation is impressionistic, and in general, i think he is right. his point was that procedure notation is much more explicit. he also mentions that prefix notation is inconvient for small expressions versus infix notation but is much more preferred when you have very large expressions with many, many terms.

Re: Why Operators Are Useful

#16

he doesn’t make any coherent argument as to why one is more clear or preferred than the other. he simply states it and moves on with this bias. for example, when he compares 2 to 2a, i feel he doesn’t really address anything and just states his preference as the more clear one. plus, he of course seems to know nothing about lisp (or just ignores it) where you might have: (+ a (+ b c)) = (+ (+ a b) c) = (+ a b c) all…

Isn't "...once you've learned this simple notation, equations written using them are easier to manipulate than equations written using functional notation..." his argument why operators are more clear?

I don't necessarily agree with that, but I haven't made a world class programming language, either. I just assume he knows something I don't.

Re: Why Operators Are Useful

#17
post #7

Earlier quoted context omitted.

You don't have to do it like that. You could do: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (+ (* x z) (* y z)) (* x (+ y z))) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) I think the last one makes the relationships quite clear. Writing legible equations is an art form, as is writing sexps. Ed…

Some would argue that the fact that you have all of those alternative forms is part of the problem. Lisp is one of the (if not the) most individualistic programming languages around. Lisp makes it easy for a programmer to create their very own impenetrable, arcane, domain specific languages. This causes large organizations to avoid it like the plague. Large teams don't want artists, they want replaceable parts.

Some would argue that Lego and Technic are too complicated, and we should all play with Duplo.

Thankfully, Michelangelo and Leonardo were not in large teams.

Which do you aspire to be: a cog or an artist?

Re: Why Operators Are Useful

#18
The mnemonic value of "operators" as reminders of properties such as associativity or commutativity interestingly extends to diagrammatic reasoning. A diagram is really just a generalized expression, and this becomes quite useful when one has to deal with more than one "type" or "domain" of operation, but in a consistent way that preserves the compositionality-like properties OP talks about. A recent book exploring this topic is "Seven Sketches in Compositionality; An Invitation to Applied Category Theory" https://arxiv.org/abs/1803.05316 . (Despite the obvious reference to CT in the title, the work is quite accessible and the math involved is not much more complicated than that found in the linked blogpost. Importantly, and perhaps unlike some people in other programming-language communities, the author does not assume any pre-existing knowledge; the work is rather about using concrete, real-world examples to gently guide the reader's intuition.)

Re: Why Operators Are Useful

#19
Smalltalk also doesn't have this problem. Since all message-sends are essentially infix, operators (binary message sends) are simply special keyword messages.

   1 add: 2.
   1 + 2.
This is helpful when you have "operators" that aren't quite as obvious, for example raising to a power.

   2 raisedTo:3.
Since there are no operators, there is no operator precedence. However, there is precedence between different message types: unary binds tightest, then binary, keyword last. Otherwise evaluation is uniformly left to right.

While this is a question on Smalltalk job interviews ( What is 2 + 3 * 5. ?), that's only useful for filtering out people who simply have never seen Smalltalk before (in case they claim knowledge). It doesn't seem to be an issue in practice, because the evaluation rules are otherwise so simple and uniform.

The other surprising effect is that binary message sends don't seem to have the same tendency to be confusing that operator overloading does. I don't really understand this effect, because the mechanism has effectively the same power.

Re: Why Operators Are Useful

#20
post #7

Earlier quoted context omitted.

You don't have to do it like that. You could do: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (+ (* x z) (* y z)) (* x (+ y z))) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) I think the last one makes the relationships quite clear. Writing legible equations is an art form, as is writing sexps. Ed…

Some would argue that the fact that you have all of those alternative forms is part of the problem. Lisp is one of the (if not the) most individualistic programming languages around. Lisp makes it easy for a programmer to create their very own impenetrable, arcane, domain specific languages. This causes large organizations to avoid it like the plague. Large teams don't want artists, they want replaceable parts.

You have alternative line breaking in infix also. All of it sucks compared to keeping it on one line, though:

  x * (y + z) = x * z + y * z


  x * (y + z) =
  x * z + y * z


  x * (y + z)
  = x * z + y * z


   x *
   (y + 
    z)
  =
   x *
   z
      +
   y *
   z
etc.
Post reply on HN