
Why category theory matters in programming - kailuowang
https://tech.iheart.com/f585d17b01d3
======
ebola1717
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 help you
do anything with it though. And Future technically doesn't even truly obey the
Monad laws, because of exceptions.

It's useful that a couple of container classes in scala use implement this
trait:

    
    
        trait ChainableContainer[A] {
          def map(fn: A => B): ChainableContainer[B]
          def flatten(nested: ChainableContainer[ChainableContainer[A]]):ChainableContainer
        }
    

But beyond making it a little easier to guess what's going on, the underlying
math isn't useful in actual programming.

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

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

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

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

~~~
ebola1717
Bind is flatMap (>>=)

Confusingly, map in scala is fmap in Haskell

~~~
hota_mazi
Oops you're right of course. And I can't edit my post.

------
keithnz
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. It's nice to express your designs in a robust system ( and be
influenced by it), but what matters most is the design choices you make. When
I look at well programmed things it's always the design choices that impress
me.

~~~
m_mueller
Coming from HPC, I think imperative programming will stay as long as we don't
have an AGI that does the actual programming for us, as it's the model with
the highest possible abatraction that still gives you the whole truth about
the underlying memory operations (and thus allows you to optimize for it
without having your hands tied behind your back and just trusting the compiler
gods). Not saying that this is how one should usually program in a context
where performance is not the highest goal, but there's always going to be
these usecases.

~~~
jonahx
Agreed. That said, the problem is that imperative programming is still used
widely in contexts (eg, 95% of web programming) where performance is not an
issue and high-level abstractions such as those used in FP are more
appropriate. This is almost entirely due, imo, to the paradigm's inertia and
to bad education.

------
LolWolf
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 linearity I
believe is much more obvious than an extension to the reals). Though it's a
nice academic exercise, which may even yield some insights, it's rather
obscure and unintuitive for almost all purposes.

This is the way I view category theory and functional programming; though I'd
love to be corrected if I'm wrong. There's no need to invoke almost all of it,
since most things can be expressed quite clearly in the language of set theory
need there be rigour.

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

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

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

~~~
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-...](http://futureofcoding.org/episodes/10-unisons-paul-chiusano-on-
how-abstraction-will-save-distributed-computing.html). IIRC Spark is based on
Algebird which is somewhat close to this type of programming. Commutativity is
a life saver for distributed computing.

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

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

------
hprotagonist

      category*

~~~
twic

      category * -> *

------
Veedrac
> So, is there a simple and universal way to compose these functions?

 _proceeds to add layers of complexity_

Why not just write a function to compose them? Argue against the competition,
not strawmen.

~~~
WkndTriathlete
_Most_ code that is written has effects - null returns, error returns,
exceptions, IO, etc., etc. We can write a custom function to compose every
pair of functions we write, but some clever people figured out there were
patterns to this madness - map, flatMap, lift, return, etc. - and it's far
more efficient to write those patterns once and reuse them.

Essentially, it's DRY at a higher level of abstraction.

~~~
Veedrac
You still have to write each composition operator separately; writing the code
to compose null returns doesn't give you the code to compose IO. Only
difference is whether they have separate names.

~~~
dllthomas
That's not the only difference. You get to reuse any code written using only
those names (that interface).

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

~~~
esarbe
That would be Scala. ([http://www.scala-lang.org/](http://www.scala-
lang.org/))

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

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

