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

Why category theory matters in programming

tech.iheart.com

Post reply on HN
Print view View original

11–20 of 47 posts

Re: Why category theory matters in programming

#11

Post by dshnkao »

ebola1717 wrote: post #5

Eh, as someone who works in scala day-to-day, and has studied actual category theory, I think the emphasis on category theory itself is silly. And in fact, most of the time, more category theory and more monads will make your code worse (e.g. MonadTransformers are D: ) Future, which is really a souped up promise abstraction, is the main star, and for-comprehensions are nice syntactic sugar. Being a "Monad" doesn't he…

as someone who also works in scala, MonadTransformer is so much better than gigantic nested flatMaps and pattern matchings

Re: Why category theory matters in programming

#12

Post by eastWestMath »

LolWolf wrote: post #4

Category theory is fine, I guess, but there's no need to invoke a sledge-hammer when talking about 99% of most work here. It's a little like saying, yes, fine we can reference the hyperreals to derive infinitesimal calculus in a beautiful way, but it's mostly abstract and highly involved, even to just understand the foundational aspects (which one may argue is the case for normal calculus, but the notion of local lin…

But infinitesimal calculus is all about local linearity, in the analytic formulation you're taking the closest linear approximation to the function at that point. Using the dual numbers approach, there is an infinitesimal (nilpotent) region around each point which is linear.

Re: Why category theory matters in programming

#14

Post by throwawayjava »

tel wrote: post #9
ebola1717 wrote: post #5

Eh, as someone who works in scala day-to-day, and has studied actual category theory, I think the emphasis on category theory itself is silly. And in fact, most of the time, more category theory and more monads will make your code worse (e.g. MonadTransformers are D: ) Future, which is really a souped up promise abstraction, is the main star, and for-comprehensions are nice syntactic sugar. Being a "Monad" doesn't he…

That has a little to do with Scala just being a pretty bad place to implement most of these things. E.g., Monad transformers work just great in Haskell but are terrible in Scala due to the sort of terrible ways type parameters and inference work together. Future also doesn't obey the monad laws for not being RT and that causes a lotttt of complexity.

OK, I'm another data point for "studied category theory; program in an ML dialect; think it's silly".

Most all the theorist/logician/algebraist-turned-programmer folks I know all feel more-or-less the same way.

Just explain the pattern in english. Might as well call it a FooDeBar. Giving axioms and such is usually a waste of The Man's money and my time.

That said, I think it's extremely valuable to see this sort of thing in an academic or side project/enrichment activity setting. The mindset and mental model are fantastically helpful. See dshnkao's post, for example.

Re: Why category theory matters in programming

#15

Post by hota_mazi »

tel wrote: post #9
ebola1717 wrote: post #5

Eh, as someone who works in scala day-to-day, and has studied actual category theory, I think the emphasis on category theory itself is silly. And in fact, most of the time, more category theory and more monads will make your code worse (e.g. MonadTransformers are D: ) Future, which is really a souped up promise abstraction, is the main star, and for-comprehensions are nice syntactic sugar. Being a "Monad" doesn't he…

That has a little to do with Scala just being a pretty bad place to implement most of these things. E.g., Monad transformers work just great in Haskell but are terrible in Scala due to the sort of terrible ways type parameters and inference work together. Future also doesn't obey the monad laws for not being RT and that causes a lotttt of complexity.

It's not just monad transformers, monads themselves are pretty awkward to use in any language that's not Haskell. And actually, a lot of FP languages simply don't even have monads at all (OCaml, F#).

Monads should never have escaped Haskell.

Re: Why category theory matters in programming

#16

Post by kafkaesq »

That's nice, but form a hard-nosed engineering perspective, not just sometimes, but in general 19 lines of yucky procedural code that pretty much anyone can understand (and debug) are usually way, way better than 9 lines of "elegant" functional code comparatively far fewer people can (really) understand - and which can be comparatively far more sinister and nefarious to debug.

Given that, after all, it's just posting likes we're talking about. You'd think that with such a bold proposition as "Why category theory matters -- no really, it does!" this would be about hot-synching whole data centers, or getting drones to deliver medicine in Africa, or something like that. You know, something perhaps unthinkable (or maybe just far less tractable) with procedural (or just less sophistical functional) code.

But no, in this case apparently it's about... updating your FB likes.

Re: Why category theory matters in programming

#17

Post by purescript »

Category theory matters to programming because, among other things, it teaches us how to abstract over programming languages. What better definition of abstract programs than "things with types which compose"?

Now consider categories with various types of constructions (products, limits, exponentials, etc.) and you'll notice they correspond to requiring certain features in your language.

Re: Why category theory matters in programming

#18

Post by adamnemecek »

kafkaesq wrote: post #16

That's nice, but form a hard-nosed engineering perspective, not just sometimes, but in general 19 lines of yucky procedural code that pretty much anyone can understand (and debug) are usually way, way better than 9 lines of "elegant" functional code comparatively far fewer people can (really) understand - and which can be comparatively far more sinister and nefarious to debug. Given that, after all, it's just posting…

> and which can be comparatively far more sinister and nefarious to debug.

This is kind of a false dichotomy as well written fp, type code is tends to have fewer bugs. Also your argument that more people understand it doesn't mean much as few people understand something they haven't been exposed to.

> hot-synching whole data centers

It actually does. There was a podcast with Paul Chiusano who is a big proponent of this type of programming http://futureofcoding.org/episodes/10-unisons-paul-chiusano-.... IIRC Spark is based on Algebird which is somewhat close to this type of programming. Commutativity is a life saver for distributed computing.

Re: Why category theory matters in programming

#19

Post by yahyaheee »

adamnemecek wrote: post #18
kafkaesq wrote: post #16

That's nice, but form a hard-nosed engineering perspective, not just sometimes, but in general 19 lines of yucky procedural code that pretty much anyone can understand (and debug) are usually way, way better than 9 lines of "elegant" functional code comparatively far fewer people can (really) understand - and which can be comparatively far more sinister and nefarious to debug. Given that, after all, it's just posting…

> and which can be comparatively far more sinister and nefarious to debug. This is kind of a false dichotomy as well written fp, type code is tends to have fewer bugs. Also your argument that more people understand it doesn't mean much as few people understand something they haven't been exposed to. > hot-synching whole data centers It actually does. There was a podcast with Paul Chiusano who is a big proponent of th…

In my experience FP code is more buggy, but I imagine there's a lot that goes into it

Re: Why category theory matters in programming

#20

Post by Myrmornis »

throwawayjava wrote: post #14
tel wrote: post #9

Earlier quoted context omitted.

That has a little to do with Scala just being a pretty bad place to implement most of these things. E.g., Monad transformers work just great in Haskell but are terrible in Scala due to the sort of terrible ways type parameters and inference work together. Future also doesn't obey the monad laws for not being RT and that causes a lotttt of complexity.

OK, I'm another data point for "studied category theory; program in an ML dialect; think it's silly". Most all the theorist/logician/algebraist-turned-programmer folks I know all feel more-or-less the same way. Just explain the pattern in english. Might as well call it a FooDeBar. Giving axioms and such is usually a waste of The Man's money and my time. That said, I think it's extremely valuable to see this sort of t…

Just to be clear, you're advocating:

1. Don't use terminology from academic category theory / abstract algebra in computer programming

2. But if you haven't studied these things, and you are a programmer, it might be very enlightening to do so.

Is that right?

Post reply on HN