This post is literally the "Ackchyually" meme. There is a reason why "fast and loose reasoning is morally correct".
Haskell is not category theory
31–40 of 54 posts
Re: Haskell is not category theory
#32> If you are looking to learn the language, I recommend Learn You A Haskell. I definitely don't recommend this. While cute, Learn You A Haskell is lacking a lot of pragmatic advice about how to write software in haskell. It's good for getting you up to the FAM trio of type classes but leaves out a lot of practical advice around things like navigating base (what to use and ditch from it), the available community libra…
Re: Haskell is not category theory
#33I'm confused by his argument that Haskell functors are only endofunctors because everything is Hask. I thought that even if everything is part of one category, if the input is a different category that is a subset of the one category and transformed to another category, even if a subset of the same category, it could still be a regular functor instead of an endofunctor. For example, lets say you had a function f(x) t…
I believe the heart of what you're asking is "why do we distinguish between codomain and range?" and relatedly why do we even need the concept of "surjectivity?" For example, the function f(x) = x + x could be thought of a non-surjective "endo-"function (endomorphism) `N -> N` (where N is the natural numbers) or it could be thought of as a surjective function from `N -> E` (where E is the even natural numbers). Why d…
Re: Haskell is not category theory
#34Earlier quoted context omitted.
You could probably try to talk about functors between subcategories by using classes, though I think there's no way to define a functor from one class to another in Haskell. Slightly more annoying is the fact that Haskell has no real product types and instead does more currying than an Indian takeaway. This makes various constructions in Category theory a bit more annoying than they need to be. If you ever wondered w…
Haskell isn't the functor police! It's on you to define good functors, proving them so would be a totally different endeavour and far more difficult. I would like to understand better the issue with product types though. What do you want to do that you can't currently. By the way, most of my knowledge about the connection between Haskell and Category Theory comes from here: https://bartoszmilewski.com/2014/10/28/cate…
Say you have a multivariate function a: X x Y -> Z, and a functor F. This would give you a function F(a): F(X x Y) -> F(Z). Now this is not really multivariate any more as F(X x Y) is not a product, but products behave quite well in category theory so this is not usually that big a problem, and it turns out that quite a few functors are 'continuous' which means they preserve 'limits' and a product is one such limit, in which case F(X) x F(Y) ~= F(X x Y). In particular all right adjoint functors have this property, which is why adjointness is such an important concept.
Now in Haskell things get slightly more difficult, because you don't have a function a: X x Y -> Z, you've got a function a: X -> (Y => Z). Where Y => Z is an object representing all maps from Y to Z (such an object may or may not exist for any particular category). And to use currying you need something like (X * Y) -> Z and X -> (Y => Z) to be isomorphic. So you don't just need F(X x Y) = F(X) x F(Y), which is fairly innocuous, you need to deal with monoidal categories and monoidal functions between them, which is a heck of a lot more complex. This is where the Applicative stuff comes from.
Now some of the stuff you don't get as easily in Haskell is the stuff relying on basic properties of sum and product types, such as
# The following are the obvious projections for a 2-tuple
proj1 :: (X x Y) -> X
proj2 :: (X x Y) -> Y
# Assuming F(X) x F(Y) exists we get the following for free
(F(proj1) x F(proj2)) :: F(X x Y) -> F(X) x F(Y)
No clue how you'd state that in Haskell. And the following # The following are the obvious projections for a 2-tuple
anX :: X -> (X + Y)
anY :: Y -> (X + Y)
# Assuming F(X) + F(Y) exists we get the following for free
(F(anX) + F(anY)) :: F(X) + F(Y) -> F(X + Y)
where you can interpret X + Y as an 'Either X Y'.Sure you could probably write a function
forall Functor f. Either (f a) (f b) -> f (Either a b)
but it's not that obvious that it should exist, whereas in category theory it's one of the most obvious constructions imaginable and its existence is clear from the definition. And in Haskell you wouldn't think about using products so the first property is probably barely used anywhere (there's probably a right inverse for zip somewhere: unzip :: [(a,b)] -> ([a],[b]) but Haskell generally doesn't seem to like functions with multiple outputs.Re: Haskell is not category theory
#35The first thing mathematicians tell you when talking about categories of, say, sets, we have to do some hand waving to avoid Russel's Paradox. In other words even mathematicians have caveats when talking about different aspects of category theory.
In the case of the Functor, we use fmap and not a "function that lifts functions" because it is much more ergonomic. Yet, it is just as "correct" since it is isomorphic to lifting a function and applying it.
With monads we use bind and flatmap although the most obvious categorical implementation would be a simple compose function. That maps more directly to the "category of endofunctors", but again it is isomorphic to the same code that uses flatMap/bind, and the same laws hold.
A lot of utility has been gotten from analogies with category theory and as long as we hold our noses we can ignore the occasional whiff of in-authenticity.
I don't believe that you need to learn category theory to take advantage of the concepts we have borrowed, but it does make everything become more coherent to dig into it a little. It's also a lot of fun if you like that sort of thing.
Re: Haskell is not category theory
#36LYAH is a fun read, but for someone trying to learn the language seriously — by this I just mean more than a casual tour to get an idea of what the language looks and feels like — there are, thankfully, some much better resources and books available these days. No shade to LYAH intended whatsoever, but it's just not what I'd recommend for some undertaking really learning the language. https://haskellbook.com/ is a solid option IMO.
Re: Haskell is not category theory
#37> If you are looking to learn the language, I recommend Learn You A Haskell. I definitely don't recommend this. While cute, Learn You A Haskell is lacking a lot of pragmatic advice about how to write software in haskell. It's good for getting you up to the FAM trio of type classes but leaves out a lot of practical advice around things like navigating base (what to use and ditch from it), the available community libra…
I have tried several times to learn Haskell. The only resource that actually worked for me was Philipp Hagenlocher's "Haskell for Imperative Programmers". It is incredible. He does an amazing job of starting from the basics and then diving deep. After going through the series I had a solid enough grasp on the language to use it for practical things. https://www.youtube.com/watch?v=Vgu82wiiZ90&list=PLe7Ei6viL6...
Re: Haskell is not category theory
#38Earlier quoted context omitted.
> A lot of category theory is fun to learn and knowing it will help you in many ways I agree with your statement except that part. W.r.t coding, learning functional programing will help you in many ways. Learning category theory will just allow you to say "ah I've seen that concept before" - but it won't really help much.
The number of times I’ve heard someone say that some academic topic was not helpful and they were right is close to zero. It’s a pretty good heuristic to not adopt that attitude.
Re: Haskell is not category theory
#39Earlier quoted context omitted.
The number of times I’ve heard someone say that some academic topic was not helpful and they were right is close to zero. It’s a pretty good heuristic to not adopt that attitude.
This statement reads as really weird. You seem to be saying that your opinion and/or experience on the usefulness of academic topics is a good heuristic to use to not adopt an attitude.
“everything everyone else says is useless is useful”
but rather
“rushing to judge something useless is a very noisy predictor of actual uselessness”
Re: Haskell is not category theory
#40And you definitely don't need to learn category theory or know anything about it to start writing programs in Haskell or to maintain and build large Haskell applications. A lot of category theory is fun to learn and knowing it will help you in many ways but it is not a necessary requirement. I mention this because a lot of people seem to think it is. Definitely a nice article for the math-oriented/curious/etc! It's n…
> A lot of category theory is fun to learn and knowing it will help you in many ways I agree with your statement except that part. W.r.t coding, learning functional programing will help you in many ways. Learning category theory will just allow you to say "ah I've seen that concept before" - but it won't really help much.
I haven't found any utility to the CT that is above the scope of Haskell; it feels like if it's too advanced to implement in Haskell, it's too advanced to find a use case anywhere.