Functional / Declarative FizzBuzz

Question

I spent some time today trying to write FizzBuzz in a functional/declarative style. I thought it would be a good chance to get some feedback on it since I've been doing functional programming for about a year now.

(I know there are some similar questions asked here before, but their approach to the code has been different to mine and it would be good to get feedback more specific to my code)

The main things I want to know are:

• How consistent is this code with the best practices in functional and declarative programming?
• Are there any bad practices in it that I should be aware of?

const isFizz = number => number % 5 === 0
const isBuzz = number => number % 3 === 0

const newArrayInRange = (min, max) => [...Array(max + 1).keys()].slice(min)

const fizzBuzz = (min, max) => newArrayInRange(min, max)
  .map(number => {
    if (isFizz(number) && isBuzz(number)) {
      return 'fizzbuzz'
    }
    if (isFizz(number)) {
      return 'fizz'
    }
    if (isBuzz(number)) {
      return 'buzz'
    }
    return number
  })
  .join('\n')

console.log(fizzBuzz(1, 100))

Answer 1

Maybe some changes

• Removing the arrays needed to hold the counter, its a huge overhead just for a counter.
• Avoiding excessive logic statements using (num % val) to return strings and using the empty string to add a number (see code marked /*A*/)
• Putting everything into an array to join when done as you have done. It is the quickest way to build a long string in JavaScript.

Thus we end up with the following...

const fizz = num => num % 5 ? "" : "fizz";
const buzz = num => num % 3 ? "" : "buzz";
const fizzBuzz = num => fizz(num) + buzz(num);
const fizzBuzzer = (min, max) => {
    const res = [];
    do {
        const fb =  fizzBuzz(min);
        res.push(fb ? fb : min);       /*A*/
    } while (min++ < max);

    return res.join("\n");
}

Personally the function fizz, buzz, fizzBuzz are just adding code without good reason and would need to be closed over to avoid polluting what ever scope it is in.

Thus the 3 function become the expression right of const fb =

Also I am not a fan of arrow functions in an open scope so using a function declaration to ensure accessibility.

function fizzBuzzer(min, max) {
    const res = [];
    do {
        const fb =  (min % 5 ? "" : "fizz") + (min % 3 ? "" : "buzz");
        res.push(fb ? fb : min);
    } while (min++ < max);

    return res.join("\n");
}

You ask

How consistent is this code with the best practices in functional and declarative programming?

Best practice, well that is subjective, contextual and would only have comparative meaning when compared to "bad" code?

Your code is not bad, it works , it would have been worse 3 years back due to the way JS engines handled arrays, but now most optimizers recognize the pattern and make it fly.

There is a zillion ways to write any bit of code. JS programmers can still not agree on the use of semicolons and whether or not automatic semicolon insertion was a good idea or not, so how is any bit of code ever going to be best practice.

Are there any bad practices in it that I should be aware of?

OMDG Yes there is.... Semicolons, where are they?

---

// Example of bad
const fizzBuzzard = (min, max) => {
    const next = n => n <= max ? order[n % 15] : () => "";
    const txt = w => n => (w ? w : n + "\n") + next(++n)(n);
    const [n, b, f, fb] = [txt(), txt("buzzard\n"), txt("fizz\n"), txt("fizzBuzzard\n")];
    const order = [fb, n, n, b, n, f, b, n, n, b, f, n, b, n, n];
    return next(min)(min);
}
console.log(fizzBuzzard(1, 100));

Answer 2

How consistent is this code with the best practices in functional and declarative programming?

I dunno. Unless you're doing something fancy like hand-rolling monads, you might just be "programming with functions" and not really doing "functional programming." You could ask Crockford about that, if he manages not to get himself dis-invited from your next local tech conference.

Are there any bad practices in it that I should be aware of?

Looks alright to me.

---

Personally I like the other answer here. I voted for it and hope it wins the Checkmark Election, because it's very practical.

But it's not what I'd call "functional."

const fizzbuzz = (min, max) =>
    Array(max + 1).fill('', min)
        .map((v, i) => i % 5 ? v : 'fizz')
        .map((v, i) => i % 3 ? v : v + 'buzz')
        .map((v, i) => v || i)
        .join('\n').trim()

If the code in your question is "functional," I suppose this is "more functional," because we got rid of more of the flow control, chained even more functions together, and threw even more lambdas in there. I definitely wouldn't go as far as calling it "declarative," though. It still looks imperative to me; a series of commands to be executed in a particular order. So, I see no reason to value something like this over Blindman67's approach.

Some tasks are better suited to a declarative style (data transformations, things where it doesn't really matter exactly what order things happen in; think XSLT for example) and some are better suited to an imperative style (anything where you need precise flow control). Fizzbuzz could surely be done in a declarative way, with the right language or libraries. But with plain JavaScript, it seems much more straightforward to do it in an imperative way.

Answer 3

First I would like to say that code can be functional to a degree, so I will point out what I like and what could be (even) more functional.

I like isFizz and isBuzz because they are declarative and pure functions (i.e. they have no obvious side effects and are deterministic). I also like that the map does not use intermediate variables, because that would be a more imperative approach.

A suggestion would be trying to reduce the potential number of evaluations in the map (for each number, both isFizz and isBuzz are potentially executed twice) without using intermediate variables. My suggestion can be found below in the toTerms function or the Ramdba pseudo code.

After taking the course Functional-Light JavaScript v3, I have attempted to write a declarative/functional FizzBuzz implementation too.

In this course, Kyle Simpson recommends gradually converting to declarative style, which I found helpful. Also it resulted in a way over-engineered implementation, but I think it does show parts of the code that I really had to think about before finding an appropriate declarative alternative.

The implementation is in this fiddle, with my intermediate progress too. It also contains suggestions for further refactoring. This is the state at time of writing:

const range = (function rangeInner(acc) {
	return (first, last) => {
    if(first > last) {
      return acc;
    }
    return rangeInner([...acc, first])(first + 1, last);  	
  }
})([]);

const isMod3 = n => n % 3 === 0;
const isMod5 = n => n % 5 === 0;

const predicatesAndTerms = [
    [isMod3, "Fizz"],
    [isMod5, "Buzz"]
]

const toTerms = n => predicatesAndTerms
	.reduce((acc, [predicateFn, term]) => acc += predicateFn(n) ? term : "", "");

const toFizzBuzz = n => toTerms(n) || n.toString();

console.log(range(1, 15).map(toFizzBuzz));

In an attempt to avoid potentially evaluating isMod3 (isFizz in the question) and isMod5 twice for each number, I refactored to a reduce over an array of "predicate" and "term" tuples, that is evaluated by a ternary operator that returns a value directly. I also tried to avoid intermediate variables as much as possible, forcing myself to create tiny cohesive functions instead.

In an earlier version, I had a similar implementation of range as in the question, but I refactored it to try out recursion combined with a closure for the acc parameter, with the option to refactor it using R.curry later, (where R refers to Ramda).

Pseudo-code for further refactoring toFizzBuzz with Ramda could be:

const orDefault = fn => n => fn(n) || n; // looks like R.defaultTo, but executes fn over n first.
const toTermsOrDefault = orDefault(toTerms);
const toString = n => n.toString();
const toFizzBuzz = compose(toString, toTermsOrDefault);

Good luck learning FP JavaScript! If you want to discuss FP JS, I'm always interested.