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

31–40 of 47 posts

Re: Why category theory matters in programming

#31

Post by Myrmornis »

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…

It's a cheap and shallow shot you're making, criticizing the article for using facebook likes as an example. I'm a programmer with some math background but who has never tried hard to understand the more theoretical sides of languages like scala. The article is a very good, even slightly inspirational, introduction to how category-theory type thinking can arise when you start to abstract some common patterns in programming. The author clearly went to a lot of effort to make this explanation available, and obviously not in her/his native language either.

Anyone put off by some of the negative responses in this thread, note that among the people saying "FP isn't necessary/helpful in real-world programming" the same people are saying "but understanding this stuff is very helpful to your development as a programmer".

Re: Why category theory matters in programming

#32

Post by thomastjeffery »

keithnz wrote: post #3

Functional Programming and Category Theroy are great, there's a strong level of robustness in the whole approach to programming. The author slams imperative programming, it isn't backboned on a robust compositional system, as is often done by FPers BUT :) there's lots of good programs in both styles....to me, this implies that there are more important things that matter to programming, the design to achieve a purpose…

The wonderful thing is that we can mix the two.

One great method is to write your program using a nice functional language (Haskell, CL/racket/scheme, etc.), and where you want optimizations, replace functions with lower level imperative language implementations (C/C++, rust, etc.) and FFI.

Re: Why category theory matters in programming

#33

Post by thomastjeffery »

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…

> 19 lines...pretty much anyone can understand

> 9 lines of...functional

First of all, those numbers are more like 1000 vs 200, but lines of code isn't a useful metric here.

The thing functional programming does for us is not hide the functionality of our code, it is to make it more consistent.

Category theory shows us ways that our code can be more consistently organized, so that we don't need to reason about the entire codebase when writing the code that guess it together.

This means we can create modules that are so compatible, all it takes to compose them is a simple map or fold.

While it may take more effort to understand the functional language itself, you may find that effort is comparatively less than learning what someone's imperative code does.

I always know right away what map and foldl will do, but I can never know what a loop does without reading through that loop.

Re: Why category theory matters in programming

#35

Post by esarbe »

thomastjeffery wrote: post #34

What language are these coffee examples written in? The article doesn't give me a reference for what syntax I'm trying to parse, and while most of it is easy to guess, it would be helpful to have an explicit reference.

That would be Scala. (http://www.scala-lang.org/)

Re: Why category theory matters in programming

#36

Post by tome »

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.

> Monads should never have escaped Haskell.

They should have put them in a monad.

Re: Why category theory matters in programming

#37

Post by tome »

Retra wrote: post #7
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…

I was reading very famous paper[1] today, and I stopped at the following: "To get an adequate definition of g [ You see, I was reading this paper because I'm currently looking into various ways of that the symmetries of Turing machines are modeled (I.e., the fact that a TM can emulate any other TM would seem to imply that the concept of an 'algorithm' must have fundamental features that are preserved across this kind…

http://h2.jaguarpaw.co.uk/posts/greenspun/

Re: Why category theory matters in programming

#38

Post by tome »

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…

> The reasonable programmer adapts his code to be read by others; the unreasonable one persists in trying to adapt others to be able to read his code. Therefore all progress depends on the unreasonable programmer.

-- Oscar Wilde

Re: Why category theory matters in programming

#39

Post by tome »

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…

> This is kind of a false dichotomy as well written fp, type code is tends to have fewer bugs.

I tentatively agree but I would caution you against making such claims in public because they are hard to rigorously justify and can end up making functional programmers just look arrogant.

Re: Why category theory matters in programming

#40

Post by tome »

Twisell wrote: post #25

This kind of contribution always make me hesitate betweeen two reactions: 1.Man I must be dumb I can't even begin to understand what matter 2.Can't we achieve/explain the same goal by keeping it simple stupid

> 2.Can't we achieve/explain the same goal by keeping it simple stupid

We should keep it "as simple as possible but no simpler". Sometimes "as simple as possible" is actually somewhat challenging ...

Post reply on HN