> My pet theory about why the object.method(args) call syntax won is that it really is the most natural to read, as evidenced by the fact that most human languages follow subject-verb-object word order.

Most western languages maybe, but according to wikipedia[1] the most common is actually SOV rather than SVO.

[1] https://en.wikipedia.org/wiki/Word_order#Distribution_of_wor...

Most common by number of languages maybe, but if we look at most common by number of people who speak the language, the top 3 most popular languages in the world(Mandarin, Spanish, English) are all SVO.

> [...] as evidenced by the fact that most human languages follow subject-verb-object word order.

Nope. [1]

[1] https://wals.info/chapter/81 (Note that while this is the language count only, the same comment applies to the population using such word order as a native tongue: SOV and SVO are both common.)

Though I program in languages that most follow the obj.method(args) pattern, I really prefer the args |> function |> function pattern and I wish it was the norm in every programming language.

In what language is that used? It reminds me of pipes in bash. I can see it being useful in circumstances where you have lots of function calls and fewer arguments (just like pipes), but I think it would look really ugly and hard to parse with a long arg list.

It's a common functional thing. I know F# has both `|>` and `<|` to go both directions. It also has `||>` and `|||>` variants which take two- or three-value tuples and spread them to arguments.

https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe...

Elixir for one.

Yes it works best when you have one argument to pass, as the first argument is passed implicitly.

https://hexdocs.pm/elixir/Kernel.html#%7C%3E/2

Julia supports it, too:

https://docs.julialang.org/en/v1/base/base/#Base.:|%3E

See also Clojure's threading macros: https://clojure.org/guides/threading_macros

These are two different use cases. In the first case, which method the call actually dispatches to depends on obj, so it kinda makes sense for it to be syntactically distinct from other args. The pipeline syntax is normally used with free-standing functions that are statically dispatched.

Now, yes, there are languages with multimethods, where the distinction is less obvious. For those that always dispatch on all arguments, a uniform syntax makes more sense. CLOS is a good example.

The commonality you are referring to sounds like Chomsky's concept of Universal Grammar [1].

The object.method(args) "won" because it is a low barrier to entry from English to Programming indeed, but as you become more and more experienced and you shake off the imperative way of thinking in favour of declarative thinking functional languages becomes more expressive than imperative languages. They become better at managing complexity because they allow you to build higher and higher towers of abstraction.

And then homoiconicity [2] shines because of its 'universally grammatic' property.

1. https://en.wikipedia.org/wiki/Universal_grammar

2. https://en.wikipedia.org/wiki/Homoiconicity

I was thinking on a more basic level than UG; just the presence of linguistic universals [1]. I agree that functional languages are in a certain way more expressive than imperative ones, but that seems mostly orthogonal to the syntax of the language.

I’m thinking about basic stuff like improper nouns, denoting a clause’s role by inflection or adposition instead of word order, and having a clearly defined spoken representation- none of this is specific to which abstract structures the language is describing.

https://en.wikipedia.org/wiki/Linguistic_universal

>The object.method(args) "won" because it is a low barrier to entry from English to Programming indeed

BASIC and C didn't have a concept of objects* , which didn't seem to hinder adoption at all. object.method() became popular when OOP languages became popular, and that was because IDEs offered better autocompletion with that syntax.

* We could emulate objects with C in some gnarly ways. Almost no one did at the time, excluding C-with-classes/C++.

It's not that simple, D has UFCS (Uniform Function Call Syntax), which makes object.method(args) and method(object, args) equivalent calls.

Also there's a non-language related advantage of dot notation. Type the name of the object, press dot and IDE will show you what things you can do with that object. You don't have that with other notations.

That assumes a very OO mindset. method(object, args)/function(data, parameters) works better in other languages, and IDEs can handle this quite well without dot syntax.

Which goes to your point-- form follows function, in syntax as with many other things.

Why is dot special? Fortran uses % (if I remember properly) IDE's can complete after a % as well as after a dot.

Dot is not special. Putting the receiver objects first is special, because it allows the IDE to only show verbs (methods) that pertain to that object. If you put the verb first, code completion lacks context, so it would necessarily have to show you all verbs that can apply to any object that could conceivably be acted on in that scope.