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

21–30 of 47 posts

Re: Why category theory matters in programming

#21

Post by kafkaesq »

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…

Commutativity is a life saver for distributed computing.

Nice to know, and I wish I understood these issues, and these kinds of arguments better.

I'm just saying - the original blog post didn't come anywhere near to making that kind of an argument.

Re: Why category theory matters in programming

#22

Post by adamnemecek »

yahyaheee wrote: post #19
adamnemecek wrote: post #18

Earlier quoted context omitted.

> 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

What particular language are you talking about?

Re: Why category theory matters in programming

#23

Post by s4vi0r »

hota_mazi wrote: post #15
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.

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.

Isn't a Monad just the fancy name for a type/structure that implements map and flatMap in a lawful manner?

Re: Why category theory matters in programming

#24

Post by hota_mazi »

s4vi0r wrote: post #23
hota_mazi wrote: post #15

Earlier quoted context omitted.

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.

Isn't a Monad just the fancy name for a type/structure that implements map and flatMap in a lawful manner?

Close: the required operations are `flatMap` and bind/pure/point/lift/return/whatever-you-want-to-call-it.

You can derive `map` from these two other functions so it doesn't need to be part of the interface.

Re: Why category theory matters in programming

#27

Post by throwawayjava »

Myrmornis wrote: post #20
throwawayjava wrote: post #14

Earlier quoted context omitted.

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?

> category theory / abstract algebra

Woah there!

But otherwise, yes.

Most working mathematicians have seen category theory and borrow bits and pieces of notation and such. But most of their work is done in far more concrete settings.

Working programmers should adopt the same arrangement.

It's a subtle position, but not an inconsistent one. I promise :-)

Re: Why category theory matters in programming

#28

Post by sidlls »

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…

I disagree that "far fewer people can (really) understand" functional code. It's more like far fewer people care to. Either way, that's a separate matter from whether category theory matters to programming or not. I happen to think it matters in the same way theoretical physics matters to engineering: that is, eventually engineering will make use of it, and sometimes an engineering need drives the research in the first place, but as a matter of day-to-day practice they're effectively completely separate fields.

Although apparently some coders desperately want to think their glorified bit-shuffling is some deeply abstract mathematical endeavor.

Re: Why category theory matters in programming

#29

Post by d--b »

Er... I think that people tend to use the if then else approach, because it is actually more flexible, in the sense that you may actually want to do something else than return false when something wrong happens in one of the functions in the composition chain...
Post reply on HN