This is true, but the problem is that people will always prefer the explanation that is, as the saying goes, "simple, neat, and wrong" over the explanation that is more complicated, especially if they (and possibly the person explaining) aren't aware that the simplified version is wrong. Even if one starts from an accessible viewpoint, any concept that is worth isolating as a concept will involve some difficult step in its exposition, and it is at that step that the person seeking to understand—not the explainer—has to decide whether to stick with the explanation despite the difficulty, or to be satisfied with an easy and wrong explanation.
But the parent post https://news.ycombinator.com/item?id=28476325 to which lmm was responding https://news.ycombinator.com/item?id=28476569 said "Wait, a functor is just a pure unary function?" If someone asks you the definition of a technical term, you sort of have to at least refer to the technical term.
Learn You a Haskell mentions functors in chapter 8 and teaches them properly in chapter 11.
http://learnyouahaskell.com/making-our-own-types-and-typecla...
Regardless of how LYAH chooses to order things, (when have you used a Zipper last time?), they are too essential to any beginner Haskell program.
In my opinion we need a new imperative first approach to Haskell teaching, to develop intuition on monads quickly.
You could not really explain JIT compilation to someone not knowing anything about computers, could you?
You can't explain the concept of doing something only when you absolutely need to, to someone that doesn't know about computers?
I mean, it may as well refer to eagerness, which is something completely different from JIT compilation. You didn’t even say anything about what the compilation is about (which again, requires some knowledge on computers), nor about the reason for doing that.
It's actually insane how hard programmers want to gatekeep even basic concepts.
Like, you can talk about programming to a child, but still not about JIT compilation.
This attitude justifying gatekeeping reminds me of Stack Overflow - mods tired of seeing the same wrong questions asked. But it’s a Q&A site and the purpose is for people to get answers to their questions.
A student can definitely have an attitude that prevents them from learning effectively though. If anyone wants to see the use of correct terminology as "gatekeeping" then they are of course free to do so but the obstacles to learning the subject that such a mindset creates are then a logical consequence of their actions and entirely their own fault.
If you want an example of what happens to a Q&A site without any gatekeeping, look at Quora.
Now, I would say you showing up and openly disparaging both the blog and the person you responded to qualifies as "guns blazing".
The debate is about using language as a gatekeeping mechanism. The analogy is spot on...
> "shame on those who maintain this status quo."
A person shows up eager to learn, expresses gratitude, feels scorned at all of the language-based gatekeeping that goes into this topic. You don't think it's fair to feel frustrated with the people doing the gatekeeping? (I don't think _you_ will, but only because I think you're one of the gatekeepers the original poster is (fairly) shaming).
They expressed gratitude for those who told them easy falsehoods and scorn for those who told them harder truths, characterizing such honesty as "gatekeeping". That's not the action of someone eager to learn, it's someone who's eager to avoid learning, like those politicians who, rather than put in the effort to understand the economic implications of their policy, go shopping around economists until they find one who gives them the answer they want.
Can you paste me in your post where you did this? (Note: you can't). I'll even paste your response, so you can remember better:
>> Wait, a functor is just a pure unary function?
> No.
>> And an endofunctor is just one of those where the argument type and return type are the same?
> Yes - "endo" means that in general. E.g. endomorphism.
>> Sometimes it makes me mad that so much confusion (and as another commenter put it, gatekeeping) has been sown in FP circles through the invention of pointlessly-obfuscated terminology for everything (and through - among many in those circles - a lack of interest in connecting the very simple dots that would allow masses of people to understand these concepts). It's like when the medieval Catholic Church refused to print a bible in anything but Latin so that they'd remain the sole authority on its content.
>> Kudos to the OP for cutting through some of that, but shame on those who maintain this status quo.
>> Edit: assuming it really is that simple. Some in the comments have suggested parts of the OP were wrong, so I'm curious to see discussion.
> The precise terminology is vital; it's how we avoid these errors when talking about this very abstract stuff. Given that the OP is very wrong, precisely because of the kind of attitude you've taken here, I hope you'll take this opportunity to reconsider your views.
Where in this block did you give them "harder truths"? I see "No", "Yes", and then saying "reconsider your views". Again, the purpose of your post clearly wasn't to help, provide value, enable, but instead to disparage. Or, you know, gatekeep.
> They said "It's like when the medieval Catholic Church refused to print a bible in anything but Latin so that they'd remain the sole authority on its content." and concluded with "shame on those who maintain this status quo."
And as I said before that:
> someone who comes in with guns blazing doesn't get to complain about being met with hostility
It's not "gatekeeping" when there's no effort to engage productively in the first place.
> Can you paste me in your post where you did this?
Is "No but..."
So we're just saying things for the sake of it now, I guess.
I don't care to show you where I did something I never claimed to have done in the first place.
> So we're just saying things for the sake of it now, I guess.
As far as I can tell that's what you've been doing the whole time. It's the height of hypocrisy for you to complain that "the purpose of your post clearly wasn't to help, provide value, enable, but instead to disparage."
For example: I might explain the programming concept of a function as "like the equations you remember from math class" (for pure functions) or "like a recipe" (for imperative functions).
I would also not, for example, make up a totally new term for a concept people already know about that just happens to be in the context of my new system of ideas. This actually comes up a lot in my day to day software engineering work: I avoid creating new abstractions in general, and when I do I strongly avoid introducing new terminology in the naming, and when I do I document and explain it to death in the comments, using analogies wherever possible.
There are lots of opportunities where I could come up with a whole new concept with a beautiful new name that nobody understands, and I explicitly choose not to.
Does what I write above bother you at all? Do you feel that it apply to you and programmers in general? Because that is the kind of generalization you are doing to another group of programmers.
I see a lot of functional programmers spending a lot of time trying to teach others. I also see a lot of people not wanting to spend any time learning so they just talk down on functional programmers, and I think its unnecessary.
I'll admit my emotions got a little heated. I get really frustrated thinking about all the potential out there that gets wasted just because of gaps in communication (willful or otherwise), and not because of capacity for understanding. And this very comments section demonstrates the unwillingness by at least some members of the FP community to put things into terms that would help with that problem, so I do feel justified talking about the community as having an issue. Whether they represent a majority or a vocal minority is not something I can say with confidence, though I still feel like I qualified my original statements sufficiently.
In my experience concepts like Functors, Monoids, Monads etc. are difficult, not because they are complicated, but because they are seemingly too simple. A Functor is pretty much something you can map, and every programmer knows list.map, so what's the point? The point is that when you have some infrastructure around using them, then you can see new ways of using them, and you can see that mapping makes sense over a lot more structures than lists. Even over something like a function "a -> b". The problem is that non-functional languages doesn't have this infrastructure around them, so they are not very useful, and so its difficult for people not using functional languages to understand what the point is. I dont really think there is any way to get past this unfortunately and the only way to get comfortable with the terms is to program in a functional language.
> Not all functional languages have typeclasses or an alternative and convenient way to express these concepts, and in those, it's not so important to understand these notions abstractly.
This is true only in an especially strict sense. Haskell's typeclasses provide two basic mechanisms: one for associating a dictionary of data with a type, and one for automatically picking / deducing such a dictionary based on a given type. Only the latter is specific to Haskell (and Scala); the first can be performed even in Java, but you have to explicitly pass the desired dictionary (called a "trait") at all call sites. [0]
I legitimately use traits all the time in Java, and it even has some built-in ones, like Comparator. There's a great paper on the same fundamental technique at [1] (there called "object algebras").
[0] https://www.haskellforall.com/2012/05/scrap-your-type-classe...
[1] https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf
For example, Java lacks higher-kinding which is needed to define a monad abstractly. This can be got cheated around using ideas from this paper (0), but it costs a cast which the compiler cannot prove safe. This is the basis for things like the arrow library in Kotlin, which while impressive, doesn't compare to the ergonomics of Haskell and still misses a bunch of standard abstractions such as Traversable, which are part of the mentioned infrastructure that makes monads (1) so useful to Haskellers.
[0] https://ocamllabs.io/higher/lightweight-higher-kinded-polymo...
[1] applicative functors more generally.
Your behavior is precisely the behavior that someone new to FP would see and say "Hard pass on that", which goes into the greater problem of FP being unapproachable to beginners because of the unnecessary gatekeeping. If you cannot communicate with a beginner in language they understand, A.) you don't really understand it either, B.) you're just pushing them away from whatever you're advocating.