You see, there's a bit of irony here in characterizing jargon as gatekeeping, because in the author's attempt to distill it, some pretty critical stuff got lost in translation.
I share the sentiment that FP jargon can be impenetrable to the uninitiated, but the same can be said about programming jargon to non-techies: it may sound like gatekeeping to talk about "closures" but there's technical reasons why closures are called closures and global state being accessed by functions are not.
The same goes for FP. Saying `val => val + val` is a functor because it maps numbers to numbers isn't really correct: you could arguably only say that in an universe where `val + val` is the only possible operation, and even then, that's not really correct because the utility of the function is hardcoded (meaning that if we were to hypothetically introduce an axiomatic operation, the internal consistence of this new algebra would implode). In a more useful algebra in a regular universe, the mapping must hold for any valid operation for that type. So a functor for the `number` type ought to look more like something like `Number.prototype.map = function(f) {return f(this)}` (i.e. the mapping contract holds for addition, subtraction, and all other algebraic operations that are valid on numbers contained within `f`)
There are also practical technical things the article glossed over: Array.prototype.map is not monadic. The signature of the callback is `(T, number, Array<T>) => U`, which is most certainly not unary (and for that matter, using JS to illustrate FP is fundamentally problematic since JS isn't side-effect-free to begin with). If you think that's nitpicky, one fundamental thing with FP is that composition relies heavily on algebras not breaking on corner cases. This is why, for example, fantasy-land specifies a different method name for `map` (called `fantasy-land/map`); because `map` is already taken by Array and it breaks some composition patterns (notoriously, `[1,2,3].map(parseInt)`)
I absolutely think this is nitpicky, and a perfect demonstration of the pedantry I'm talking about:
> Array.prototype.map is not monadic. The signature of the callback is `(T, number, Array<T>) => U`, which is most certainly not unary (and for that matter, using JS to illustrate FP is fundamentally problematic since JS isn't side-effect-free to begin with).
The unspoken understanding in the OP is that we're only using .map() in the single-argument form. The author makes it clear that only a function with a single argument counts for their definition, and I feel there's also an implicit understanding that that function has to be pure.
The fact that JavaScript technically lets you break both of these assumptions is entirely beside the point. For the sake of teaching, this idealized case is carved out for the example, and I for one had no misconceptions resulting from the relevant quirks of JS. We aren't writing a bullet-proof type system here, we're learning about concepts.
It's not beside the point, though. It's a crucial aspect of FP!
Perhaps I'm getting a different reading from the article than you, but as someone who's gone in and out of this rabbit hole, I found that the author was making some pretty stretchy claims. For example, he says "It may also seem like every monad that is needed already exists. Some common ones are" and proceeds to name Arrays and Promises, neither of which can be used in functional composition beyond the very basic `foo.map(f)` (and may break even then, as per my trivial example above!)
It's fine to try to use a non-functional language to try to explain functional concepts to those who are familiar w/ JS but not FP, but also keep in mind that you may be misunderstanding unknown unknown nuances because of the misappropriation of one domain (JS) to explain another (FP). You yourself are an example of someone who seemed to be about to take a mischaracterized technicality at face value before an avalanche of people started pointing out issues. How do I know to what extent you or someone else understands the implications of functions not always being endofunctors, Arrays not actually being monadic, or why map vs fantasy-land/map matters?
There's a real cost when people come out of reading articles thinking they know more FP than they actually do. This exact discussion about strictness already had implications to the design of Javascript itself: the algebraic consistency argument was brought up while Promises were being specified, but it got dismissed and we ended up with non-monadic promises (and shitshows festered all over the place as a result, e.g. rxjs had to special case them, and we have stuff like fluture.js because why not have multiple future types). The Fantasy Land project itself was created out of spite of a dismissive comment in the promises discussion calling algebraic consistency "fantasy land". On another occasion, one of the React core team members went on twitter at one point saying react hooks are pure (and don't even get me started on algebraic effects). The amount of misunderstanding surrounding FP - even among JS engineers at FAANG - is frankly scary and "loose-is-fine" mentality seeping into the design of widely used APIs is not exactly ideal.
I share the sentiment that FP jargon can be impenetrable to the uninitiated, but the same can be said about programming jargon to non-techies: it may sound like gatekeeping to talk about "closures" but there's technical reasons why closures are called closures and global state being accessed by functions are not.
The same goes for FP. Saying `val => val + val` is a functor because it maps numbers to numbers isn't really correct: you could arguably only say that in an universe where `val + val` is the only possible operation, and even then, that's not really correct because the utility of the function is hardcoded (meaning that if we were to hypothetically introduce an axiomatic operation, the internal consistence of this new algebra would implode). In a more useful algebra in a regular universe, the mapping must hold for any valid operation for that type. So a functor for the `number` type ought to look more like something like `Number.prototype.map = function(f) {return f(this)}` (i.e. the mapping contract holds for addition, subtraction, and all other algebraic operations that are valid on numbers contained within `f`)
There are also practical technical things the article glossed over: Array.prototype.map is not monadic. The signature of the callback is `(T, number, Array<T>) => U`, which is most certainly not unary (and for that matter, using JS to illustrate FP is fundamentally problematic since JS isn't side-effect-free to begin with). If you think that's nitpicky, one fundamental thing with FP is that composition relies heavily on algebras not breaking on corner cases. This is why, for example, fantasy-land specifies a different method name for `map` (called `fantasy-land/map`); because `map` is already taken by Array and it breaks some composition patterns (notoriously, `[1,2,3].map(parseInt)`)