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?
I'm sure somewhere, someone has been paid to write a program that prints 1 to 100.
Edit: and had 6 figure salaries.
1. Implement a sane (albeit less powerful) view hierarchy system, foregoing basically all of the CSS selector stuff, and applying styles individually. The framework will be big and unwieldy, and you'll take a performance hit, but you'll be able to maintain the client code.
2. Bite the bullet and implement it the ad hoc way, comment the crap out of it, and hope that whoever comes and changes something later will remember to read those comments.
Sigh.
var query = {};
function print(x) {
console.log(x);
if (typeof x === "number") {
query = {last_num: x, time_since: 1};
} else {
query.time_since += 1;
}
}
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.)
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'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
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.
http://webcache.googleusercontent.com/search?q=cache:http://...
Looks like "The mathematician's solution to Fizz Buzz"
Another way to think about it would be that he defined a little finite-state automaton to compute the answer. You just run the automaton for as many steps as you want, noting down what it outputs each time. I think this is actually very much like what a programmer would write if tasked with solving FizzBuzz in an online streaming fashion (rather than for some bounded n).
Maybe it's just my bias towards functional programming showing, but I actually think this approach is fairly intuitive. In fact, I would have probably come up with something structurally similar (differing only in details).
Is it a common FP technique to do local-state-less looping like that? I would expect a tail-recursion solution to pass the next or previous value rather than re-deriving it from reading the output.
Programs are just algorithms, a flow diagram is just a different programming language
There's probably a lot more to say about programs that doesn't fit within the "just algorithm" view.
http://www.downforeveryoneorjustme.com/http://www.nixonmcinn...
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.
Peano Axioms and all that.