5 ms·

> It seems to me that some design patterns are essentially ad-hoc, informally specified, specialised instances of basic category theory concepts. There is a fl

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

empath75 9y ago
> 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. I’m fairly sure that’s the entire premise of his series.
closed 9y ago
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 9y ago
  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.
  - closed 9y ago
    I don't know if they're bad at higher abstractions, or if the pay-off of a higher abstraction isn't always there (or is unclear). 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?).
    - AstralStorm 9y ago
      Unless you somehow teach people to actually run math proofs on the fly, it won't do any good either way if they start using mathematical descriptions since they will still "fake out" the math. 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.
  - loup-vaillant 9y ago
    > 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.
deleted 9y ago
[deleted]
mjburgess 9y ago
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 + ...
c3534l 9y ago
Recognizing a design pattern saves you the time and effort of having to independently invent it.
lmm 9y ago
It's always possible to write the non-generic version of a generic method and still get it right. I mean, there are mistakes that the formality will help you avoid (e.g. if you violate associativity, even in a seemingly trivial way, it will always come to bite you at the worst possible time), but it's possible to just not make those mistakes. The advantages of the generic formalism over reimplementing it specifically every time are, just like for any other use of generics, saving code and being able to reuse existing library methods (e.g. traverse, mfix, the various recursion-schemes traversal operators).
- AstralStorm 9y ago
  There are disadvantages too. Most often performance and not in a small way. Compare general comparison sorts with counting sorts for a simple example. The latter require additional properties on the value making them much less general, but you gain major performance benefits. Additionally you assume that you can skip the specific proof given the general one. That is not the case a lot of the time. 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.
  - lmm 9y ago
    > Compare general comparison sorts with counting sorts for a simple example. The latter require additional properties on the value making them much less general, but you gain major performance benefits. 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.

empath75 9y ago

> 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. I’m fairly sure that’s the entire premise of his series.

closed 9y ago

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 9y ago
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.
- closed 9y ago
  I don't know if they're bad at higher abstractions, or if the pay-off of a higher abstraction isn't always there (or is unclear). 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?).
  - AstralStorm 9y ago
    Unless you somehow teach people to actually run math proofs on the fly, it won't do any good either way if they start using mathematical descriptions since they will still "fake out" the math. 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.
- loup-vaillant 9y ago
  > 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.

deleted 9y ago

[deleted]

mjburgess 9y ago

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

c3534l 9y ago

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

lmm 9y ago

It's always possible to write the non-generic version of a generic method and still get it right. I mean, there are mistakes that the formality will help you avoid (e.g. if you violate associativity, even in a seemingly trivial way, it will always come to bite you at the worst possible time), but it's possible to just not make those mistakes. The advantages of the generic formalism over reimplementing it specifically every time are, just like for any other use of generics, saving code and being able to reuse existing library methods (e.g. traverse, mfix, the various recursion-schemes traversal operators).

AstralStorm 9y ago
There are disadvantages too. Most often performance and not in a small way. Compare general comparison sorts with counting sorts for a simple example. The latter require additional properties on the value making them much less general, but you gain major performance benefits. Additionally you assume that you can skip the specific proof given the general one. That is not the case a lot of the time. 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.
- lmm 9y ago
  > Compare general comparison sorts with counting sorts for a simple example. The latter require additional properties on the value making them much less general, but you gain major performance benefits. 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.