More info on "The Expression Problem" https://en.wikipedia.org/wiki/Expression_problem

There are OOP languages that use doThing(X, Y), though.

Ada, Julia, Dylan, Common Lisp for example.

Yet another example why people shouldn't put programming paradigms all into the same basket.

There are a handful of (somewhat exotic) languages that support multiple dispatch - pretty much, all those listed by you. None of the mainstream ones (C++, Java, C# etc) do.

(also Common Lisp is hardly a poster child of OOP, at best you can say it's multi-paradigm like Scala)

Multi-methods do seem like a missed opportunity:

https://nice.sourceforge.net/visitor.html

At least we have Julia and Clojure as more mainstream versions of them.

Still it isn't CLOS.

I guess Julia and Clojure are exotic.

Since when do OOP languages have to be single paradigm?

By then point of view, people should stop complaining about C++ OOP then.

> Since when do OOP languages have to be single paradigm?

What I really meant to say with that was that it's lisp at its core -i.e. if one wants to place it squarely in one single paradigm, imo that one should be "Functional".

I was just surprised to see it listed as an example of OOP language, because it's not the most representative one at that.

The Art of Metaobject protocol was written and researched in Lisp.

Provides an OOP programming model, that no mainstream language, other than Common Lisp fully supports.

https://en.m.wikipedia.org/wiki/The_Art_of_the_Metaobject_Pr...

Dylan, Julia and Clojure only have subsets of it.

C# does support a form of multiple dispatch, through the dynamic keyword. Used it myself for writing a parser.

https://shawnhargreaves.com/blog/visitor-and-multiple-dispat...

Yeah, the dot operator is not a particularly strong signal of whether something is OOP or not. You could change the syntax of method calls in OO languages to not use the object as a prefix without the underlying paradigm being affected.

> Suddenly clicked for me why some people/languages prefer doThing(X, Y) vs. X.doThing(Y)

It's when you start writing ThingDoer.doThing(X, Y) that you begin questioning things.

But if you make it thingService.doThing(x,y) you're all good.

In Go, of course, thingService would implement the interface Thinger.

Excuse me, you need a BeanShell.BeanThread.GeneratorStalk.VeggFactory to do that in this Environment®™

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

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.

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

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.

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.

This mention of verbs reminds me of Steve Yegge's blog post "Execution in the Kingdom of Nouns" from 2006.

https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...