2 ms·

Cycled lists and the modulo operator are two different abstractions for thinking about the same problem, in the same vein of "blind men grasping at elephant." T

by johnfn 10y ago

Cycled lists and the modulo operator are two different abstractions for thinking about the same problem, in the same vein of "blind men grasping at elephant." They are different perspectives on the similar problem. The reason we think that cycling a list is "clever" but using modulo is "boring" is because most of us use modulo often, and cycling rarely. There is nothing inherently "clever" about either of the two approaches. In an alternate universe where we all used Haskell, perhaps the modulo solution would come off as "clever". And perhaps this article would be pointing out the flaws in the modulo approach instead: the fact that numbers divisible by both 3 and 5 have to be treated by a special case, the fact that it doesn't easily generalize to fizz buzz bazz, etc.

emn13 10y ago
The issue with the first fizzbuzz isn't just cylcling lists, it's also the use of zipWith. At least, that's what causes some of the brittleness in his examples. --- Also, I think you're slightly wrong in that cycled lists and modulo are "just different abstractions" - they may be to a machine, but they are not to people. And in this case, critically, the original problem's phrasing is much closer to the modulo implementation than the cycled list equivalent: "...for multiples of three print Fizz...". By choosing to encode that constant 3, rather than represent it, you're being clever; by failing to use a straightforward analog of "is multiple of", you're being clever. This "encoding" has real risks - for instance, because you're human, you'd immediately notice that 5 is not 6. You don't need to think to do that; don't need to process equivalence or do any kind of algebraic reasoning; a kid can and will notice the identical shapes before they can talk or walk. It's built in. By contrast, even a trained professional might overlook a list with 5 spaces followed by Buzz as opposed to a list of 5 elements consisting of spaces followed by a single Buzz. Sure, it's a really stupid mistake, and one I hope you make very rarely - but people make stupid mistakes. No need to encourage that habit by making them think. So no, it's not that cycled lists are bad and module is good, it's that the problem description is closer to the definition of modulo than it is to list cycling. (This is my interpretation, the article's definition of clever is more about seems and changes and doesn't really touch this).
- sixbrx 10y ago
  > problem's phrasing is much closer to the modulo implementation But I take the problem description as only describing a specification of what output is wanted, I don't think it's intended as a guidelines of how it should be implemented internally. If teams I've been on ever implemented things as some of our clients imagined they would work (which we had to sit through while trying to coerce some coherent requirements from them) we'd have been in a world of hurt :)
- groovy2shoes 10y ago
  Modular arithmetic (a.k.a. clock arithmetic) is equivalent to cycles in a very real, mathematical way. There's a reason that clocks are round -- in order to count the naturals modulo 12 (and again modulo 60), you simply need to cycle 1..12 (or 1..60). I'd argue that for anyone who understands modular arithmetic, the `cycle` solution doesn't seem particularly clever. Anyone with enough knowledge of number theory to understand that "x is a multiple of y" -> "y divides x" -> "x (mod y) = 0" ought to have an understanding of the relationship between modular arithmetic and cycles. This is introductory-level discrete mathematics.

by johnfn 10y ago

emn13 10y ago

The issue with the first fizzbuzz isn't just cylcling lists, it's also the use of zipWith. At least, that's what causes some of the brittleness in his examples. --- Also, I think you're slightly wrong in that cycled lists and modulo are "just different abstractions" - they may be to a machine, but they are not to people. And in this case, critically, the original problem's phrasing is much closer to the modulo implementation than the cycled list equivalent: "...for multiples of three print Fizz...". By choosing to encode that constant 3, rather than represent it, you're being clever; by failing to use a straightforward analog of "is multiple of", you're being clever. This "encoding" has real risks - for instance, because you're human, you'd immediately notice that 5 is not 6. You don't need to think to do that; don't need to process equivalence or do any kind of algebraic reasoning; a kid can and will notice the identical shapes before they can talk or walk. It's built in. By contrast, even a trained professional might overlook a list with 5 spaces followed by Buzz as opposed to a list of 5 elements consisting of spaces followed by a single Buzz. Sure, it's a really stupid mistake, and one I hope you make very rarely - but people make stupid mistakes. No need to encourage that habit by making them think. So no, it's not that cycled lists are bad and module is good, it's that the problem description is closer to the definition of modulo than it is to list cycling. (This is my interpretation, the article's definition of clever is more about seems and changes and doesn't really touch this).

sixbrx 10y ago
> problem's phrasing is much closer to the modulo implementation But I take the problem description as only describing a specification of what output is wanted, I don't think it's intended as a guidelines of how it should be implemented internally. If teams I've been on ever implemented things as some of our clients imagined they would work (which we had to sit through while trying to coerce some coherent requirements from them) we'd have been in a world of hurt :)
groovy2shoes 10y ago
Modular arithmetic (a.k.a. clock arithmetic) is equivalent to cycles in a very real, mathematical way. There's a reason that clocks are round -- in order to count the naturals modulo 12 (and again modulo 60), you simply need to cycle 1..12 (or 1..60). I'd argue that for anyone who understands modular arithmetic, the `cycle` solution doesn't seem particularly clever. Anyone with enough knowledge of number theory to understand that "x is a multiple of y" -> "y divides x" -> "x (mod y) = 0" ought to have an understanding of the relationship between modular arithmetic and cycles. This is introductory-level discrete mathematics.