Thinking that you need to learn "Category Theory" in order write Haskell is like saying you need to read George Boole's 'Investigation of the Laws of Thought' (1854) in order to write a conditional statement.
In other words, it's not.
"Category Theory" is for mathematicians and people interested in highly abstract mathematical theory. It doesn't help you write Haskell programs.
Never did I assert the need to learn category theory to write Haskell. I was speaking of my own experience and if you can understand the underlying category and type theory that goes on behind the scenes implicitly and can write Haskell programs without ever thinking of the theory behind them that is awesome. Personally I don’t like languages that feel like magic so I strive to learn what is behind the abstractions and for me that meant getting a deeper understanding of category theory. Furthermore I feel as a computer scientist the more math I can learn and absorb the deeper my understanding grows on a multitude of subjects. Sorry if my post came off as flipped I was simply trying to use humour to accentuate the difference in the conceptualization of Haskell vs. a non-pure procedural language.
You need it for a deeper understanding of type classes and algebraic data types. You can get by without it but I would say your understanding of things like a "functor" will be flawed.
This is not true. For example, The typeclassopedia contains all you need to know about functors and doesn't go into detail about the underlying Category Theory.
Agreed. Having worked closely with them, I would say such Haskell luminaries as Simon PJ, Lennart Augustsson and Neil Mitchell have not "learned category theory" (and I don't think I'm being too offensive to them if I state that). In fact the only figure of highest repute in the community who puts much stock in category theory is Edward Kmett.
"The wise student will focus their attention on definitions and examples, without leaning too heavily on any particular metaphor. Intuition will come, in time, on its own."
typeclassopedia admits that the intuition is missing. I would go on to argue that just going from the definition alone you would think that a functor is anything that is mappable and that fmap simply maps a function across a functor to produce a new functor.
The intuition that cannot be grasped without some category theory is that fmap actually lifts a regular function of standard types into a function between functors. A functor is more than just fmaps.
you draw the wrong conclusion from that excerpt. It does not say "Intuition that cannot be grasped without some category theory". It is saying that you need to see many concrete examples to learning something abstract. This is how it works in all of education basically, and there's isn't an easy substitute. Learning "category theory" will not replace your need to see concrete examples to grok something inherently abstract. You'll have to go through the concrete examples anyway.
Those concrete examples aren't visible until you do category theory. That is what I'm saying. You are drawing the wrong conclusions.
There is literally not enough information from the definition of the type class Functor and from examples of usages of that definition for a programmer to truly understand the concept of a functor. That is the conclusion I am deriving. It is not wrong. You are wrong. What's going on is you are deriving a conclusion convenient to your view point.
Sure you can get by programming haskell without category theory just like you can program without knowing the notion of an algorithm. However in both cases you are worse off without the knowledge.
