> 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.
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.
> If you cannot communicate with a beginner in language they understand, A.) you don't really understand it either
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.
You have to start with the 'simplified but not technically perfectly correct' and then add in the nuances to get to the real point. Starting with words like 'functors' that most software engineers today will not be able to define is not useful.
The article is likely aimed at intermediate-ish FP programmers, though, not people with no prior knowledge. (Although I suspect it is an example of "learning by teaching", since it is wrong on many counts.)
Learn You a Haskell mentions functors in chapter 8 and teaches them properly in chapter 11.
You don’t have to understand category theory to program in FP languages. But if we want to talk about the mathematical basis, you do need a common vocabulary at least to be able to communicate at all.
You could not really explain JIT compilation to someone not knowing anything about computers, could you?
If such a “definition” is sufficient, than I’m a rocket engineer as well because the rocket goes brr to the space..
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.
Do you provide concrete "definitions" to people that don't/wouldn't understand? How would you handle a child asking you about something beyond their years? Would you just respond with a textbook definition and say "lol sucks to suck"? No, you'd use language they could understand, and you'd guide them as that language increased. This is the difference between "teaching" and "just saying things to sound smart".
It's actually insane how hard programmers want to gatekeep even basic concepts.
Well, no matter what you won’t be explaining multivariable calculus to a children. Concepts build on each other and for certain ones, you do have to build from something. You can start teaching math, and indeed for certain topics, taking shortcuts is allowable. But this is context-dependent and not universally true.
Like, you can talk about programming to a child, but still not about JIT compilation.
Communication is a two-way street. When someone is making an effort to learn, most FP advocates will happily make an effort to teach. But someone who comes in with guns blazing doesn't get to complain about being met with hostility, and if telling someone they're wrong when they're wrong is gatekeeping then it's a kind of gatekeeping that we need.
Being a teacher is a labor of love. There’s nothing wrong with a student coming in with any attitude.
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.
> There’s nothing wrong with a student coming in with any attitude.
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.
Yes, that goes for teachers. Not normal working programmers who choose to discuss FP in the terminology which has been commonplace for decades. They are under no such obligation.
A Q&A website needs both people who ask questions, and people who answer them. Perhaps the latter even more than the former. You can ask a question on stackexchange and have it answered by Peter Shor. Not having the platform inundadated by dumb repetitive questions and homework problems is the compromise you need to retain such talented people on your platform.
If you want an example of what happens to a Q&A site without any gatekeeping, look at Quora.
I would say the person you're responding to didn't come in "guns blazing". They seemed legitimately eager to learn, and expressed gratitude that the person that wrote the blog post used language they could understand.
Now, I would say you showing up and openly disparaging both the blog and the person you responded to qualifies as "guns blazing".
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." That's pretty "guns blazing" in my book.
> "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."
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).
> A person shows up eager to learn, expresses gratitude, feels scorned at all of the language-based gatekeeping that goes into this topic.
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.
You'll notice that the post you quote was a reply to their post, where, as I said:
> 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.
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."
So you would say the same for programming in general then? Should programmers not use the word "function" because that word is foreign to non-programmers and might push them away?
Some terms are used for radically new concepts with no analogue, some terms refer almost exactly to concepts people already know, and some terms refer approximately to concepts people already know (and could be explained as "like X but with these differences")
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.
I actually agree with this much. Explaining monads before explaining a lot of concrete examples of monads is putting the cart before the horse, and is where a lot of these tutorials go wrong (https://m50d.github.io/2013/01/16/generic-contexts is my own effort at taking the opposite approach). But calling something a functor when it isn't is extremely unhelpful; the whole point of using a special-purpose term like functor is to be very precise about what it is and isn't, and to avoid intuitions that would be misleading.
It often makes me very mad that so much gatekeeping has been sown into programming circles through the invention of pointlessly-obfuscated terminology for everything. Programmers are really arrogant most of the time, they dont want to teach beginners their craft so they just make everything difficult on purpose. They are like medieval priests yada yada.
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.
Generalizations are always imperfect, and I felt I was explicit about the fact that there are exceptions (like the OP).
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.
I am a self taught programmer who first learned python and then learned Haskell. A lot of concepts in python were difficult when I was new and the same is true for Haskell. I found the Haskell community to be very welcoming and very willing to explain their terms and the reasoning behind them, and I dont find the negative characterizing from you and others about them to be true at all. That's why it really bothers me how you and others are so willing to slander a whole community based on what I perceive as not the truth at all. That's also why I wonder if you would be ok with non-programmers making the same generalization about programmers.
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.
Good points. But I'd note that Haskell's infrastructure around Functor isn't typical of functional languages. Specifically in Haskell, I think it's pretty important to have an idea what functors, monoids and monads are, because these are typeclasses that you will almost certainly be using at some point. 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.
I agree with your overall point, but I want to dig in on this bit:
> 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").
It's certainly possible to express some of these ideas in other languages, but implementations are nowhere near as ubiquitous or idiomatic as in Haskell, where they pervade the standard library and most people's code. And I'd argue that's because the ergonomics of the solutions in other languages don't come close to those of Haskell's. Furthermore, there appear to be limits to how far you can take them.
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.
It's tricky with functional programming. It's like reading SICP, and after a lot of effort, y-combinators and stuff, the outcome is like "See? Thanks to this invention, we can easily pass multiple parameters into a function". Which is fun, but not anything that will impress a non-functional programming user.
This is not an unusual thing to see around foundations of mathematics, either - where it could take dozens of pages filled with complicated argument and construction before one eventually can say, “We can multiply these integers now!”
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.