Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From design patterns to category theory

blog.ploeh.dk

Post reply on HN
Print view View original

61–70 of 78 posts

Re: From design patterns to category theory

#61

Post by AstralStorm »

loup-vaillant wrote: post #49
AstralStorm wrote: post #18

Earlier quoted context omitted.

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

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

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.

Re: From design patterns to category theory

#62

Post by AstralStorm »

lmm wrote: post #45
conistonwater wrote: post #2

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

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…

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.

Re: From design patterns to category theory

#63

Post by loup-vaillant »

AstralStorm wrote: post #61
loup-vaillant wrote: post #49

Earlier quoted context omitted.

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

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…

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

Re: From design patterns to category theory

#64

Post by AstralStorm »

loup-vaillant wrote: post #63
AstralStorm wrote: post #61

Earlier quoted context omitted.

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…

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

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

Re: From design patterns to category theory

#65

Post by loup-vaillant »

AstralStorm wrote: post #64
loup-vaillant wrote: post #63

Earlier quoted context omitted.

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

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…

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.

Re: From design patterns to category theory

#66

Post by lmm »

AstralStorm wrote: post #62
lmm wrote: post #45

Earlier quoted context omitted.

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…

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…

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

Re: From design patterns to category theory

#67

Post by flavio81 »

hoorayimhelping wrote: post #32
edem wrote: post #23

Earlier quoted context omitted.

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

How many stack overflow questions and answers are there for lisp(s)? How many for Java? How many applications on the web are written in a lisp? How many are written in Java (or Python or Ruby or PHP)? There's a lot more to accessibility than how easy the syntax is to grok. This is just one simple and limited example.

>How many stack overflow questions and answers are there for lisp

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.

Re: From design patterns to category theory

#68

Post by flavio81 »

hoorayimhelping wrote: post #32
edem wrote: post #23

Earlier quoted context omitted.

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

How many stack overflow questions and answers are there for lisp(s)? How many for Java? How many applications on the web are written in a lisp? How many are written in Java (or Python or Ruby or PHP)? There's a lot more to accessibility than how easy the syntax is to grok. This is just one simple and limited example.

>How many applications on the web are written in a lisp?

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.

Re: From design patterns to category theory

#69

Post by flavio81 »

kazinator wrote: post #58
empthought wrote: post #30

Earlier quoted context omitted.

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

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.

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

Re: From design patterns to category theory

#70

Post by edem »

kryptiskt wrote: post #27
edem wrote: post #23

Earlier quoted context omitted.

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

Brainfuck has even simpler syntax and is even more inaccessible. There's way more to languages than syntax.

Brainfuck it unintuitive, but Lisp is. You can learn the lambda calculus in 10 minutes. You can'c tompare the two.
Post reply on HN