Live data from Hacker News

Category Theory for Programmers (2014) [pdf]

github.com

51–60 of 136 posts

Re: Category Theory for Programmers (2014) [pdf]

#51

I liked “An Invitation to Applied Category Theory“, pdf is available here: [1] It is written in a more terse, mathematical language, but it is very clear and friendly for non-mathematicians. The authors provide interesting examples of applicability. Hardcover is quite expensive, but the quality is great [2]. [1] http://math.mit.edu/~dspivak/teaching/sp18/7Sketches.pdf [2] https://www.amazon.com/gp/aw/d/1108482295

I've quite literally spent the last month trying to read, digest, and apply the above to a record layer I'm writing for FoundationDB. Dr. Spivak's work has been absolutely beyond helpful and insightful. There's no way I'd even be able to approach the subject with his efforts. I'd also recommend these as they're associated with the 7 Sketches and help fill in some blanks: Functorial Data Migration - https://arxiv.org/…

is the source code of the record layer available somewhere?

Re: Category Theory for Programmers (2014) [pdf]

#52

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).…

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/

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 http://www4.di.uminho.pt/~jno/ps/pdbc.pdf

Re: Category Theory for Programmers (2014) [pdf]

#53

The clearest and most concise treatment I've come across on how Category Theory is used is Tai-Danae Bradley's "What is Applied Category Theory": https://arxiv.org/abs/1809.05923 (It's a 50 page PDF) Unfortunately the examples aren't within CS, but at least for me personally, seeing it clearly applied in any context was the most important thing. It may be a good pre-req for looking at (or conjuring up your own) more…

I'm familiar with the applications here, and I've never found them compelling. They amount to taking things we already understand perfectly well (chemical reactions, written in terms of differential equations or visualized in terms of graphs) and draping huge amounts of formalism around them. The "theorems" they then prove do not provide any new insight -- they're only called theorems because the excess formalism makes completely trivial things hard to see!

For example, the main theorem of one of Baez's very long papers is:

> There is a symmetric monoidal functor from the category Petri to the category Dynam.

When you plug in the hundred relevant definitions, you find that this is literally just the statement that you can specify a chemical reaction network in terms of differential equations, or pictorially in terms of graphs where the edges represent reactions, which is a standard thing taught in ordinary chemistry classes. The language of categories is not achieving anything here but obfuscation.

Category theory is only good when there's a very rich preexisting mathematical structure, so that introducing it simplifies things. That usually isn't true in science.

Re: Category Theory for Programmers (2014) [pdf]

#54
post #44

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).…

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 a…

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"

Re: Category Theory for Programmers (2014) [pdf]

#55

Earlier quoted context omitted.

This is probably one of the best introduction to category theory text out there now, but it isn’t exactly as friendly to the non-mathematicians as advertised. The book assumes a level of mathematical sophistication beyond what most non-math majors know and ramps up fast. The average programmer would probably get lost pretty quickly with this book.

>but it isn’t exactly as friendly to the non-mathematicians as advertised. i really chafe at criticisms like this given how much effort was clearly invested by those authors in that book being readable - there are ample definitions (and clearly offset), tons of diagrams, instructive examples, solutions to many exercises, pointers to further readings, motivation and discussion. is the thing that bothers you that there…

> "this book is too unfriendly to people that don't program because it has lots of code and expects people to be able to read code"

That would be a perfectly valid response to the claim that the book "is very clear and friendly for non-coders". I don't understand why you are chafed.

Re: Category Theory for Programmers (2014) [pdf]

#56
post #18

Question to all CS majors, that invested in learning Category Theory: Did you have any concrete take aways from learning it? ( I have a math background, and struggle to find something concrete. Maybe I am just blind. )

I believe my real analysis class made me a significantly better programmer and thinker in general, but I don't use anything specific from it (not yet, anyway).

Genuinely curious how real analysis made you a better programmer...? I've taken it and loved it, but my interest was more due to physics/engineering applications. I can't see a connection to programming.

Re: Category Theory for Programmers (2014) [pdf]

#57
I very much like: "Sets for Mathematics", which I currently read and which finally clicks with me. I always found expositions of category theory tiring in that it bombarded me with trivialities and examples that were kind of obvious. Instead, "Sets for Mathematics" describes one particular and probably the most familiar and important category, the category of sets, and I very much like this fresh look at sets.

Re: Category Theory for Programmers (2014) [pdf]

#58
post #53

The clearest and most concise treatment I've come across on how Category Theory is used is Tai-Danae Bradley's "What is Applied Category Theory": https://arxiv.org/abs/1809.05923 (It's a 50 page PDF) Unfortunately the examples aren't within CS, but at least for me personally, seeing it clearly applied in any context was the most important thing. It may be a good pre-req for looking at (or conjuring up your own) more…

I'm familiar with the applications here, and I've never found them compelling. They amount to taking things we already understand perfectly well (chemical reactions, written in terms of differential equations or visualized in terms of graphs) and draping huge amounts of formalism around them. The "theorems" they then prove do not provide any new insight -- they're only called theorems because the excess formalism mak…

I think you may be missing something here.

> The "theorems" they then prove do not provide any new insight

Knowing that you can model reaction networks using categorical concepts may not provide new insights IF you have no deep familiarity with those concepts—but if you do, then knowing there is a "symmetric monoidal functor from the category Petri to the category Dynam" is a richly useful piece of information. It's probably more accurate to say that the amount of new insight conferred is proportional to your familiarity with the categorical concepts.

And yes, it's true the concepts are 'just' being translated into a new language—but if this new language is extremely general, applicable to a wide range of domains, then:

1) You can build a set of skills and knowledge related to concepts in this general language, which become automatically applicable to a wide range of domains (when their concepts are imported into the language).

2) It's possible to build 'machinery' (i.e. theorems or software) which deals with / operates on (representations of) concepts from this very general language—so once again, if you can translate some concept from domain X into e.g a symmetric monoidal category, now your general machinery can operate on things from domain X (which it was built with no awareness of).

Additionally, at least in Bradley's paper, the point wasn't to prove new things about e.g. reaction networks; instead it was to illustrate a method. To be more specific she is showing how "functorial semantics" can be applied in this context, using Petri nets as the syntax and dynamical systems as the semantics. From there the categorical classification of these objects gives us guarantees on their behavior under composition (the utility of which I assume is clear).

I'm not sure in the context of reaction networks whether modeling the system with compositionality guarantees and a clean mapping between graph representation and differential equations gives scientists something new or not—but the illustration of this method is done clearly, and the generality of the method is enormous.

And maybe I'm also missing something. I'm not a mathematician, but that's how the situation looks to me.

Re: Category Theory for Programmers (2014) [pdf]

#59
post #44

Earlier quoted context omitted.

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 a…

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"

What?

Re: Category Theory for Programmers (2014) [pdf]

#60
post #53

Earlier quoted context omitted.

I'm familiar with the applications here, and I've never found them compelling. They amount to taking things we already understand perfectly well (chemical reactions, written in terms of differential equations or visualized in terms of graphs) and draping huge amounts of formalism around them. The "theorems" they then prove do not provide any new insight -- they're only called theorems because the excess formalism mak…

I think you may be missing something here. > The "theorems" they then prove do not provide any new insight Knowing that you can model reaction networks using categorical concepts may not provide new insights IF you have no deep familiarity with those concepts—but if you do, then knowing there is a "symmetric monoidal functor from the category Petri to the category Dynam" is a richly useful piece of information. It's…

> Knowing that you can model reaction networks using categorical concepts may not provide new insights IF you have no deep familiarity with those concepts—but if you do, then knowing there is a "symmetric monoidal functor from the category Petri to the category Dynam" is a richly useful piece of information.

Look, I completely agree with the general point. I love new ways of thinking about things. But blindly applying extremely complicated tools to domains where their power isn't helpful is not good.

What is happening here is like taking a 2-line program that adds together two numbers and dressing it up into thousands of lines of OOP, until you have AdditionObjectFactoryGetterSetter objects being created by AdditionObjectFactoryGetterSetterFactory objects. Then you can bring in powerful OOP tools, but the only things they help you with are understanding the excess complication you added in. Maybe the sheer scale of that structure is beautiful to someone, but we're discussing whether scientists should bother learning it.

> I'm not sure in the context of reaction networks whether modeling the system with compositionality guarantees and a clean mapping between graph representation and differential equations gives scientists something new or not

And I'm telling you, it really doesn't! There simply is not a rich enough formal structure present in chemical reaction networks for category theory to yield anything useful, like it did in parts of pure math. Adding a complicated structure on top of something simple does nobody any good. All of the "guarantees on compositionality" were not useful, in the sense that they went without saying in freshman-level courses, or worse, were problems solely created by the introduction of category theory.

> the illustration of this method is done clearly, and the generality of the method is enormous.

The fact that the technique is extremely general does not improve things. If a technique makes science harder to do, you can't make it up on volume.

Post reply on HN