3 ms·

A question for those of you here who are into functional programming: Is category theory worth studying if I (coming from c++ background) am looking to get int

A question for those of you here who are into functional programming: Is category theory worth studying if I (coming from c++ background) am looking to get into functional languages like Haskell? How common is it actually among Haskell or Lisp programmers to know and utilize concepts from category theory in their programming?

mrkgnao 9y ago
A lot of the ideas used in everyday Haskell originated in category theory (similarly to how all our programming languages eventually come from Turing machines, the lambda calculus, and so on), but command over the mathematical ideas is absolutely not required to "get into Haskell" or even to use it productively and fluently. It is certainly something you should look into if you want to a) know why some things are done the way they are (in case you're not satisfied with "this works!"), or b) if you want to find inspiration to write a certain kind of library: Haskell is one of the few languages that has, as I like to call it, "over 50 years of documentation". -- To elaborate: a category is a bunch of objects, and functions (morphisms) between the objects. The types in a language like Haskell form a category (called Hask in this case) where the objects are the types and morphisms from one type to another are the functions that go from the former to the latter. A lot of things done in Haskell are instances of general constructions from category theory applied to Hask. Comfort with these general constructions certainly helps to illuminate many ideas. For example, the great trifecta of Haskell abstractions comprises three interfaces ("typeclasses") called Functor, Applicative, and Monad, which are used everywhere. Each of these corresponds to a concept from category theory: for instance, what a Haskeller calls a "Functor" is what is categorically called an "endofunctor on Hask". Among users of the language who know any category theory at all, most have some familiarity with things at the level of what I've just said, but not much more. A knowledge of category theory at any higher level (like in the linked repo) is not at all common, statistically. Also, not many of the common libraries are based on deep categorical ideas (lens [0] is an important exception) but even then, knowledge of the mathematics is useful if you want to dig into how the ideas are implemented, not if you're happy just using them. Learn as little or as much as you'd like. [0] https://github.com/ekmett/lens/wiki/Examples https://github.com/ekmett/lens/wiki/Examples
- MikkoFinell 9y ago
  Thank you, that was very illuminating.
  - mrkgnao 9y ago
    You're welcome! http://haskellbook.com/ http://haskellbook.com/ is the currently recommended book and is worth looking at when you start learning.
runeks 9y ago
It depends on what you’re interested in about programming. Do you like the research aspect of programming languages (inventing new language stuff) or are you into application programming (e.g. writing an app)? Category theory is the lowest level of functional programming. At this low level you can do some pretty ground-breaking stuff (like the Haskell z3cat[1] library which can apply a SAT solver to a regular Haskell function), but it’s not required, in any way, in order to write great Haskell code, and make use of Haskell as a tool to write applications with very few runtime exceptions. [1] https://github.com/jwiegley/z3cat https://github.com/jwiegley/z3cat
tel 9y ago
"looking to get into..." -- No, not at all. It will lead you down a long rabbit hole that doesn't actually wind up anywhere too close to functional programming. CT is great for "looking to get really good at" FP. It writes out a parallel universe where certain things are easier and certain things are harder but the same core pillars of FP are intact. In this parallel universe there are myriad examples of constructions, techniques, and conceptual frameworks which can be "ported" back to FP. Likewise, some FP concepts have interesting "ported" versions in CT. Learn CT when you want to build intuition for how to construct functional architecture. Don't learn it to start and don't even learn it when you run into Functor/Applicative/Monad. It's _not_ useful for understanding them in practical terms. Go learn it when you start composing higher level constructions together comfortably and start running into questions about the most efficient ways to lay things out. It's _great_ for that.

mrkgnao 9y ago

A lot of the ideas used in everyday Haskell originated in category theory (similarly to how all our programming languages eventually come from Turing machines, the lambda calculus, and so on), but command over the mathematical ideas is absolutely not required to "get into Haskell" or even to use it productively and fluently. It is certainly something you should look into if you want to a) know why some things are done the way they are (in case you're not satisfied with "this works!"), or b) if you want to find inspiration to write a certain kind of library: Haskell is one of the few languages that has, as I like to call it, "over 50 years of documentation". -- To elaborate: a category is a bunch of objects, and functions (morphisms) between the objects. The types in a language like Haskell form a category (called Hask in this case) where the objects are the types and morphisms from one type to another are the functions that go from the former to the latter. A lot of things done in Haskell are instances of general constructions from category theory applied to Hask. Comfort with these general constructions certainly helps to illuminate many ideas. For example, the great trifecta of Haskell abstractions comprises three interfaces ("typeclasses") called Functor, Applicative, and Monad, which are used everywhere. Each of these corresponds to a concept from category theory: for instance, what a Haskeller calls a "Functor" is what is categorically called an "endofunctor on Hask". Among users of the language who know any category theory at all, most have some familiarity with things at the level of what I've just said, but not much more. A knowledge of category theory at any higher level (like in the linked repo) is not at all common, statistically. Also, not many of the common libraries are based on deep categorical ideas (lens [0] is an important exception) but even then, knowledge of the mathematics is useful if you want to dig into how the ideas are implemented, not if you're happy just using them. Learn as little or as much as you'd like. [0] https://github.com/ekmett/lens/wiki/Examples https://github.com/ekmett/lens/wiki/Examples

MikkoFinell 9y ago
Thank you, that was very illuminating.
- mrkgnao 9y ago
  You're welcome! http://haskellbook.com/ http://haskellbook.com/ is the currently recommended book and is worth looking at when you start learning.

runeks 9y ago

It depends on what you’re interested in about programming. Do you like the research aspect of programming languages (inventing new language stuff) or are you into application programming (e.g. writing an app)? Category theory is the lowest level of functional programming. At this low level you can do some pretty ground-breaking stuff (like the Haskell z3cat[1] library which can apply a SAT solver to a regular Haskell function), but it’s not required, in any way, in order to write great Haskell code, and make use of Haskell as a tool to write applications with very few runtime exceptions. [1] https://github.com/jwiegley/z3cat https://github.com/jwiegley/z3cat

tel 9y ago

"looking to get into..." -- No, not at all. It will lead you down a long rabbit hole that doesn't actually wind up anywhere too close to functional programming. CT is great for "looking to get really good at" FP. It writes out a parallel universe where certain things are easier and certain things are harder but the same core pillars of FP are intact. In this parallel universe there are myriad examples of constructions, techniques, and conceptual frameworks which can be "ported" back to FP. Likewise, some FP concepts have interesting "ported" versions in CT. Learn CT when you want to build intuition for how to construct functional architecture. Don't learn it to start and don't even learn it when you run into Functor/Applicative/Monad. It's _not_ useful for understanding them in practical terms. Go learn it when you start composing higher level constructions together comfortably and start running into questions about the most efficient ways to lay things out. It's _great_ for that.