I understood from near the very beginning that this wasn't really about Fizzbuzz. All the way through the post, I was waiting for the author to get a real world example instead of Fizzbuzz. Yet, I got to the end of the post and realized it was already pretty long.
I think in talking about programming, we are often hindered by the fact that it is much more complicated than our brains can handle. Our only choices are to write novel length treatments of real programs or short story length posts about a toy program, or just the tiniest piece of a real program.
Which is all to say, as sick of hearing about Fizzbuzz as I am, I'm glad there are silly little examples like it that we all know. Even though it was ostensibly about interviewing, that was a much clearer introduction to monoids than most. I think it was largely because it was in reference to Fizzbuzz: something very concrete with which we're all familiar.
Too many introductions to Haskell's abstractions are too abstract. Good on the author for finding away around that.
What sort of surprised me as I shopped my copy around and showed people the python-add-one-factor example is that even programmers I consider experts didn't realize how quickly the conditional cascade blows up. It's easy to miss. And I looked around for people to mention this in blog posts, but almost no one does. So I feel like there's a bit of life left in the old fizzbuzz yet.
I think the non-blown cascade is exactly what makes fizzbuzz aggravating. With three noises, the linear solution clearly dominates. With two, the exponential is actually shorter -- but feels unclean.
I've been programming some game servers, and I have the same problem with guaranteed two-player games; I feel dirty hard-coding the logic to assume two players, yet making it general enough for N players makes it absurdly more complex for no gain, which is a net loss.
(And yes, before anyone pops in, these are guaranteed two-player games. Of all the rules of the games in question which have changed over time, that is the one rock-solid constant which will not change in this application.)
I think in talking about programming, we are often hindered by the fact that it is much more complicated than our brains can handle. Our only choices are to write novel length treatments of real programs or short story length posts about a toy program, or just the tiniest piece of a real program.
Which is all to say, as sick of hearing about Fizzbuzz as I am, I'm glad there are silly little examples like it that we all know. Even though it was ostensibly about interviewing, that was a much clearer introduction to monoids than most. I think it was largely because it was in reference to Fizzbuzz: something very concrete with which we're all familiar.
Too many introductions to Haskell's abstractions are too abstract. Good on the author for finding away around that.