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 construct

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.