[shuaiboi]

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...

[saghm]

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.

[roland-s]

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" \*)

[atsbbg]

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...

[nickitolas]

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()")

[Ferret7446]

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.

[ivanjermakov]

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.