First of all a modulo is ultra expensive, one does not simply modulo 15 when they already modulo 3 and 5.
The proper structure is if(3){if(5)}elif(5){}else{},unless anyone has a better proposition.
While of course it is possible to define abstractions that handle fizzbuzzing anything for any number, it's clear that the monoid way is a bad overweight bloated approach.
Second the example written is code bloat à la java, writing tons of stuff for no reason.
Third Ruby is a beta prototype language that doesn't have any production ready implementation.
Lastly functional and procedural programming enable you to work at the highest level of abstraction you can think of, whereas OO tends to lock you at a specific abstraction level, which is pretty low and not adapted to most cases.
I have to admit it's impressive how such a simple test can show so many failures in people's deep understanding of programming.
This is another example of someone who I think looked at my code examples but didn't read the post. Fair enough, I guess.
> While of course it is possible to define abstractions that handle fizzbuzzing anything for any number, it's clear that the monoid way is a bad overweight bloated approach.
Why? It is not computationally expensive, and it avoids excess modulo operations. All the dispatching work gets figured out at compile time and you end up with pretty much the same sorts of string concatenation costs you get in every other implementation.
Do you mean to suggest that it is conceptually expensive?
> Lastly functional and procedural programming enable you to work at the highest level of abstraction you can think of, whereas OO tends to lock you at a specific abstraction level, which is pretty low and not adapted to most cases.
I actually agree with this, although I sort of question procedural's place on the totem. I suppose stuff like Forth suggests you're right.
> Bloated, as in, takes way too much space for what it is.
> Additionally, it does _not_ avoid excess mod operations, _and_ the implementation is _broken_ because it won't print fizzbuzz for the 15.
If we're talking about the Haskell version here (I can't tell?), you're wrong on all counts.
• It is about as short as any reasonable impl I've seen of FizzBuzzBazz. Not long at all.
• And it does print out correctly for 15.
• And it does NOT do excess operations. It does exactly one modulo per factor.
Do you not understand how it works? I detail it pretty closely in the post; please look again.
The second ruby version _is_ long, but does not perform excess operations (unless you're complaining about Ruby's implementation of lambdas, which is out of scope). As I said both in my article and in this discussion; coding during an interview is tricky and that's not a bad effort.
Fianlly, the naive if-chain extensions are deliberately wrong to extend, but my initial research and experience is that most programmers don't realize that until they try it once. But then, they're lifted right from Rosetta Code so they're hardly unrepresentative of what people consider an "unacceptable" version of Fizzbuzz.
The proper structure is if(3){if(5)}elif(5){}else{},unless anyone has a better proposition. While of course it is possible to define abstractions that handle fizzbuzzing anything for any number, it's clear that the monoid way is a bad overweight bloated approach.
Second the example written is code bloat à la java, writing tons of stuff for no reason.
Third Ruby is a beta prototype language that doesn't have any production ready implementation.
Lastly functional and procedural programming enable you to work at the highest level of abstraction you can think of, whereas OO tends to lock you at a specific abstraction level, which is pretty low and not adapted to most cases.
I have to admit it's impressive how such a simple test can show so many failures in people's deep understanding of programming.