I've had someone do that on this very website. I was assured that affine types in Rust are too difficult to understand without a solid grounding in Category Theory.
The years have proven that ease of programming and the burden of knowledge are the two most important elements of a programming language. FP zealots simply won't accept that their chosen paradigm is opaque to most for benefits that can't seem to be written out in human language.
On this website you will hear anyone say the wildest assertions. There's the whole human range of expression here. But what makes you think actual FP practitioners (and Haskelers) really believe this?
The proof wouldn't be what some random person here on HN tells you. The proof would be you getting involved in an actual FP community trying to write an actual FP project and being told that you just cannot do this unless you understand category theory. Which, as I said, is not something that happens... at least not in my (limited) experience.
Never confuse what people tell you here on HN, random forums or even throwaway StackOverflow comments with what actually happens in the actual communities when trying to achieve real goals and not just chat about stuff.
But why is it funny? Isn't it funny because the community knows it comes off that way, at least some of the time (and/or some of the people)?
> Nobody claims you have to understand category theory to write Haskell.
I've seem the claim that you can't really use Haskell without it, here on HN, more than once. (Or at least something that I interpreted as being that claim...)
It's funny because the community knows some people too deep in the rabbit hole come across that way, but because the community acknowledges this is a hilarious assertion that would alienate newcomers -- if said with a straight face -- then it cannot be gatekeeping.
Gatekeeping would be if the community said this with a straight face and everyone got impatient when you just "don't get it".
> I've seem the claim that you can't really use Haskell without [knowing category theory], here on HN, more than once
I've almost never come across this assertion; it's certainly not common in the community (or wasn't when I was learning Haskell). I can tell you it's certainly false: you can very well write Haskell without knowing or studying category theory.
Well, try understanding the Haskell docs around Applicative, Functor or Monad without understanding at least basic category theory - not to mention the heavy use of notation/operators in place of traditional programming idioms (named functions).
Here [0] is an example:
> This module describes a structure intermediate between a functor and a monad (technically, a strong lax monoidal functor). Compared with monads, this interface lacks the full power of the binding operation >>= [...]
Counterpoint: I learned about Applicative, Functor and Monad by reading docs and tutorials, and I haven't the faintest idea about category theory.
These are the building blocks of Haskell. You learn them as you go, just as you learn what a "method" is when learning OOP. You don't need to know category theory.
Learning what Applicative, Functor and Monad are is category theory. It's like saying "you can learn how to do unions, intersections, and differences on collections of unique objects without understanding set theory".
That seems a little silly to me and I think we're splitting hairs with what it means to do category/set theory. I don't know category or set theory, so I hope you will forgive me for using yet another allegory.
Let's say I make a type class for Groups (in the abstract algebra sense). The rationale behind this is that there's an algorithm for exponentiation which is O(log(n)) versus the naive O(n) algorithm. So if you make an instance that's a Group, you get to use this fast exponentiation.
Sure, to understand and use this type class you have to understand what a Group is. However, I think it's a bit of a stretch to tell someone "in order to use Group you must first learn abstract algebra" because they'll think you're telling them to take a university level course. In actuality, they don't have to know much at all (they don't even need to understand _why_ the exponentiation algorithm works) - they just need to know what is a lawful Group.
The first day of the intro to abstract algebra course I took introduced much more information than you'd need to use this made up type class, and I expect the same of the others.
Like this is my understanding of Functors/Applicatives/Monads. I kind of know their shape and how to use them. If you asked me about any of the underlying math I would shrug and maybe draw a pig (https://bartoszmilewski.com/2014/10/28/category-theory-for-p...).
That's not really true. When some people claim you must learn category theory to use Haskell, they mean they have to learn the math-subject-capital-letter Category Theory, which goes way beyond programming and comes with a lot of baggage.
They never mean you have to learn Functor, Applicative, etc as used in Haskell and taught in every tutorial. If they did mean the latter, it would be a tautology, which is not very useful.
Compare "in order to do OOP you have to learn what an object truly is, its essence, and possibly take some courses on the philosophy of being" vs "you have to learn about methods and objects".
> It's like saying "you can learn how to do unions, intersections, and differences on collections of unique objects without understanding set theory".
You can totally do unions, intersections and differences without knowing set theory.
The saying "a monad is just a monoid..." is a cliché and an in-joke, not gatekeeping. It's the community having a laugh at itself.