There was a great introduction to QuickCheck and many other interesting concepts at 36c3:
<a href="https://www.youtube.com/watch?v=_2tK9G7rKQQ" rel="nofollow">https://www.youtube.com/watch?v=_2tK9G7rKQQ</a><p>I'd recommend it if you don't understand much of the article.
To me this says the parallel library the author described isn't as efficient as it could be because it's enforcing an unexpected ordering constraint.
It seems like the monoid-thinking just obscures. Positive integers under addition are not a monoid (no identity) but you can still map-reduce their sum of squares. All that you really need is associativity, and associative operations are associative.
That’s a great article! I have no background in either Haskell or CS but was captivated to read until the end. Great job!<p>Nit: I think this would read better if the author replaced “personal theory” with “hypothesis”.
There seems to be a lot of work to get not very much. Maybe the point of this article is more about faffing around with quickcheck but the conclusion should basically be:<p>1. Parallel [efficient] MapReduce requires a commutative monoid for deterministic results<p>2. A naive implements of parallel MapReduce in haskell using par doesn’t because it will only do reduce operations in a certain order. Imagine if the map for every second element took 0s and the others took 10s. In normal mapreduce, you would reduce together the fast half of the results as they come in but in this haskell implementation you would need to sit on them and wait until the other adjacent elements come in. In the article’s very naive implementation, you can’t even reduce together the first two elements together until you’ve reduced everything after them (modulo some weirdness around lazy evaluation)<p>I think if one thinks of mapreduce as an operation on sets not lists, it should be obvious that the monoid must be commutative.