Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I am learning category theory

the.scapegoat.dev

Post reply on HN
Print view View original

61–70 of 224 posts

Re: Why I am learning category theory

#61

Post by floober »

picardo wrote: post #45
floober wrote: post #24

Earlier quoted context omitted.

For me, I use the simple stuff (Semigroup, Monoid, Monads, Functors, ..) the most. Often times I'll be reasoning about a problem I'm working on in Haskell and realize it is a monad and I can reuse all of the existing monadic control structures. It is also helpful the other way, where you start working with someone else's code and seeing that it is a e.g. Monad immediately tells you so much concrete info about the str…

Same here. I drank the cool aid a few years back, and started using fp-ts in my frontend projects, hoping to use algebraic data types regularly. But today all I use is the Monad. I can't find any motivation to write abstract algebra to build UI widgets.

> I can't find any motivation to write abstract algebra to build UI widgets

This made me chuckle, because I am at this very moment trying to apply the "tagless final style" described here[0] to a custom GUI in a personal-for-fun-and-learning ocaml project : )

[0] https://okmij.org/ftp/tagless-final/course/optimizations.htm...

Re: Why I am learning category theory

#62

Post by deltaseventhree »

i_am_toaster wrote: post #21

I would be willing to drink the kool-aid if I saw it being used in a practical way. I always feel these posts are filled with category theory jargon without ever explaining why any of the jargon is relevant or useful. I’ve even watched some applied category theory courses online and have yet to feel I’ve gained anything substantive from them. However, as I started off with, I’m always willing to try something out or…

Knowing category theory helps you better design interfaces. Exactly like the interfaces in OOP.

Alot of the generic interfaces you design in OOP end up being useless. Never re-used and pointless. You never needed to make these interfaces in the first place

In category theory, you will be able to create and identify interfaces that are universal, general and widely used throughout your code. Category theory allows you to organize your code efficiently via interfaces and thus enable Maximum reuse of logic.

When creating an interface you largely use your gut. Category theory allows you to draw from established interfaces that are more fundamental. Basically class types in haskell.

If you want to see the benefit of category theory, you really need to use haskell. Monads for example are a pattern from category theory.

Also a lot of what people are talking about in this thread is exactly what I'm saying^^. I'm just saying it in less complicated jargon.

Re: Why I am learning category theory

#63

Post by tmoertel »

musk_micropenis wrote: post #57
larve wrote: post #53

Earlier quoted context omitted.

This is useful for example when implementing compiler optimizations, or concrete string implementations. It means that you can reduce "foo" + "bar" + foo to at least "foobar" + foo and that you can intern "foobar". Would that work the same without calling it a monoid? Of course, monoid is just a name. But that name allows you to go shopping in a wide variety of other fields and work other people have done and mine it…

A vast, overwhelming majority of programmers will never implement a concrete string type or compiler optimizations. Can you show me how this kind of theory is practical for a working programmer who does things like batch processing jobs, web applications, embedded software, event-driven distributed systems, etc?

Consider the monoid abstraction in the context of batch processing. Anywhere you have a monoid, you have a corresponding “banker’s law” that says you can find the generalized sum of a collection of items by partitioning the items into groups, computing the sum over each group, and then taking the sum of the sums as your final result. This idea has many applications in batch processing.

For example, in the MapReduce framework, this idea gives rise to “Combiners” that summarize the results of each map worker to massively lower the cost of shuffling the results of the Map stage over the network prior to the Reduce stage.

Another example: In distributed database systems, this idea allows many kinds of addition-like aggregations to be performed more efficiently by computing the local sum for each group under the active GROUP BY clause before combining the groups’ subtotals to yield the wanted gobal totals.

Basically, in any situation in which you have to compute a global sum of some kind over a collection of items, and some of those items are local to each worker, you can compute the global sum faster and with fewer resources whenever you can take advantage of a monoidal structure.

Re: Why I am learning category theory

#65

Post by larve »

tmoertel wrote: post #63
musk_micropenis wrote: post #57

Earlier quoted context omitted.

A vast, overwhelming majority of programmers will never implement a concrete string type or compiler optimizations. Can you show me how this kind of theory is practical for a working programmer who does things like batch processing jobs, web applications, embedded software, event-driven distributed systems, etc?

Consider the monoid abstraction in the context of batch processing. Anywhere you have a monoid, you have a corresponding “banker’s law” that says you can find the generalized sum of a collection of items by partitioning the items into groups, computing the sum over each group, and then taking the sum of the sums as your final result. This idea has many applications in batch processing. For example, in the MapReduce f…

Which is exactly the concept between optimizing for string concatenation and interning them, ultimately. Sure you can make do with the "algebraic" definition of a monoid, or entirely without it, but that doesn't mean the abstraction isn't there to inform your thinking and your research.

One point that really stuck with me is how people who apply category theory (say, people at the topos institute) use the concepts as little tools, and everytime a problem crosses their way, they try out all the little tools to see if one of them works, similar to how Feynman describes carrying out problems in his head until one day a technique unlocks something).

Having more general abstractions just allows them to be applied to more problems.

Re: Why I am learning category theory

#66

Post by larve »

yodsanklai wrote: post #64

Reading at the comments, people confuse concepts like monoids and functors with category theory.

They're concepts in category theory? Since category theory's goal is to find common abstractions behind concepts from other fields (mathematics or otherwise), it makes sense some of those concepts appear in other fields. Their definition in a category theory context is different, usually, since you can only express them using morphisms between objects in a category.

(edit: typo)

Re: Why I am learning category theory

#67

Post by Karrot_Kream »

larve wrote: post #9
Tainnor wrote: post #7

As someone with a maths degree, yet who admittedly hasn't looked into category theory beyond some basic notions, I still don't quite understand why anyone would want to learn category theory before e.g. abstract algebra or even just fundamental mathematical reasoning (definition, theorem, proof). Maybe I'm missing something but it seems to me that all you can study monads in programming languages without having to al…

author here, for context, I do have a reasonable background in maths (algebra, analysis, statistics) at a CS master-ish level (self-taught and a long time ago, though), as well as spent quite some time with programming language / type theory when I was younger, and I do use monads quite a bit in my day to day programming. In fact, the fundamental algebra concepts (rings, groups, etc...) as well as fundamental CS theo…

How much do you think your predilection for algebra affected your interests? Most folks who do CT as a hobby that I know are much weaker in analytical concepts than any working mathematicians that I knew.

Re: Why I am learning category theory

#68

Post by dboreham »

rslice wrote: post #3

I strongly recommend this presentation: "John Baez: "Symmetric Monoidal Categories A Rosetta Stone"[0]. It is easy to get lost in the ocean of theorems and definitions and overlook some powerful core concepts. [0] https://www.youtube.com/watch?v=DAGJw7YBy8E

Even though I've done much reading on the subject, and watched many of his lectures, my brain still jumps to music and Joan Baez.

Re: Why I am learning category theory

#69

Post by Karrot_Kream »

School-Cotton wrote: post #14
Tainnor wrote: post #7

As someone with a maths degree, yet who admittedly hasn't looked into category theory beyond some basic notions, I still don't quite understand why anyone would want to learn category theory before e.g. abstract algebra or even just fundamental mathematical reasoning (definition, theorem, proof). Maybe I'm missing something but it seems to me that all you can study monads in programming languages without having to al…

> As someone with a maths degree, yet who admittedly hasn't looked into category theory beyond some basic notions, I still don't quite understand why anyone would want to learn category theory before e.g. abstract algebra Because people think “category theory” means “abstract math” in general, due to cargo-culting in and around the Haskell community.

Yeah when I read all of this "category theory expands your mind" thinking, it makes me think that folks were looking for mathematical maturity more than category theory. Work through any good book on algebra and analysis and you'll learn and prove a bunch of stuff about objects and relations.

Re: Why I am learning category theory

#70

Post by dboreham »

oxff wrote: post #35

To obviously debunk any and all FP autism coming at your way. To give credit where credit is due, most of the time some application functionality being described through FP jargon gives a better spec of its behavior than the same through OOP jargon.

This is exactly why I learned about it.
Post reply on HN