Comment by CTmystery | Hacker News Reader

Comment by CTmystery | Hacker News Reader

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

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

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

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.

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"

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

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

Here’s maybe one attempt at answer 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”

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

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.

Reply on news.ycombinator.com