I agree with you on namespacing: I've found myself having to add prefixes myself when working with a bunch of similar datatypes with identically-named constructors (e.g. terms and types in a compiler have many similarities).
Saying "non-argument" and ending it there is not useful, but in this case it's shorthand for something along the lines of "not even wrong", and I think that's a valid answer for some (not all!) of the points in the OP.
To pick one example: the author gives an example of an eta-reduced function and then says:
let fn1 a b c d = ... do something ...
let fn2 a b c = fn1 a b c
fn2 a b c d
> and you're like ...wtf... where the hell does d come from.
(Or their criticism of partially-applied functions, which is essentially the same thing.)
This is a "non-argument": the only thing that is being made clear here is that the author hasn't spent sufficient time learning the idioms of an unfamiliar style of programming. Yes, horrible partial-application like
f = (g .) . ($) . (. (. h))
or whatever is always a bad idea, but saying that writing
map f
is always worse than
map (\x -> f x)
is much more likely to be a symptom of unfamiliarity than a deep, cutting critique of functional programming style.
The whole thing was obviously driven by unfamiliarity and stubbornness in clinging to the familiar but your comparison of "map f" vs "map (\x -> f x)" is not equivalent to his comparison of "array.map(fn)" to "array.map(x => fn(x))".
The haskell versions are equivalent but the javascript versions are not due to the airty issues raised in the comments.
If you do raise that then it's no longer an argument against partial application or "high[er] order functions", since you can't really call `fn` partially applied if fn and x => fn(x) aren't equivalent.
Saying "non-argument" and ending it there is not useful, but in this case it's shorthand for something along the lines of "not even wrong", and I think that's a valid answer for some (not all!) of the points in the OP.
To pick one example: the author gives an example of an eta-reduced function and then says:
> and you're like ...wtf... where the hell does d come from.(Or their criticism of partially-applied functions, which is essentially the same thing.)
This is a "non-argument": the only thing that is being made clear here is that the author hasn't spent sufficient time learning the idioms of an unfamiliar style of programming. Yes, horrible partial-application like
or whatever is always a bad idea, but saying that writing is always worse than is much more likely to be a symptom of unfamiliarity than a deep, cutting critique of functional programming style.