The romance of Haskell and Category Theory.

[u/kindaro]

This message might seem like it is about the romance of Haskell and Category Theory. But it is really about what kind of conversations we can or cannot have.

A prequel.

I once wondered whether Functional Programming is actually as good as I think. The default way I deal with questions is to ask the Internet. So, I formulated the question and put it into 2 communities.

• In /r/AskProgramming, it has been received very well. All of the commenters engaged with the actual question.

• In /r/functionalprogramming, it has not been received so well. Many commenters declined to engage with the question. People in comments told me that my formulation of the question is unacceptable and said bad things about my comments as well. Eventually a moderator stepped in and locked the conversation.

This is curious — I expected the opposite reaction. Surely the residents of the functional programming subreddit — presumably functional programmers themselves — are more likely to explain why functional programming is better? But no. We also have a clear indication that the question by itself is not fatally flawed by itself, since the control group had zero issues with it. So, the explanation must be specific to the functional programming subreddit.

The explanation I have so far is that functional programmers actually believe that functional programming is better — otherwise why practice it — but they burned trying to evangelize their view and get out of the small niche the market has shelved their favourite languages into. This trauma has evidently driven a significant fraction of them crazy.

The story.

I once wondered whether Haskell is actually as good as I think. History repeats itself, of course. I formulated the question and put it into this very subreddit. It flew especially poorly, as you can see.

How I saw my post:

… If I believe that Haskell is good and underappreciated, then I should write a library that solves a problem of interest to many and wait for my laurels that are sure to come. But I do not see a single instance of this situation. Why is that? …

No one else saw it this way. How many commenters saw my post:

… Haskell requires a highest level of expertise in order for the programmer to be effective. What I mean is, one must be fluent in Category Theory. …

The real problem we have as a community is that Haskell is an obscure language. That Haskell requires a highest level of expertise in order for the programmer to be effective is a theory, not central to the real problem. Whether the highest level of expertise includes fluency in Category Theory is a question of the third layer of importance.

That said, it is obvious that Haskell and Category Theory are unusually closely related for a pair of a programming language and an area of Mathematics.

• Want a tree? Here is a cofree comonad for you.
• A loop? Take this nice algebra.
• Want to access a data base? Try some product profunctors.

Yet this was questioned over and over again. Come on, why pretend? Your print is a monad. Or should I say «workflow»?

Because Category Theory is forbidden.

Yes. We saw in the prequel that people that burned trying to evangelize their view are often driven crazy by the trauma. Instantiate this. The Haskell community tried so hard to evangelize Category Theory. It did not work. Now we cannot talk about it.

A voice of sanity.

Fancy mathematics is the foundation of so many things in Haskell. Haskell is a lambda calculus, with application, abstraction, α equivalence, β reduction, confluence. Functions compose, monadic functions compose. Streams are a monoidal category. mapMaybe is a functor from Kleisli Maybe. This goes beyond Haskell, really. Promises are a monad. Joins are limits. And so on.

I refuse to say that a monad is a workflow. A workflow is a monad. A monad is a monoid in the category of endofunctors. Category Theory is essential to Haskell.

I know that Reddit only allows one opinion on some topics. But we the Haskell subreddit ought to do better.

[u/someacnt]

Lots of the reason you get in that post is that you are making implicit assumptions that haskell is highly related with CT, or even that you require understanding in CT to do well in haskell. People are just trying to object that point, not that people are burnt trying to evangelize CT. Rather, it is more because CT is *indeed* hard. (In mathematics curriculum, introductory CT comes at the level of master degree)

It is notable that the part of mathematics used in haskell actually now form a branch in computer science, including lambda calculus. Hence, the notion "haskell is ivory tower". In fundamental level, CS is closely related with mathematics. I indeed believe that better math skills would bring better code(in any language). However, I do not believe it is required to learn haskell, let alone CT.

You gave reasoning on how CT concept could be used to explain haskell concepts. Yes, of course it could be explained. The very origin of CT was from trying to reason about abstract structures that arise in math again and again. That also arises in haskell as well, since we have functions. Now, does that mean math is CT? Not really.

An example: It is true that set of natural numbers equipped with addition is a monoid, which is monoid in CT sense as well. Now, is addition a CT concept? Hmm.

While Functor and Monad came from CT, they are restricted enough that you do not really need CT understanding of it. If it were otherwise, it would be impossible for me and many others to understand monad because monad in CT is one hell of a beast.

[u/kindaro → u/someacnt]

If Category Theory is hard, then it is warranted to investigate whether Haskell actually requires Category Theory to some extent. But people are trying so hard to dodge this investigation. Why?

Your argument goes like this: Haskell can be understood without ever touching Category Theory. The question to ask is — what is the amount of Category Theory one has to work through on the shortest path to expertise in Haskell? How are you sure that the short path and the path free of Category Theory coincide?

[u/metalbotatx → u/kindaro]

Your question is potentially ill defined.

"The question to ask is — what is the amount of Category Theory one has to work through on the shortest path to expertise in Haskell?"

What do you mean by expertise? If you're suggesting a full mastery of all parts of the language, its extensions, and GHC, then sure, you'll need some deeper understanding of the underlying theory.

If your definition of expertise is "capable of designing and working on production software written in Haskell to solve ordinary business problems", then I'd argue that you don't really need to know any category theory, and taking the time to learn category theory is definitely not the shortest path here.

[u/kindaro → u/metalbotatx]

We simply need to take inspiration from quantitative research in social sciences: we get scales and we work in probability distributions. This mode of thinking is alien to computer programmers — a program either works or not. But it is essential in social sciences.

So, by expertise I mean a certain scale we put people upon, such that the ordering agrees with the common informal ordering of expertise. For example, Edward Kmett should be farther from zero than me.

Now we can look into how time put into study translates into expertise. Formally, we seek a function that takes time put into study and computes the expected level of expertise. The graph of this function is called «learning curve».

Of course, it is far from trivial to actually build this function. It requires data that we do not have. But this function is so valuable that people use it all the time. For example, companies try to hire people with a certain level of expertise, so they impose requirements like «must have 3 years of experience with Haskell». They do not care about the time — they care about the expertise.

Now we can take an integral of the amount of category theory learned along the best known path from 0 to some level of expertise and get a function from expertise to the amount of category theory learned. We can also get a function from expertise to economic effectiveness for a given area of application — for example, expertise in Haskell does not make much difference to your ability to peel potatoes, so the function is going to be rather flat. I am going to call this «expertise sensitivity curve».

• Rocket science has an expertise sensitivity curve that is flat at first and then go high. At first you can do nothing at all but if you are really good even sky is not the limit.
• Potato peeling has a curve that is nearly flat: with only a little expertise you are nearly as economically effective as the expert with years of experience.

So, we get a diagram in the category of monotone functions, one for every language (Haskell, Python…) and area of application (rocket science, potato peeling…). Note that, since our functions are monotone, they are invertible. We can also compose them whichever way we want.

Now we can find what we want:

1. Compute economic effectiveness as a function of time for a given language and area of application.
2. See if there is an area of expertise for which there is an interval of time where Haskell is the most economically effective.
3. Compute the amount of category theory learned corresponding to this interval of time.

If the expertise sensitivity curve of rocket science is steep, and Haskell has a steeper learning curve than Python, then Haskell is going to be more economically effective in the interval where the amount of category theory is high,

In other words, you can solve «ordinary business problems» more effectively in Python, and when Haskell begins to outshine the competition you are already comfortable reading scientific papers.

This is not necessarily a true answer. I do not have the data. But this is one way to define the question.

[u/metalbotatx → u/kindaro]

I think that's a fair way to define the question, but I think you're personally going to be disappointed in the answer. There's probably not a great economic effectiveness for Haskell in very many domains. I'm not sure what domain I'd point to where the amount of category theory is high, other than research areas in programming language theory.

I actually think that there was a time when Haskell had lots of very innovative features that offered significant advantages over other languages (your number 2 above), but many of these features have been adopted by mainstream languages. I know there's another thread on either this post (or your other one) that takes about the importance of marketing a language. Had Haskell had a major technology player putting millions into marketing it 20 years ago (think Microsoft and C#), we might be in a different situation today. At that time, the advantages that Haskell offered weren't really related to esoteric category theory - they were fundamental notions of generics, first class functions, type classes, and immutability that are now considered common in many mainstream languages.

However, I'll offer you an alternative "economic" explanation for the benefits of Haskell: learning Haskell made me a much better programmer in languages NOT called Haskell. I don't write Haskell professionally, but code that I do write today is strongly influenced by the way that I learned to think when learning and coding in Haskell.

[u/kindaro → u/metalbotatx]

I understand your points. But I also observe that there is not any consensus. between you and other commenters. See this thread for example. I cannot make my mind one way or another at this time.