Boss: I need you to write me a program to print the numbers from 1 to 100

Me: Really? Is that really a business requirement? Any other requirements you need done?

Boss: Yes, it's your number 1 priority. No, just 1 to 100

Me: <a few minutes later> Done. Give it a review and I'll push it live.

Boss: <a few minutes later> No! I said 1 to 100 and everything divisible by 3 should be replaced by "FIZZ". Why didn't you do that?

Me: I'm pretty sure you didn't ask for that, but I'll do it right now. Any other requirements than FIZZ?

Boss: Thanks for taking care of this. There aren't any other requirements.

Me: <a few minutes later> Done. Give it a review and I'll push it live.

Boss: <a few minutes later> Seriously! Why didn't you put the BUZZ in there?

Me: What BUZZ are you talking about? You only asked for FIZZ.

Me: Wait a second, are you having me program FIZZBUZZ for you? What the heck!

Boss: Yes! Somebody on the internet asked how a non-programmer like myself would solve FIZZBUZZ!

Me: Sigh...

    Me: Really? Is that really a business requirement? Any other requirements you need done?

What's very interesting here is the SICP-style recursive looping, combined with the fact that the non-programmer doesn't expect to be able to pass variables but rather expects to make stateful queries. That is, the infrastructure expected (here written in JS) is:

    var query = {};
    function print(x) {
        console.log(x);
        if (typeof x === "number") {
            query = {last_num: x, time_since: 1};
        } else {
            query.time_since += 1;
        }
    }

And given all that, they have invented a fizzbuzz() which, as its last statement in each branch, calls fizzbuzz(). I like the way that it's graphically represented but I also think those semantics are quite interesting.

This is a perfect illustration of why programming is easy if you have aptitude for it, at least on a small scale, but almost impossible if you're not. Clive is already a programmer; he just doesn't know any programming languages yet, and anyone can learn those.

Site is down, here's a PDF of the solution: https://nm-files.s3.amazonaws.com/clive-fizz-buzz.pdf

Hi All.

I'm Clive, Wintron's non-programmer colleague and the guy who tried FizzBuzz on the piece of paper.

I feel fascinated by the fact people are examining the approach I took, and a little flattered by the nice remarks people have made about the fact I should maybe move on to learn a programming language. Maybe I will.

If I'm honest, I don't understand all the observations people have made, but there's one I do understand, and wanted to shed some light on: the point about iteration.

The exercise reminded me of some kind of in-the-round drinking game, where everyone is determining the responses one by one, as an iteration of the last number. Consequently, this shaped the way I approached the problem.

In retrospect, I completely see that I would have been better off simply counting from 1 to 100, then translating each of the 100 numbers into how it should be displayed (Fizz, Buzz, FizzBuzz or as a number). But recreating the drinking game in my head, it made perfect sense to me that each number is determined by being an iteration of the last one. That feels to me like I count in real life.

Thanks again for taking an interest, and yes, maybe I will ask Wintron/Steve to teach me some programming!

Clive

I've been thinking a lot lately about what sorts of systems "the rest of us" (where by "us" I mean "them") are able to program effectively.

One thing I've noticed is that people that don't really know programming in a hacker sense seem to have no problem creating a spreadsheet that calculates even fairly complex things (not that FizzBuzz is complicated, but see here: https://docs.google.com/spreadsheet/ccc?key=0AnUa0E6R--UedGd...).

I think one of the biggest factors is that users don't have to keep track of the order of operations. If you change the value in cell A1, and cell B6 depends on it, and D5 depends on it, and so on until you get to Z22, there's no step-by-step thinking about what order the calculations will be done in. Basically a change in the input is instantaneously (and automatically, transparently) reflected in the output.

Another big factor is that all state is made explicit by default.

In some ways it seems similar to functional reactive programming. The code for e.g. FizzBuzz looks crazy complicated (http://www.lejordet.com/2012/01/fizzbuzz-with-reactive-exten...), but if you hooked it together in a GUI (sort of how Quartz Composer works on the Mac) it would probably be pretty easy to wrap your head around, and probably possible for someone with no formal programming knowledge to figure out, if not recreate.

Google Cached link:

http://webcache.googleusercontent.com/search?q=cache:http://...

I like how instead of giving a procedure to produce the whole answer he created an induction-style algorithm that, given part of an answer, produces the next output.

Looks like "The mathematician's solution to Fizz Buzz"

I don't wish to complain but does that look like an infinite loop to you?

Programs are just algorithms, a flow diagram is just a different programming language

This inspired me to do FizzBuzz in CSS: http://codepen.io/SachaG/pen/jCpba

It's always interesting to have a peek at how how non-programmers think. What I dislike about these sorts of posts though, is the comments, where everyone feels like it'd be useful for them to submit yet another trivial Javascript, C or Python FizzBuzz implementation. Congratulations! You can do a basic programming task in a popular language!

The site is not up right now.

http://www.downforeveryoneorjustme.com/http://www.nixonmcinn...

Good for Clive for being a sport and coming up with a valid answer, of course, but this is what interested me about his response:

He tackled the problem on a "meta" level, but didn't grasp the math. He could have saved a lot of time by seeing if the number was divisible by 15.

No if statements and a single, convoluted line: http://jsfiddle.net/P8Dr2/2/

That sounds like a mathematicians mind.

Peano Axioms and all that.

I wouldn't be so quick in concluding that the long back arrow stands for recursive looping. I'd guess it's just a non-coder notation for "and then do that thing again", for which the closest equivalent in actual language would be the `while` loop (most likely infinite, as the author remarked). I don't see the meta-level of considering the algorithm/procedure as a whole here, a one that is needed for thinking in terms of recursive application.

Furthermore, the fact that non-programmer expects to be able to poll the state of everything around (like the numbers which were already printed) would indicate that in their mind, there is no separation between the program/algorithm and the environment it is executed in. (Ironically, this is completely accurate viewpoint if we're thinking at the level of actual machines, be it real ones or abstract models like Turing machines.)

Inspired by this, I translated the whole solution into JS. I renamed your "query" object to "output_state," which seems like a more accurate name.

    var output_state = {};
    function print(x) {
        console.log(x);
        if (typeof x === "number") {
            output_state = {last_num: x, time_since: 1};
        } else {
            output_state.time_since += 1;
        }
    }

    function fizzbuzz() {
        switch(output_state.last_num) {
            case undefined:
                print(1);
                break;
            default:
                var a = output_state.last_num;
                var b = output_state.time_since;
                var number = a + b;

                if (number % 5 !== 0) {
                    if (number % 3 === 0) {
                        print("Fizz");
                    } else {
                        print(number);
                    }
                } else {
                    if (number % 3 === 0) {
                        print("FizzBuzz");
                    } else {
                        print("Buzz");
                    }
                }
        }

        fizzbuzz();
        // Or, correctly: if (number < 100) { fizzbuzz(); }
    }

I too was struck by the fact that it's essentially an FSM. It's cool that a non-programmer will naturally gravitate towards that structure, while we're forced to spend weeks learning it in upper-level courses...