29 ms·

Less? Even ignoring the glut of imports, it's significantly longer than the straightforward and more extensible attempt where you just chain a few `if`s. (The a

Less? Even ignoring the glut of imports, it's significantly longer than the straightforward and more extensible attempt where you just chain a few `if`s. (The article did strawman that attempt, but it was transparent enough about it.)

KirinDave 9y ago
Which if my examples is it longer than? It's been awhile since I wrote this so...
- Veedrac 9y ago
  None of the examples you specifically gave. As I said, it strawman'd the easy method.
  - KirinDave 9y ago
    I don't know what the "easy" method you're referring to is. I did include an else-if chain and did my best to not inflate it. Even though it was 5 years ago I need to revisit this blog to update the pronouns anyways, so please do correct me.
    - Veedrac 9y ago
      loop i = 0..100 { out = "" if i % 3 == 0 { out += "Fizz" } if i % 5 == 0 { out += "Fizz" } if i % 7 == 0 { out += "Fizz" } if out == "" { out = str(i) } display out }
      - KirinDave 9y ago
        Is this really much shorter than my Haskell example? If we count the import decls it seems to be a bit of a wash.
        Veedrac 9y ago
        It's about 0.7x the length of the final Haskell version, ignoring indentation and imports, but I don't really care about golfing. My point was simply that your statement that you "write less of [your] own code" was not justified.
        KirinDave 9y ago
        > It's about 0.7x the length of the final Haskell version, The final haskell version with the explicit "show" does 2 things your example here does not: offer parameterized final case, and use a rope data structure for the strings. But in a very real sense your code is a special case of the haskell code c_wraith offered. You're using a builtin monoid (strings) and explicit control flow to do it, so your code can't be reused in other contexts. If I tactically asked you for a feature that made the output = '' in some cases, you'd have to refactor pretty significantly. The haskell version not only doesn't have that weakness, but it can even be used to do more abstract things like count the number of times Bar _would_ be printed if we wanted to do that. > but I don't really care about golfing Okay, but for someone that's indifferent you are sorta gut punching c_wraith's code by penalizing haskell for explicit modules and imports for libraries, writing code in a style where I can explain it line-by-line, and comparing a simplified version to my most complicated version. > My point was simply that your statement that you "write less of [your] own code" was not justified. It's a debate I'm willing to have, but I think my blog post defends this point. That code lacks any sense of abstraction over very common patterns, and it ultimately ends up appealing to a builtin monoid and its operations to accomplish the same thing. It's fizzbuzz, so it's hardly a crisis. But the point of this entire discussion here is about how even in these small cases we can see big abstractions appear and be relevant. I'd rather add 4 import lines and lean on code tested till the cows come home than pretend I can't ever have a bad day writing bespoke logic. Edit: it occurs to me that implicitly in this assumption is the notion that we must defend using simple, wide-reaching abstractions. Can you give a good reason why something as trivial as "monoids" isn't exactly the sort of thing we should all be using, as opposed to bespoke logic that on a good day conforms to this pattern? Why _wouldn't_ we?
        9y ago

KirinDave 9y ago

Which if my examples is it longer than? It's been awhile since I wrote this so...

Veedrac 9y ago
None of the examples you specifically gave. As I said, it strawman'd the easy method.
- KirinDave 9y ago
  I don't know what the "easy" method you're referring to is. I did include an else-if chain and did my best to not inflate it. Even though it was 5 years ago I need to revisit this blog to update the pronouns anyways, so please do correct me.
  - Veedrac 9y ago
    loop i = 0..100 { out = "" if i % 3 == 0 { out += "Fizz" } if i % 5 == 0 { out += "Fizz" } if i % 7 == 0 { out += "Fizz" } if out == "" { out = str(i) } display out }
    - KirinDave 9y ago
      Is this really much shorter than my Haskell example? If we count the import decls it seems to be a bit of a wash.
      - Veedrac 9y ago
        It's about 0.7x the length of the final Haskell version, ignoring indentation and imports, but I don't really care about golfing. My point was simply that your statement that you "write less of [your] own code" was not justified.
        KirinDave 9y ago
        > It's about 0.7x the length of the final Haskell version, The final haskell version with the explicit "show" does 2 things your example here does not: offer parameterized final case, and use a rope data structure for the strings. But in a very real sense your code is a special case of the haskell code c_wraith offered. You're using a builtin monoid (strings) and explicit control flow to do it, so your code can't be reused in other contexts. If I tactically asked you for a feature that made the output = '' in some cases, you'd have to refactor pretty significantly. The haskell version not only doesn't have that weakness, but it can even be used to do more abstract things like count the number of times Bar _would_ be printed if we wanted to do that. > but I don't really care about golfing Okay, but for someone that's indifferent you are sorta gut punching c_wraith's code by penalizing haskell for explicit modules and imports for libraries, writing code in a style where I can explain it line-by-line, and comparing a simplified version to my most complicated version. > My point was simply that your statement that you "write less of [your] own code" was not justified. It's a debate I'm willing to have, but I think my blog post defends this point. That code lacks any sense of abstraction over very common patterns, and it ultimately ends up appealing to a builtin monoid and its operations to accomplish the same thing. It's fizzbuzz, so it's hardly a crisis. But the point of this entire discussion here is about how even in these small cases we can see big abstractions appear and be relevant. I'd rather add 4 import lines and lean on code tested till the cows come home than pretend I can't ever have a bad day writing bespoke logic. Edit: it occurs to me that implicitly in this assumption is the notion that we must defend using simple, wide-reaching abstractions. Can you give a good reason why something as trivial as "monoids" isn't exactly the sort of thing we should all be using, as opposed to bespoke logic that on a good day conforms to this pattern? Why _wouldn't_ we?
        9y ago