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

[thomastjeffery]

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

[adamnemecek]

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

[kafkaesq]

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.

[tome]

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

[yahyaheee]

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

[adamnemecek]

What particular language are you talking about?

[yahyaheee]

Mainly scala, but I've used some clojure as well. Ever since learning Go, I just haven't looked back. I think FP does well with streaming problems, but outside of that it seems to have a cognitive overhead that doesn't pay

[Myrmornis]

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

[tome]

> 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

[sidlls]

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.

[14113]

> hot-synching whole data centers

That is actually what Facebook is doing with their spam detection code - their purely functional architecture makes it easier and more reliable for them to hot-swap out parts of their codebase when the need to update it.

https://code.facebook.com/posts/745068642270222/fighting-spa...