One of the things I love about programming in dialects of ML like ocaml and f# is the forward pipe operator:

  x
  |> f
  |> g
  |> h

So if it were something like

  h(z, g(y, f(x))

  x
  |> f
  |> g y
  |> h z

  my_data
  |> filter (x => x > 37)
  |> select (x => x * 2)
  |> sum

Mathematica has a crazy amount of syntax abbreviations (https://reference.wolfram.com/language/guide/Syntax.html). Of course your whish is fulfilled there: x // f called the postfix operator.

In a lazy language like Haskell, the order in which things are actually evaluated is f -> g -> h -> x, because arguments to a function are only evaluated when the are needed, rather than before they are called. But even so, I still prefer writing it as x |> h |> g |> f.

Do you mean (((x)h)g)f ?

since the order in which things happen is "h first, then g, then f"

So would you like to write shell commands connected with pipes like that too?

So is this better too

  $ less | find / -type f -perm /6000 -ls

  $ find / -type f -perm /6000 -ls | less

ps. I'm fine with current notation and would not like change it.

That actually makes so much sense...

When you're calling a function, you're putting some things into the function... You have to get the things first before you can put them in...

Why didn't it evolve like that in the first place? Is it a byproduct of mathematical notation? If so, I wonder why mathematical notation evolved that way in the first place...

Did you even have an RPN-based calculator at school?

As to more serious programming languages, Erlang, F#, Haskell have forms of a "pipe" operator, roughly

  [1 2 3] |> sum |> print

But the original algebra functions, as introduced by Leibniz in 17th century, were, of course, pure functions, more like properties than procedures. So cos(x), aka cos x, is just a formalized shorthand for "cosine of x", so it preserved the order of words typical for Germanic and Romance languages. Maybe if functions were introduced by the Japanese, we would have the reverse order, kind of x の cos.

Stack based languages and the APL tradition all follow this pattern, which I agree can be more terse and nice too. I've also been experimenting with right-associative calls which does the same thing but in reverse. For a data pipeline you're more likely to transform from A->B, so I think the post-fix syntax makes sense.

But you can also define a "thread" operator easily for doing subsequent function calls. ala `threaded x { f; g; h }`

Assuming you mean h)g)f, you can do it in D. D allows you to write this:

f(g(h(x))) as x.h().g().f() or even x.h.g.f (parenthesis are optional).

If `f` is an expression, that would require it to be evaluated last as well.

This is why some languages have the | pipe syntax for chaining operations.

And that's why "purely procedural" languages don't make much sense to me

It's more natural to write

    x.h().g().f()

you can start with

    var chain = x=>f=>f?chain(f(x)):x;
    chain(x)(h)(g)(f)();

    var _ = (f,...y)=>x=>f(x,...y);
    var sum = (x,y)=>x+y;
    chain(1)(_(sum,1))()

    var $ = (x,...f)=>f.reduce((x,f)=>f(x),x);
    $(1,_(sum,1));

    var sum1 = _($,_(sum,1));
    sum1(1);

I want to put the function below the arguments, so that the call tree actually looks like a tree

    u v x y
     f   g
       h

[flagged]

The function reference is actually evaluated first so your preferred order is actually backwards! Consider this:

  foo.bar(x)

  foo()(bar())