You have a point but you mention C#, it's worth thinking of how you'd handle one of the examples in C#:
items
.filter(isOk)
.map(toOtherType)
::flatten()
In C# that sort of case is primarily handled by extension methods. They have their issues not least in terms of collisions, but to me they are a beautiful solution. The equivalent in JS would seem to be the always unpopular choice of adding these methods to the prototype, and as with extension methods you'd want the user to opt-in to their addition (possibly at object level here?).
I think extension methods in C# are basically a way to work around the fact that you can't just stick a method on the prototype like you can in Javascript. I also like the C# solution, actually, I just love C#. It's a great "daily driver" language in my book.
If you took the function bind syntax to its natural extreme, you end up with a model like Python or Nim, where all instance methods accept their "this" as a first parameter, and "a.call(b)" is equivalent to "call(a, b)". Personally I always thought that was a particularly elegant way of implementing instance methods, because it doesn't require inheritance or modifying the original type.
In Nim it even lets you do some very interesting method chaining to replace nested calls, like "toInt(sqrt(toFloat(num)))" can be equivalently written "num.toFloat.sqrt.toInt"
Yup agreed but the prototype approach is scarier as it affects every user of the prototype, where as with namespaces you opt-in to bringing in extension methods at the file level by importing the associated namespace.
Not sure on the whole this as argument, I prefer it to the current approach of this being decided at framework/library level because I get bored of having to bind each function to get lexical scoping back. That Nim code is indeed beautiful though, maybe need to give ti a look ta.
items .filter(isOk) .map(toOtherType) ::flatten()
In C# that sort of case is primarily handled by extension methods. They have their issues not least in terms of collisions, but to me they are a beautiful solution. The equivalent in JS would seem to be the always unpopular choice of adding these methods to the prototype, and as with extension methods you'd want the user to opt-in to their addition (possibly at object level here?).
Not sure though, maybe I've missed something.