I believe "harder to learn" is highly subjective in the same way that Japanese is hard to learn for a native English speaker but easy to learn for a Chinese.

Granted, Haskell and Scala are pretty "rich" and not beginner-focused.

OTOH, a language like Elm has a pipe operator and manages to keep things pretty simple.

Now does javascript need the added complexity? Tough call.

that's fair, i was in a spicy mood.

there's "esoteric" as in fundamentally complicated, and """esoteric""" as in syntax that's unfamiliar but easily explained w/ a quick web search.

i believe "it's nicer to express some things this way" is a very important practical benefit. for me, "being expressive for experienced users" is ultimately more important to optimize for than """learnablility""", scare quotes intended. because beginners will be beginners for a while, and then they won't. (i dislike e.g. Go for this reason, but let's not get sidetracked)

(before you or someone else asks: i've tutored many beginner/first-time programmers, and yes, i still think a bit of syntactic sugar won't hurt them)

The practical benefit is that, unlike say Lodash's chaining, it is outwardly extensible, you don't need to write every function into a big object (and worry about naming clashes).

  _.chain(inputSet)
      .filter((x) => x >= 0)
      .map((x) => x * 2)
      .thru((e) => new Set(e))
      .value()

Assumes chain returns a object with {filter, map, thru, value}, and if you want a new operation you need to assign it to that object, which means the library that returned the original object must expose that too, and everyone knows "Prototype Extension Is Bad" since you could come up with a method name that someone else came up with too, then you'd override things and introduce bugs.

With chaining (even ignoring the % Hack syntax for placeholder expressions) you can use functions from anywhere: local variables, other objects, anything you want, even if the library that provided the original data is not viable to modify, since it doesn't need to be modified.

Another way of approaching this extension problem is, well, with extension members, like Kotlin or C#, where you can declare free functions to operate on a "this" of a specific type, and then you can use it exactly as if it was a method of the type. Of course, JS is dynamically typed so that wouldn't be viable in this case.

Finally, I think that for JS specifically, a pipe function is enough. Sure you have a few more commas around but it's fine. I could see the appeal of having an operator in TypeScript, since it would mean that types would be preserved much better.

> no practical benefits other than “it looks cooler”

That is a very ignorant take and only shows that you haven't taken the time to learn the first thing about functional programming.