Hacker News Reader

Comment by shuaiboi | Hacker News Reader

bjarne (creator of c++) has a quote about this:

Unified function call: The notational distinction between x.f(y) and f(x,y) comes from the flawed OO notion that there always is a single most important object for an operation. I made a mistake adopting that. It was a shallow understanding at the time (but extremely fashionable). Even then, I pointed to sqrt(2) and x+y as examples of problems caused by that view.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p19...

View on HN

The main benefit of x.f(y) IMO isn't emphasizing x as something special, but allowing a flat chain of operations rather than nesting them. I think the differences are more obvious if you take things a step further and compare x.f(y).g(z) and g(f(x, y), z). At the end of the day, the difference is just syntax, so the goals should be to aid the programmer in writing correct code and to aid anyone reading the code (including the original programmer at a later point in time!) in understanding the code. There are tradeoffs to using "method" syntax as well, but to me that mostly is an argument for having both options available.

The pipe operator eliminates the syntax problem.

Ocaml example:

  let increment x = x + 1
  let square x = x \* x
  let to_string x = string_of_int x

  let result = 5 |> increment |> square |> to_string
  (\* result will be "36" \*)

That's exactly the context of where this quote comes from. He wanted to introduce Unified call syntax[1] which would have made both of those equivalent.

But he still has a preference for f(x,y). With x.f(y) gives you have chaining but it also gets rid of multiple dispatch / multimethods that are more natural with f(x,y). Bjarne has been trying to add this back into C++ for quite some time now.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n44...

That makes sense! It wasn't immediately obvious to me from the context of this discussion though, since it seemed like you were responding to the parent comment's framing of it as a choice between one or the other. This might just be from me never having heard of the term "unified call syntax" though, and I admit that I didn't expect to need to read through the PDF you linked before super carefully after opening it and seeing a bunch of C++-specific details that I knew would go over my head. (On a good day, I can remember what words SFINAE is an acronym for, but I don't think I ever really felt like I got comfortable enough with C++ to fully understand how the template code I saw actually encoded behavior that fit what I'd expect those words to mean).

If my memory isn't failing me, that was part of the reason rust went with a postfix notation for their async keyword ("thing().await") instead of the more common syntax ("await thing()")

Yep, and that itself was similar to the rationale for introducing `?` as a postfix operator where the `try!(...)` macro had previously been used. In retrospect, it's kind of funny to look back and see how controversial that was at the time, because despite there being plenty of criticism of the async ecosystem in once, the postfix `.await` might be the one thing that seems to consistently be praised by people needing to use it. People might not like using async, but when we do use it, it seems like we're pretty happy with the syntax for `.await`.

The flaw here isn't OO, but the idea that it should be applied in all cases. The point of OO methods is to control access and mutation of an object's private members. Rather than have clients know to, e.g., lock specific fields before accessing, you expose a method that handles the locking appropriately.

There is the most important argument regardless, whether it is a method or regular function - first one (or last one in languages supporting currying). While it's true that there are functions with parameters of equal importance, most of them are commutative anyway.

Reply on news.ycombinator.com