This post is literally the "Ackchyually" meme. There is a reason why "fast and loose reasoning is morally correct".
I might be a counterexample to the claim that "this is pedantic and the differences they're mentioning are meaningless in practice". I learned about functors in uni and only later took a look at Haskell. I was genuinely very confused by the naming of Functor: functors map both morphisms and elements, but this isn't the case in Haskell. So I was left wondering whether I had missed something.
Haskell is not category theory
41–50 of 54 posts
Re: Haskell is not category theory
#42And 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.
Re: Haskell is not category theory
#43Re: Haskell is not category theory
#44Re: Haskell is not category theory
#45Earlier 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.
It probably started all the way back in high school with people in the back of the class asking how all this high school maths would help them in real life. Then you get to university and people ask the same in just about every class. Then you get to industry and all the people who had that attitude growing up are calling you for help (and the people who still have that attitude seem to stop learning, or learn at much lower velocity).
It’s always more obvious in hindsight, and particularly with maths: stuff always seems kinda useless before you deeply understand it. That’s unfortunate, because it severely hampers the motivation to learn the stuff in the first place… But it is what it is, I guess.
Even pure mathematicians, who have every incentive to see their own work as immensely useful, are notorious for frequently having no idea just how useful and applicable their work will be in the future (albeit usually over longer time horizons).
My experience is that this is even more true for cross-disciplinary applications, as either discipline naturally is unaware of the perspective of the other discipline. It’s true that it’s important/necessary to specialize deeply and narrowly, but the value of cross-disciplinary skills (especially regarding maths) is probably under-appreciated, IMO.
Re: Haskell is not category theory
#46> 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...
[1]: https://www.youtube.com/channel/UCBDp7ydYTHi1dh4Gnf3VTPA
Re: Haskell is not category theory
#47This post is literally the "Ackchyually" meme. There is a reason why "fast and loose reasoning is morally correct".
Re: Haskell is not category theory
#48> 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
#49And 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.
Re: Haskell is not category theory
#50Earlier quoted context omitted.
I might be a counterexample to the claim that "this is pedantic and the differences they're mentioning are meaningless in practice". I learned about functors in uni and only later took a look at Haskell. I was genuinely very confused by the naming of Functor: functors map both morphisms and elements, but this isn't the case in Haskell. So I was left wondering whether I had missed something.
They actually do. The type constructor maps types to types (which are Hask objects), and `fmap` maps the functions (which are the morphisms).
I meant functors where the objects being mapped aren't types, but type inhabitants, and the morphisms being mapped are not arrows between types, but arrows between type inhabitants. (I suppose this also has to do with "the only category in Haskell is Hask", rather than types also being themselves categories?)