Live data from Hacker News

From design patterns to category theory

blog.ploeh.dk

11–20 of 78 posts

Re: From design patterns to category theory

#11
post #7

I found another interesting approach to formalizing design patterns a few years ago: 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 th…

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.

Re: From design patterns to category theory

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

Re: From design patterns to category theory

#13
post #12

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.

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

Re: From design patterns to category theory

#16

> 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,…

If I am understanding you correctly:

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

Re: From design patterns to category theory

#17
post #9

> 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 accurac…

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.

Re: From design patterns to category theory

#18
post #4

> 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,…

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

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.

Re: From design patterns to category theory

#19

> 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,…

Recognizing a design pattern saves you the time and effort of having to independently invent it.

Re: From design patterns to category theory

#20
post #17
post #9

> 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 accurac…

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.

Depends on the audience, really. You have to already know a fair bit before you can critically evaluate the speaker.
Post reply on HN