> The entire point of FizzBuzz, as a programming practice, is to ensure the programmer does not try to write this exact code

No, the point of FizzBuzz, which is an interview practice is to make sure that the candidate has literally the minimum ability to translate a natural-language problem description into code.

There is no point using it for anything else. Not demos of languages or tools, not looking for a particular shape of solution, you don't even really need to let them finish writing a bug-free version of it. It is only to filter out the people who "learned a language" but cannot actually write a program. Which is unfortunately a ton of people.

https://imranontech.com/2007/01/24/using-fizzbuzz-to-find-de...

I agree that I hate this solution. However, are you saying that this is a bad FizzBuzz solution to you? (Python)

  nums = list(range(100))
  
  def fizzbuzz(n):
    if n % 15 == 0:
      return "FizzBuzz"
    elif n % 3 == 0:
      return "Fizz"
    elif n % 5 == 0:
      return "Buzz"
    else:
      return str(n)
  
  print(" ".join(map(fizzbuzz, nums)))

I think it's far better than:

  nums = list(range(100))
  
  for num in nums:
    if num % 3 == 0:
      print("Fizz", end="")
    if num % 5 == 0:
      print("Buzz", end="")
    if num % 3 != 0 and num % 5 != 0:
      print(num, end="")
    print(" ")

EDIT: Formatting, typo

I don’t want to argue in favour of the Beads solution but I think the right way to describe the logic is as follows:

  input is n
  | 3 divides n | 5 divides n | result     |
  |—————————————|—————————————|————————————|
  | Yes         | Yes         | “FizzBuzz” |
  | Yes         | No          | “Fizz”     |
  | No          | Yes         | “Buzz”     |
  | No          | No          | n.toString |
  print result

The key points are:

1. The logic is declarative: the order of the rows in the table doesn’t matter.

2. It tests for divisibility in words rather than a potentially confusing idiom (how does % behave for negative numbers? Is it defined for floats in this language?)

3. The structure allows you (or a compiler) to check that no case is missed.

4. It should be easier to convince oneself that modifications to the code do what they are supposed to.

The funny thing is that looking things up in tables is much more common in excel.

I agree, I think that's close to isomorphic to my first solution! There's a "mapping" from numbers to strings, and this is the mapping.

At the risk of the classic "no here's the fizzbuzz code" while then getting it wrong, the typical case you're trying to draw out is like the second but:

Not printing in the middle, return a string and afterwards print it.

Each step adds to the string, and if it's still empty by the end you just put the number in.

The next stages are often to add another number, then something more complex (if it's a prime number). As you do this, the concatenation version grows slowly while the first approach explodes in combinations.

In his defense: I think the logic of his programming language and the pattern match works just fine: it's a mod over bounded linear range checking a remainder. He's just showing off that he can check "mod 15" against a list of potential values, or at least that's my reading of it.

> is to ensure the programmer does not try to write this exact code

I agree with your thoughts around the language constraints, but I see more room for what you once could have gotten from using FizzBuzz as a minimum-skill filter. It depends on the level you're hiring at.

From a novice engineer I would be content if they're demonstrating awareness that multiples of 15 represent an edge case without it being included in the instructions.

If I'm hiring someone more senior, I'd expect them to provide (or iterate to) a more optimized solution to FizzBuzz.

But in a further tangent - I think this using this type of question as a minimum-talent filter stopped becoming viable as soon as it became commonly used. In the time since, it's become more a minimum-knowledge filter -- and that doesn't tell you anything about the candidate's methods in solving a problem with derivable requirements.

There are about 3 slightly different methods for doing FizzBuzz, in any language, and this was but one of them.

You could express it also as an empty string, then concatenating as necessary: ''' // to those objecting to using a modulo-15 test, // we could have done the above code as follows: var ss = "" if mod(b.cell_seq, 3) == 0 "Fizz" &=> ss if mod(b.cell_seq, 5) == 0 "Buzz" &=> ss if ss == "" ss = to_str(b.cell_seq) '''

The problem with FizzBuzz as a programming language exploration is that it is far too short of a program to reveal the totality of a language, since it only consists of using the if/pattern match capability, modulo function, concatenating strings, and converting an integer to a string. The Stock market ticker program is a much better demo of the language, because it shows how to do client/server programming in a very easy way.

I think that is a better FizzBuzz example. You are right that it isn't meant to showcase the whole language, but lacking a composable solution (mod N1 || mod N2... for N prime factors) makes me immediately think the language does not lend itself well to that kind of composition.

And as others mentioned, Fizzbuzz is merely a "can you program anything test." But I do prefer the "general" fizzbuzzjazz, which accepts a list of numbers and a list of words [fizz, buzz, jazz,...] and emits the strings for appropriate prime factors.

Depends on your definition of 'simple', I guess.

My preference is to have all behaviours be explicit in the declared code, rather than implicit or as a side-effect. Much simpler to read and reason about the program.

Clarity over cleverness. To that end, I prefer this version over 'hiding' the mod 15 case for the sake of saving a line of code.

I also appreciate languages that warn (or better, require) that all cases are covered.

This solution looks ugly, but i don't think its "wrong". The point of fizzbuzz is to check they can write any trivial program. It works, its a pass.

I don't understand your objection.

I think he's saying that inside of the loop in FizzBuzz, it should look like something like this (Python-esque pseudocode, assuming for a second print() doesn't add a newline automatically):

    if x % 3 == 0:
        print("Fizz")

    if x % 5 == 0:
        print("Buzz")

    if x % 3 != 0 and x % 5 != 0:
        print(x)

    print("\n")

i.e. no special "FizzBuzz" case for when it's divisible by 15, it just naturally falls out of the first two if's. It's a bit of a silly objection though, the it's fine to write it as the author did.

as I learned above you can use the "end" kwarg to avoid the newline:

    print("Fizz", end="")

That doesn't work here, though, because then you don't get "FizzBuzz" for 15 -- you get "Fizz" and "Buzz" on separate lines.

A lot of the rosetta code examples show the simple and the more complex example or less use of built-in functions to show they can express it with the core language.

Sure, but I think that's a different objection?