Google Cached link: http://webcache.googleusercontent.com/search?q=cache:http://...
Which doesn't include the image of the solution since the server hosting the image is down.
You can click on it
A non-programmer’s solution to “Fizz Buzz”
21–30 of 58 posts
Re: A non-programmer’s solution to “Fizz Buzz”
#22I 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
It's an infinite loop, and the b variable isn't necessary, but it's interesting to see how a supposed non-programmer is able to structure a (near) solution.
Re: A non-programmer’s solution to “Fizz Buzz”
#23Boss: 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: Done. Give it a review and I'll push it live. Boss: 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…
Me: Really? Is that really a business requirement? Any other requirements you need done? I landed a graduate assistantship in 1992 as "the computer guy's assistant" at my school's physical plant. My first assignment was to generate a fixed format file with one phone number per line. The file was to range from 1-900-0000 to 1-900-999-9999 and was needed by the campus telephone system to block all premium rate calls. T…
I know people who spent at least 40 hours/month just updating dates in monthly/weekly excel reports.
Edit: and had 6 figure salaries.
Re: A non-programmer’s solution to “Fizz Buzz”
#24I 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"
In other words, this person seems to be expressing a tail-recursive solution? Interesting. I would agree that tail-recursion is probably more intuitive than stateful iteration to a mathematician as well.
Re: A non-programmer’s solution to “Fizz Buzz”
#25I 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"
[deleted]
Re: A non-programmer’s solution to “Fizz Buzz”
#26Boss: 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: Done. Give it a review and I'll push it live. Boss: 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…
This sounds like a daily interaction with my current employer.
Sigh.
Re: A non-programmer’s solution to “Fizz Buzz”
#27Earlier quoted context omitted.
And this is the problem I have with CSS selectors. What you just described is ridiculously fragile and will send shudders down the spine of any developer experienced with wrangling projects that have tangles of inappropriate coupling, but in many cases, there simply isn't a more elegant solution. Your options are: 1. Implement a sane (albeit less powerful) view hierarchy system, foregoing basically all of the CSS sel…
This stuff is getting solved, for the particular example you can use n-th child in modern browsers[0]. [0] http://www.quirksmode.org/css/nthchild.html
Well, that sort of solves some of the problem, but in other ways it makes it worse. The fundamental problem is that mentally applying CSS rules is difficult, particularly when the DOM structure being styled is complex and is determined by an imperative program.
Imperatively generating and dealing with a DOM structure using simple selector queries is relatively easy to do, as is modeling what is happening in your head. Dealing with more complex CSS rules as they apply to a static (or dynamic but very simple) DOM structure is a little trickier, but not completely unwieldy. When you run into problems is when you try to do both simultaneously. Suddenly you have to not only mentally model a mutable DOM structure, but you have to model how those CSS rules will be applied in a generalized and abstract form. It's not hard to paint yourself into a corner where you'd actually start having to prove theorems about your code in order to be reasonably assured that the CSS will apply correctly.
Of course, hardly anybody actually lets it get that far. Instead, they start applying styles imperatively using JavaScript. And that sucks.
I don't know what the solution to this is, or if there even can be one that is a progression from where we currently are. But I don't think fancier CSS selectors are the answer.
Re: A non-programmer’s solution to “Fizz Buzz”
#28I 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"
Agree with the mathematician point. It looks a lot like something (I think) I would come up with if I didn't know any programming.
Re: A non-programmer’s solution to “Fizz Buzz”
#29What'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;
}
}
Re: A non-programmer’s solution to “Fizz Buzz”
#30I 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"
Is this really an "induction-style" algorithm? (I haven't actually heard that term before.) I usually associate induction with taking some large input and shrinking it at each step until you hit some base case. This is really the opposite of induction--it starts with a base case (1) and grows the output, which makes this sound a bit more like co-induction.
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).