7 ms·

Can someone please explain to me the excitement for category theory in this forum? I've gone through the first 10 chapters + exercises of this book, and truth

Can someone please explain to me the excitement for category theory in this forum? I've gone through the first 10 chapters + exercises of this book, and truth be told the content is interesting but the ROI is low for programming (FWIW I started this book as part of a study group in a large unicorn co, and after approximately one month I was the only person left grinding through the exercises, hoping for some payoff). It's cool that I know what a functor is, I guess, but where others tout CT as unlocking a higher level view of programming, all I see are little curiosities (when you do X you are really doing Y, isn't that cool!?). I've heard it said that CT's true power comes as a "refactorer" for what would otherwise be complicated proofs. I.E. we discovered a new tool to make proofs that already existed more elegant. That's cool that it has a use! Does this somehow extend to programming? I don't mean to sound like a grouch, but I'm genuinely baffled by the level of excitement around this topic. If you're looking to scratch a math itch, ML has plenty of opportunities to hobby some math while advancing your career and marketability. For programming in general, there are tens of topics I would pick before reaching for this, with major immediate payoff to our occupation as programmers. Finally, after going through 10 chapters I skipped to the end to see if there was some culminating breakthrough that we were striving towards... and I found more definitions stacked upon other definitions. I suppose memorizing all these definitions is supposed to give me a different mental model about programming. Is that right? I'll quote here the first line of the Analects, "Isn't it a pleasure to study and practice what you have learned?". This is what I look for in studying any topic: something that gives me joy to put into use. In the best cases it gives me a feeling of a super power - something that was previously impossible or extremely difficult is now elegant and clear. Can CT offer that in any way to programming? -Sincerly, Guy that doesn't get it, but wants to

zug_zug 7y ago
As a functional programmer myself, I have the same confusion. As best I can tell, category-theory a cargo-cult thing ("I want to look like the type of engineer who CARES about monoids [because if I use words you don't know I'm smart]" much in the same way hipsters claimed vinyl sounds better). I'd like to be wrong about this, but I've already met a handful of "phonies" who rant and rave about this stuff, but when I ask them "How does labeling an array a monad help me?" or even "Is a hash-map a monad?" they are completely stuck.
- crimsonalucard 7y ago
  Label the string as a functor and think about lifting the array into the string functor and doing string manipulation to change it to a dict, then lift it back into a dict type. String manipulations of a lifted type in "string space" can be faster and more efficient then actually manipulating it in "type space"
  - edflsafoiewq 7y ago
    What?
    - alexandercrohde 7y ago
      This is exactly what I mean. I can't tell if that's a joke or not.
      - crimsonalucard 7y ago
        Not a joke. Take a look at my response to the other guy. I clarified my point with a thorough example. Please note that I was somewhere else and on the phone when I typed my initial response so forgive me for the brevity and lack of clarity. Hopefully the new response will clear things up. Anyway... I think theres a good chance that you simply aren't grasping what the category theory fans are saying. Hopefully you grasped what I'm saying.
    - crimsonalucard 7y ago
      Apologies. I was on the phone typing the above. Still, remarks like "What?" that provide no information or context are against the rules on HN. Just FYI. The OP said that there's no point in labeling an arbitrary type as a functor or monadic value. I'm going to use an example to illustrate how there is a benefit in being aware of this concept. I will be using a "String Monad" in my example. Imagine you have some type, like in the initial example. And you want to convert that type into another type. I'll give you an arbitrary example using python: You want to convert this: {1:2 ,3:4, 5:6, 7:8} To this: [1,2,3,4,5,6,7,8] You can do this via loops or you can "lift" the dictionary type from "type space" to "string space" via the python functor str(): lifted_dictionary = str({1:2 ,3:4, 5:6, 7:8}) This is similar to movement between two categories or objects via a functor. You see similar techniques in other fields of engineering when say someone "lifts" something from cartesian coordinates to polar coordinates. Which is why I'm using the word "space" it's similar to how I'm shifting representations of coordinates to have an easier time with certain calculations. Then you do your type manipulations in "string space" rather then on the type itself. So it all ends up being string manipulation operations to get from the string "{1:2 ,3:4, 5:6, 7:8}" to the string "[1,2,3,4,5,6,7,8]". I didn't use regexp in the example below but you get a huge performance boost if you use that instead. lifted_array = "{1:2 ,3:4, 5:6, 7:8}".replace('{','[').replace('}',']').replace(':',', ') #computed value is a string of the form: "[1,2,3,4,5,6,7,8]" Then you use the opposite functor from str() to lift the value back into "type space" array = eval(lifted_array) Here eval() is the opposite functor to str() Type conversion complete. The full code: original_dict = {1:2 ,3:4, 5:6, 7:8} array = eval(str(original_dict).replace('{','[').replace('}',']').replace(':',', ')) #value of array is [1,2,3,4,5,6,7,8] Essentially you use functors to lift your data structures into other categories for easier conversion, then you simply bring the stringified type back down into regular "type space". So in short I took types and lifted it into the String Monad or "String Category" or whatever you want to call it, then brought back down into types. It seems like an arbitrary way to do type conversion but using regexp to do string manipulation in place of a for loop that unrolls the dictionary is more performant and faster. Think about preserving order as well. When I convert the dict type into string space, ordinal properties of the string itself will be enforced on the dict. SO the keys in the dict will follow the order they appear in the string as will the array string that it is converted to. This technique utilizes category theory. The categories you are lifting to must be isomorphic to the origin category, you must understand the notion of functors (or monadic values) to really get it.
philzook 7y ago
I think I've got the category bug. I very much was intrigued by Milewski's course and found that it made things happening in Haskell make more sense to me. There are a couple of things that really excited me. Conal Elliott's compiling to categories. Categories make a great intermediate representation for DSLs. They are very easy to manipulate/optimize in a simple algebraic manner without issues related to named variables. This proposal showed how a plugin could take ordinary programs written in more user friendly syntax and compile it to the category IR. You can overload ordinary programs to automatically differentiable programs and more. http://conal.net/papers/compiling-to-categories/ http://conal.net/papers/compiling-to-categories/ Another thing I think is really interesting is calculating programs. It is possible in the right formalism to write down a specification of a program in a simple small form, and use algebraic manipulation to derive an executable form of the program. It feels like doing an integral or something. Check out these books on that topic. https://themattchan.com/docs/algprog.pdf https://themattchan.com/docs/algprog.pdf http://www4.di.uminho.pt/~jno/ps/pdbc.pdf http://www4.di.uminho.pt/~jno/ps/pdbc.pdf
- runeks 7y ago
  Great example! Here’s a video where Conal demonstrates interpreting a Haskell program (actual Haskell, not a DSL) into a) an image of a graph-like structure (visualizing the algorithm), b) Verilog (for compiling to hardware), and c) GLSL (for being rendered by a GPU in the browser). https://youtu.be/vzLK_xE9Zy8 https://youtu.be/vzLK_xE9Zy8
6gvONxR4sf7o 7y ago
It's a really interesting way to think about things, that's pretty unlike other ways to think about things, and yet you can use it as a viewpoint for so many other things. It's intellectually really neat and marginally useful. More useful in certain programming communities.
playing_colours 7y ago
I think it is a similar kind of excitement people have when learning Haskell and functional programming: pleasure to experience the aesthetics of pure forms, distilled mathematical concepts, that contrast with impurity and mess of real world coding. I see some practical benefits from studying Category Theory and Pure Mathematics in general: mental patterns, some limited applications in general, interesting application in specific problems, but it requires huge investment of time, and, frankly, there are much more practical applied areas in maths that can bring food on the table: optimizations, probability, linear algebra, fluid dynamics, Fourier transforms. One usually does not ask questions about applicability when decides to study Pure Maths, it is a passion driven adventure: https://en.m.wikipedia.org/wiki/A_Mathematician's_Apology https://en.m.wikipedia.org/wiki/A_Mathematician's_Apology
CuriousSkeptic 7y ago
Here’s maybe one attempt at answer https://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory/ https://blog.ploeh.dk/2017/10/04/from-design-patterns-to-cat... As I take it the hope isn’t that all programmers would learn CT but rather that those who work on progressing the craft and our tools get at a proper formalism to work with for certain aspects that until now has been rather “soft”
mathgenius 7y ago
> the content is interesting but the ROI is low ... Even mathematicians themselves have had this view, for a long time. The attitude appears to be "hey I'm doing my good calculations here, why should I be messing around with arrows?" Theoretical physicists are now getting involved in this debate aswell. So it's a much bigger complaint than "how is this going to give me better programs?" I've thought so much about this, I don't really know where to start. The functional programming stuff is nice, but it is only one manifestation of CT ideas. Probably, if you are any good at programming you are already "doing" CT. Anytime you have a class invariant, you are "doing" category theory. The methods are preserving some kind of structure (the class invariant.) And that is the key idea behind OOP. That is what it means to have an object and not just a bucket of data. FP does this too but in a strict way; nothing is mutable. The revelation of CT is how deep (or wide?) these ideas are, but maybe the only thing you get from this is the satori.
lopsidedBrain 7y ago
I didn't read the book yet, but I'll take a crack with a couple of examples: Unix file systems, and its philosophy of "everything is a file". It wasn't common before Unix to interact with devices through a filesystem. Somebody noticed that simple tasks like "listing with ls" and "hex-dumping with xxd" doesn't need separate utilities for files vs devices, and thus made the abstractions converge. If you ask me, this is the kind of abstraction I wouldn't normally think of. It's useful to know what kind of things to be on the lookout for. The second example is fuzzing. At least today, it's still kind of painful to have to manually write fuzz-tests for everything we care about. Manually coming up with good test cases is also hard. But remember those Monad laws in Haskell? https://wiki.haskell.org/Monad_laws https://wiki.haskell.org/Monad_laws these are essentially free fuzzing code. If I implement something as a Monad, at least in theory I should be able to reuse existing fuzz-drivers to test my new code as well. I probably would not have had the patience to come up with good tests myself. Similarly for other categories. Again, it's good to know what general interfaces already exist.

zug_zug 7y ago

As a functional programmer myself, I have the same confusion. As best I can tell, category-theory a cargo-cult thing ("I want to look like the type of engineer who CARES about monoids [because if I use words you don't know I'm smart]" much in the same way hipsters claimed vinyl sounds better). I'd like to be wrong about this, but I've already met a handful of "phonies" who rant and rave about this stuff, but when I ask them "How does labeling an array a monad help me?" or even "Is a hash-map a monad?" they are completely stuck.

crimsonalucard 7y ago
Label the string as a functor and think about lifting the array into the string functor and doing string manipulation to change it to a dict, then lift it back into a dict type. String manipulations of a lifted type in "string space" can be faster and more efficient then actually manipulating it in "type space"
- edflsafoiewq 7y ago
  What?
  - alexandercrohde 7y ago
    This is exactly what I mean. I can't tell if that's a joke or not.
    - crimsonalucard 7y ago
      Not a joke. Take a look at my response to the other guy. I clarified my point with a thorough example. Please note that I was somewhere else and on the phone when I typed my initial response so forgive me for the brevity and lack of clarity. Hopefully the new response will clear things up. Anyway... I think theres a good chance that you simply aren't grasping what the category theory fans are saying. Hopefully you grasped what I'm saying.
  - crimsonalucard 7y ago
    Apologies. I was on the phone typing the above. Still, remarks like "What?" that provide no information or context are against the rules on HN. Just FYI. The OP said that there's no point in labeling an arbitrary type as a functor or monadic value. I'm going to use an example to illustrate how there is a benefit in being aware of this concept. I will be using a "String Monad" in my example. Imagine you have some type, like in the initial example. And you want to convert that type into another type. I'll give you an arbitrary example using python: You want to convert this: {1:2 ,3:4, 5:6, 7:8} To this: [1,2,3,4,5,6,7,8] You can do this via loops or you can "lift" the dictionary type from "type space" to "string space" via the python functor str(): lifted_dictionary = str({1:2 ,3:4, 5:6, 7:8}) This is similar to movement between two categories or objects via a functor. You see similar techniques in other fields of engineering when say someone "lifts" something from cartesian coordinates to polar coordinates. Which is why I'm using the word "space" it's similar to how I'm shifting representations of coordinates to have an easier time with certain calculations. Then you do your type manipulations in "string space" rather then on the type itself. So it all ends up being string manipulation operations to get from the string "{1:2 ,3:4, 5:6, 7:8}" to the string "[1,2,3,4,5,6,7,8]". I didn't use regexp in the example below but you get a huge performance boost if you use that instead. lifted_array = "{1:2 ,3:4, 5:6, 7:8}".replace('{','[').replace('}',']').replace(':',', ') #computed value is a string of the form: "[1,2,3,4,5,6,7,8]" Then you use the opposite functor from str() to lift the value back into "type space" array = eval(lifted_array) Here eval() is the opposite functor to str() Type conversion complete. The full code: original_dict = {1:2 ,3:4, 5:6, 7:8} array = eval(str(original_dict).replace('{','[').replace('}',']').replace(':',', ')) #value of array is [1,2,3,4,5,6,7,8] Essentially you use functors to lift your data structures into other categories for easier conversion, then you simply bring the stringified type back down into regular "type space". So in short I took types and lifted it into the String Monad or "String Category" or whatever you want to call it, then brought back down into types. It seems like an arbitrary way to do type conversion but using regexp to do string manipulation in place of a for loop that unrolls the dictionary is more performant and faster. Think about preserving order as well. When I convert the dict type into string space, ordinal properties of the string itself will be enforced on the dict. SO the keys in the dict will follow the order they appear in the string as will the array string that it is converted to. This technique utilizes category theory. The categories you are lifting to must be isomorphic to the origin category, you must understand the notion of functors (or monadic values) to really get it.

philzook 7y ago

I think I've got the category bug. I very much was intrigued by Milewski's course and found that it made things happening in Haskell make more sense to me. There are a couple of things that really excited me. Conal Elliott's compiling to categories. Categories make a great intermediate representation for DSLs. They are very easy to manipulate/optimize in a simple algebraic manner without issues related to named variables. This proposal showed how a plugin could take ordinary programs written in more user friendly syntax and compile it to the category IR. You can overload ordinary programs to automatically differentiable programs and more. http://conal.net/papers/compiling-to-categories/ http://conal.net/papers/compiling-to-categories/ Another thing I think is really interesting is calculating programs. It is possible in the right formalism to write down a specification of a program in a simple small form, and use algebraic manipulation to derive an executable form of the program. It feels like doing an integral or something. Check out these books on that topic. https://themattchan.com/docs/algprog.pdf https://themattchan.com/docs/algprog.pdf http://www4.di.uminho.pt/~jno/ps/pdbc.pdf http://www4.di.uminho.pt/~jno/ps/pdbc.pdf

runeks 7y ago
Great example! Here’s a video where Conal demonstrates interpreting a Haskell program (actual Haskell, not a DSL) into a) an image of a graph-like structure (visualizing the algorithm), b) Verilog (for compiling to hardware), and c) GLSL (for being rendered by a GPU in the browser). https://youtu.be/vzLK_xE9Zy8 https://youtu.be/vzLK_xE9Zy8

6gvONxR4sf7o 7y ago

It's a really interesting way to think about things, that's pretty unlike other ways to think about things, and yet you can use it as a viewpoint for so many other things. It's intellectually really neat and marginally useful. More useful in certain programming communities.

playing_colours 7y ago

I think it is a similar kind of excitement people have when learning Haskell and functional programming: pleasure to experience the aesthetics of pure forms, distilled mathematical concepts, that contrast with impurity and mess of real world coding. I see some practical benefits from studying Category Theory and Pure Mathematics in general: mental patterns, some limited applications in general, interesting application in specific problems, but it requires huge investment of time, and, frankly, there are much more practical applied areas in maths that can bring food on the table: optimizations, probability, linear algebra, fluid dynamics, Fourier transforms. One usually does not ask questions about applicability when decides to study Pure Maths, it is a passion driven adventure: https://en.m.wikipedia.org/wiki/A_Mathematician's_Apology https://en.m.wikipedia.org/wiki/A_Mathematician's_Apology

CuriousSkeptic 7y ago

Here’s maybe one attempt at answer https://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory/ https://blog.ploeh.dk/2017/10/04/from-design-patterns-to-cat... As I take it the hope isn’t that all programmers would learn CT but rather that those who work on progressing the craft and our tools get at a proper formalism to work with for certain aspects that until now has been rather “soft”

mathgenius 7y ago

> the content is interesting but the ROI is low ... Even mathematicians themselves have had this view, for a long time. The attitude appears to be "hey I'm doing my good calculations here, why should I be messing around with arrows?" Theoretical physicists are now getting involved in this debate aswell. So it's a much bigger complaint than "how is this going to give me better programs?" I've thought so much about this, I don't really know where to start. The functional programming stuff is nice, but it is only one manifestation of CT ideas. Probably, if you are any good at programming you are already "doing" CT. Anytime you have a class invariant, you are "doing" category theory. The methods are preserving some kind of structure (the class invariant.) And that is the key idea behind OOP. That is what it means to have an object and not just a bucket of data. FP does this too but in a strict way; nothing is mutable. The revelation of CT is how deep (or wide?) these ideas are, but maybe the only thing you get from this is the satori.

lopsidedBrain 7y ago

I didn't read the book yet, but I'll take a crack with a couple of examples: Unix file systems, and its philosophy of "everything is a file". It wasn't common before Unix to interact with devices through a filesystem. Somebody noticed that simple tasks like "listing with ls" and "hex-dumping with xxd" doesn't need separate utilities for files vs devices, and thus made the abstractions converge. If you ask me, this is the kind of abstraction I wouldn't normally think of. It's useful to know what kind of things to be on the lookout for. The second example is fuzzing. At least today, it's still kind of painful to have to manually write fuzz-tests for everything we care about. Manually coming up with good test cases is also hard. But remember those Monad laws in Haskell? https://wiki.haskell.org/Monad_laws https://wiki.haskell.org/Monad_laws these are essentially free fuzzing code. If I implement something as a Monad, at least in theory I should be able to reuse existing fuzz-drivers to test my new code as well. I probably would not have had the patience to come up with good tests myself. Similarly for other categories. Again, it's good to know what general interfaces already exist.