
From design patterns to category theory - mpweiher
http://blog.ploeh.dk/2017/10/04/from-design-patterns-to-category-theory/
======
conistonwater
> _It seems to me that some design patterns are essentially ad-hoc, informally
> specified, specialised instances of basic category theory concepts._

There is a flaw in this type of thinking which I think is not addressed here,
but should be. (I took the quote from the summary, but I think it's fair.) The
usual issue with ad-hoc informally specified things is that the ad-hocness and
the informality leaves something out, making sure that if you understand the
informal thing, but not the formal, you end up understanding only some part of
the whole thing that you could understand if you tried.

So in the context of design patterns, that means there should exist situations
where the extra abstraction, the non-ad-hoc non-specialized understanding,
allows you to write code that is better than otherwise, and (more importantly)
that you would not have otherwise written. This would show explicitly the gap
between the ad-hoc ideas and the formal ideas instead of leaving you to guess.

Whereas the way this post tries to explain it, as I understand it, is that it
shows you things (design patterns) that you _would_ have otherwise written,
and shows how it can be talked about in more general terms. But the things
that you _wouldn 't_ have written are missing.

E.g., in some monad tutorials at some point one of the exercises is the
nondeterministic choice monad, which is totally something you might not have
written yourself, which makes it a way of showing why monads are a useful
concept. If the only monad you had was IO, it'd be a much more useless idea
(it would merely be a different, not even necessarily better, way of writing
things that you already knew).

~~~
closed
Wow, this really struck home the idea of useful forms of generality for me.
Definitely reminded me of an interesting section in Polya's book Induction and
Analogy in Mathematics that discusses different forms of generality, and when
it's useful (in the context of a problem to figure out).

~~~
AstralStorm
And then you wake up to the fact that most programmers are really bad at
higher abstractions and especially mathematics. They start off way better than
general population too...

But they can deal with nested smaller abstractions or impure smaller
abstractions just fine.

It is easier to think of a set of logic properties than essentially equation
describing construction of an object with such properties. And that is the
difference between the design pattern and a category. To put something in a
mathematical category you have to actually prove it constructively or you're
doing adhockery.

And due to so many levels of abstraction nesting proving anything nontrivial
in maths is really a chore at times.

A simple example: prove some operation is a Strategy morphism compared to
describing it as an object with a set of properties.

~~~
loup-vaillant
> _most programmers are really bad at […] mathematics._

I wouldn't be so sure. Many of us got into programming to flee what we often
call "mathematics". But the stuff we learned in school is quite different from
actual mathematics (rote application of recipes, and tedious exercises,
mostly).

I'm pretty sure we _can_ teach maths to those traumatised programmers. Just
don't utter the "M" word so they don't recoil in horror.

Monoids for instance are a deeply mathematical, yet very simple concept. And
useful too: want to do map-reduce? make sure your binary operation is
associative (meaning, make sure your stuff _is_ a monoid), or you won't be
able to parallelise your reduce step.

~~~
AstralStorm
And you made the mistake here just as I expected. Map-reduce does not require
associativity as long as you know the order of the operation execution. (Or
error due to operation reordering is bounded and acceptable.) You break the
assumption any time you use floating point math.

Then you've added a property to an operation that does not require it. Many
"math types" like to do such things to simplify proofs and there you end up
with variations of spherical cow results, either in applicability or
performance.

~~~
loup-vaillant
> _Map-reduce does not require associativity as long as you know the order of
> the operation execution._

Good luck knowing that order when using a magic map-reduce to parallelise
things for you.

> _You break the assumption any time you use floating point math._

You're just nitpicking here.

Either I care about the non-associativity, and I have to control the ordering
of the reduce operation (the best one might be a parallel bottom-up merge), or
I don't care, and I'll be using -ffast-math already.

~~~
AstralStorm
It is not nitpicking. Either a property is true or it not. This is exactly the
point article author is making when resisting design pattern ambiguity.

If you cheat you will get invalid results sooner than later. Essentially bugs.
Sometimes trivial, sometimes a billion dollar rocket explodes.

If you use math name but lie about it is even worse than if you don't use the
concept at all.

For example a String despite what author says is not a Monoid in almost all
languages as catenation (operation +) is not strictly associative. (Because
memory allocation is different!) Yet he does this mistake...

~~~
loup-vaillant
Hey, _you_ brought up floating points. I talked about monoids, not floating
points. I don't even make the assumption you say I break when I use floating
points. Of _course_ floating points aren't a monoid, let alone a group or a
field.

> _catenation (operation +) is not strictly associative. (Because memory
> allocation is different!)_

What the hell are you talking about? The ordering of operation influences the
address of the result? Who ever cares about that? Even in C, you don't rely on
the value of such addresses —only their uniqueness.

> _Yet he does this mistake..._

Step down your high horse.

------
defined
> I'll write these articles in an authoritative voice, because a text that
> constantly moderates and qualifies its assertions easily becomes unreadable.
> Don't consider the tone an indication that I'm certain that I'm right.

Kudos for including this disclaimer.

The article can be trim and readable, while the disclaimer acts to dissuade
well-meaning reviewers (like - ahem - me), who sometimes value precision and
accuracy more than the big picture, from nitpicking it to death.

~~~
vog
In other words: strong opinions, loosely held.

Shouldn't this be the default expectation, for every article we read, anyway?

Such a disclaimer makes only sense if the article was written by some very
famous author who must reasonably fear that their advice is taken too
dogmatically. Speaking of that, I've never seen people like Martin Fowler make
such a disclaimer.

~~~
mikekchar
To be fair, Martin Fowler's entire blog is a "bliki" because he intends to
(and does) change his entries often. He's even ripped out entire swathes of
his writing when he thinks he's wrong (occasionally frustrating when you think
he's wrong about being wrong ;-) ).

I assume he doesn't make such a disclaimer because he thinks everyone already
realises it -- but I have to agree that it would be nice if he (and other
people as well) did. A lot of times people seem to think that reading
something from a well known author is equivalent to permission to turn their
brains off :-( Instead of, "Oh, that's amazing! Let's try it", they think,
"Oh, that's amazing! We don't have to try it".

------
100ideas
"Physics, Topology, Logic and Computation: A Rosetta Stone (2009) [pdf]"
[https://news.ycombinator.com/item?id=12317525](https://news.ycombinator.com/item?id=12317525)

------
westoncb
I found another interesting approach to formalizing design patterns a few
years ago:
[https://dl.acm.org/citation.cfm?id=2207827](https://dl.acm.org/citation.cfm?id=2207827)
—rather than expressing them as particular instances of more general things
(as you'd do using category theory), he breaks them into a small set of more
fundamental things which can be re-combined into familiar design patterns.

I find it pretty interesting that it's possible to do both of these things...
I'd also bet category theory isn't the only generalization and 'elemental
design patterns' isn't the only decomposition.

Also, while the formalization might be _interesting_ , I wish I could be sold
on its value... I'd definitely be interested in seeing some 'train of thought'
examples of how someone used category theory (for instance) to reason about
some architectural issues for something like... a game engine or web framework
or CAD tool—something where the _domain_ isn't going to make it an easy fit
for category theory on its own.

~~~
proc0
I will check that link out, but I'm willing to bet CT actually captures the
entirety of design patterns plus any subset that you might make out of them.
CT is the most abstract math and is really good for studying structures and
patterns of computation itself.

------
aaimnr
Mark Seemann, TFA's autor wrote a highly praised book Dependency Injection
in.NET and then slowly gravitated towards F# and Haskell. He presents lot of
perspectives on FP often in the context of OO alternatives making it easier to
appreciate FP advantages not just in theory, but in the context of practical
application problems.

I've found his Pluralsight course on Functional Architecture pretty
interesting.

------
uptownfunk
Has anyone come across design patterns w.r.t data science (e.g., importing /
transforming data / creating a modelling record / doing a grid search /
scoring a new data set / outputting results?) I see these things running in
scripts generally, but wondering if there are any applications of design
patterns to a data science workflow.

~~~
terminalcommand
Full disclosure: I have not dabbled with data science, nor I'm an experienced
programmer.

But many of the CS pioneers dealt with the issue of reading input, processing
it, and giving a meaningful output. Recently I've stumbled upon Jackson's
Principles of Program Design and it has really helped me in writing a parser.
IMHO general understanding of structuring a program goes a long way than
arbitrary design patterns. I now am a propenent of modular programming. For me
it resembles functional programming and TDD. Basically it states your program
should be made up of numerous self-contained modules that can be independently
tested.

For data science workflow it could be an import package, further divided in
modules such as general helpers and implementations for different file types;
a computation package etc.

~~~
ambicapter
Its always hard for me to decide how those modules are going to end up
communicating though. Should there be a _lingua franca_ to all your modules?
Or do they all have specialized APIs?

~~~
terminalcommand
Programming to interfaces help in this matter. e.g. if I have a data
interface, I could use the same type on any format I liked. If it is the same
interface, methods are the same too.

For encapsulation and message passing, coroutines work wonders. You could use
a generator in Python, or a goroutine in Golang. And then you could treat
different modules of your program, as if they were a standalone independent
part.

------
proc0
Better to use discovered languages as they say, but also better to learn the
actual abstractions of computation itself, which CT does a great job at,
instead of arbitrary patterns that are based on human intuition.

~~~
filmor
Category Theory is also a set of arbitrary patterns based on human intuition.
Just with the added property of being formalised and consistent :)

~~~
proc0
What about the Curry-Howard-Lambek correspondence? This is directly relate to
why math works so well on the real world. CT and pure FP languages seem to tap
into this fundamental workings of our mind and possibly the universe (CT is
used in quantum mechanics). In contrast things like OOP are modeled based on
intuitive patterns that solve specific problems, and which are often based on
metaphors or abstract analogies, but not a fundamental abstraction of nature.
In other words CT seems to capture the patterns of computation itself.

------
sandGorgon
The problem with category theory and monads, etc are that they are
inaccessible for some of the popular tools. E.g. javascript, python, ruby . It
invariably happens that learning these patterns needs you to learn haskell,
lisp or erlang. Which is where accessibility breaks down.

If there was a conceptual framework that bridges these higher order designs to
accessible languages .. even if partially so, that would be killer.

P.S. I love what dg for python has done -
[http://pyos.github.io/dg/](http://pyos.github.io/dg/)

> _Annoy advocates of the category theory!_

> _With Haskell 's syntax but none of its type system, dg is the best way to
> make fans of static typing shut up already_

~~~
edem
How can you call lisp an inaccessible language? It has less syntax than
anything else. It is as simple as a language gets.

~~~
201709User
It's better to have 50 keywords than 1000 nested brackets.

~~~
empthought
Personally I don't see the advantage of )}]]})} over ))))))).

~~~
kazinator
It's more time consuming to close )}]]})}. With ))) we just repeatedly type
))) until the cursor jumps to the target opening paren we are trying to close.
With a mixture of different parens we have to interrupt what we are doing and
determine the correct parens which will continue the closing sequence.

~~~
flavio81
_> With ))) we just repeatedly type ))) until the cursor jumps to the target
opening paren we are trying to close._

Exactly.

Or, the IDE can close all the parens for you: SLIME command "slime-close-all-
parens-in-sexp", which you can map to whatever key combination you want.

------
fmap
I'm looking forward to reading this series!

Based on the overview, I would call it "From design patterns to algebra",
though. There's (in most cases) no reason to involve categories in a
discussion of monoids/semigroups and isomorphisms.

~~~
madhadron
That would be my choice of title, too. I considered writing exactly such a
thing a few years ago, but realized that I am almost certainly the wrong
person to do so, since I use the algebras but not the design patterns that
approximate them.

------
sigsergv
Design patterns are not formalized enough, we cannot apply category theory
axioms to them.

------
DonbunEf7
I fear that we do not understand patterns well enough to categorify them so
easily.

------
_zachs
Thanks for writing this! Looking forward to reading the articles as they come
out.

------
CodingChef
Does anybody have a recommendation for a book on category theory?

~~~
sjakobi
[https://github.com/hmemcpy/milewski-ctfp-
pdf](https://github.com/hmemcpy/milewski-ctfp-pdf) appears to have quite a few
fans.

------
heroku
how long do we wait until the series is complete, a year?

~~~
wisam
Well, he just posted the second entry in the series. Let's hope he keeps
posting that frequently.

[http://blog.ploeh.dk/2017/10/05/monoids-semigroups-and-
frien...](http://blog.ploeh.dk/2017/10/05/monoids-semigroups-and-friends/)

------
avodonosov
through blockchains?

