From design patterns to category theory
blog.ploeh.dk
blog.ploeh.dk
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).
I’m fairly sure that’s the entire premise of his series.
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.
The original comment did a good job of illustrating this. It's not clear from this post what category theory can do for a person programming with design patterns in mind (in other words, how will it change their behaviors?).
It is like trying to teach calculus by showing baked approaches at solving integral equations.
Just because you call a thing a Monoid does not mean it is one. Similar in how people use the design patterns in real life, except these do not demand clarity and of you partly misnamed it people are not confused.
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.
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.
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.
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...
> 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.
To rephrase what is often written in a better form, misses the value of teaching the translation. You need to show the things you would never have written, enabled by the better form, to show that it is better.
sub: better = formal + ...
You have to verify all required properties anyway or you end up in a similar place.
Generic does not mean general, but programming languages do not have an easy way to verify properties so you end up with general.
In theory sure, but I've never seen anyone use a counting sort in production code.
> You have to verify all required properties anyway or you end up in a similar place.
You go from n * m to n + m though, and since the properties are often simple and standard they might be done for you in the standard library already.
> Generic does not mean general, but programming languages do not have an easy way to verify properties so you end up with general.
Typeclasses give a reasonable representation; newer languages let you require their properties to be verified if you really want.
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.
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.
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".
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.
I haven't read that book, but it sounds similar to how Peter van Roy deconstructs programming paradigms:
[1] https://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf
[2] https://en.wikipedia.org/wiki/File:Programming_paradigms.svg
How do these two approaches differ from each other? As far as I can see, they’re exactly the same thing. From the linked article:
> Smith introduces a foundational layer of patterns terminology: a collection of core patterns that can't be decomposed further.
This is exactly the purpose of category theory. Rather than have group theory, set theory, propositional logic, etc., category theory unites all of these into something that cannot be decomposed further (identity and composition).
I've found his Pluralsight course on Functional Architecture pretty interesting.
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.
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.
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/
>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
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.
I picture the difference as that between a role playing game and chess: complex, domain-specific rules on one side, simple and abstract rules on the other.
There's a lot more to accessibility than how easy the syntax is to grok. This is just one simple and limited example.
Yet there are a ton of books written about Lisp in all kinds of topics and applications. Not to mention really well-written tutorials like "Practical Common Lisp".
Plus, the documentation/reference of the language itself is comprehensive and well written, comparing favorably to the documentation for most programming languages out there.
You are using one right now: Hacker News is written on a Lisp: Arc.
Also, the first HTTP 1.1 compliant server and used by the W3C to debug the HTTP 1.1 reference implementation, was written in Common Lisp.
I agree that Haskell is built around those concepts. But the point of learning category theory is to change your mindset when programming. And even in Javascript, it is super useful. (basically because, while trying to learn category theory, you become fluent in functional programming ).
>Part 3 will start to dance the fine line between practical programming and academic absurdity. We'll look at comonads, f-algebras, free monads, yoneda, and other categorical constructs.
I myself like this - https://github.com/valentjedi/ddd-dynamic - but I'm beginning to think maybe all of this is not the right paradigm for programming in languages like javascript or python. The success of tools like React or RxJava in Android makes me think that the tools define the paradigm and not the other way around... no matter how much we want it to be.
I thought the original Rx was a Haskeller saying "Hey a 'dsl' built on a monad would be really powerful here in C#" and implemented it. Then it spread to other langs from there.
In my opinion the biggest hurdle is the fact that getting to unrestand purely functional programming is pretty difficult. You start with monads, but quickly find out they do not compose. Move on to monad transformers, good for the simple stuff, but then you hit another wall because they don't compose either! Move on (up!) to tagless final and/or free monads. There are _a lot of_ concepts that don't have any equivalent in "the real world". The gang of four design patters are a child's toy in comparison.
I'm have been trying to answer this question for quite some time. In Haskell, writing monads or applying category theory is part of the idiomatic language. Not so in js or python.
for example, if you want to apply haskell like concepts in javascript, the closest thing I know is purescript (http://www.purescript.org/) or Bucklescript. So you need to switch over to a different language to achieve the richness of these concepts.
I'm hardpressed to apply these concepts idiomatically to the mainstream languages. Compare this to design patterns or OO, or reactive programming (via rxjs or whatever) - which are so accessible that they are now the reason to learn a particular language!
However, there are many libraries which make functional programming in Python seem viable. See eg: https://pypi.python.org/pypi/PyMonad/
It can, but without a type system you lose most of the benefits. You can put monads in there but if you refactor fearlessly the way you would in Haskell (without tests), you'll get production bugs.
> Compare this to design patterns or OO, or reactive programming (via rxjs or whatever) - which are so accessible that they are now the reason to learn a particular language!
Isn't that the same thing? Monads etc. are the reason to learn Haskell.
A functional program is simply a program that is made up of a single mathematical expression. Complexity is achieved in functional programming by composing smaller expressions into a single big expression. It should be possible to write your entire functional program as a single expression or statement (not saying you should do it, but it should be possible). That's it. That means all your python functions should be a single expression only (use lambda always instead of def; or if you must use def make sure all your variables remain immuted)
If you want to apply like category theory to it, then just make sure your python functions always stick to specific types. Don't let a function take in either a string or an int and return a list or a iterator or any bullshit like that. Keep the typing consistent... If you define all your functions to behave mathematically like only taking in a string and only returning an int, not an int or a None... then you are following category theory.
So nothing like this:
def someFunc(value):
if value == "hello"
return 1
elif value == 123:
return [1,"world"]
blah = lambda a: "hello" if a is None else 304
If you try this style at work, people will complain haha, I don't recommend it
As an example, a maybe monad in python can be implemented by having a monadic function return either:
["Just", 1]
["Nothing", None]
bind = lambda a, f: a if a[0] == "Nothing" else f(a[1])
Weirdly how someone chooses to implement a monadic value and the bind operator suffers from the same problem as what this article writer complains about in OOP design patterns. Both monads and design patterns really depend on previous understanding of a pattern, and a variation on how someone chooses to implement the bind operator or a design pattern can really throw off people.
Here is an example of an alternative variation of the "Maybe" monad in python, for the return values:
["Only", 1], None
bind = lambda a, f: f(a[1]) if a is not None else NoneIs there a resource for this ? or good old intuition ?
Just remember Absolutely ANY design pattern / data structure can be a monad as long as you can get an internal value out of that abstraction and define a bind operator to compose monads together.
This rule tells it all:
(>>=) :: m a -> (a -> m b) -> m b
You can define the bind operator to do whatever you want, it just needs to follow the type signature above and be associative.
A list is not a monad — it’s just a container of values, ie. a functor. A monad is a data structure defines a computation in a specific context, and allows composing these in a sequential manner. For example, the Haskell IO monad is a computational context in which you can do input/output, and all of these IO operations are represented using a data structure of the type “IO <return_value>”.
For example, the function “readLine” has the type “IO String”, and represents a computation that reads a line from standard input and returns it as a string. At runtime, evaluating this value will result in the runtime system asking the user for some input, and at compile-time this is represented as the string (that the user enters at runtime) inside the IO monad.
Huh? List is very much a monad.
But I can't make sense of the definition of >>= for the list in Haskell, which is:
xs >>= f = [y | x <- xs, y <- f x]
[1,2,3] >>= return . (+1) > [1,-2,3] >>= (\x -> replicate (abs x) x)
[1,-2,-2,3,3,3]Besides, I don't think you would gain anything by using CT concepts in a language that won't resolve type polymorphism for you. It will lead to a mess of a code, where you'll have to make everything explicit.
By the way, great language. an await command in a where scope is just phenomenal. Between seamless lambdas, interdependent functional declarations, and forced async I don't think it missed any language at its trolling.
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.
http://blog.ploeh.dk/2017/10/05/monoids-semigroups-and-frien...