Summary: 2011 OO FizzBuzz joke...
Why can't programmers design software?
11–20 of 25 posts
Re: Why can't programmers design software?
#12Is it just me? I don't like this design.
What's the point of wrapping an algorithm in strategy, when there is no reuse, nor any need to exchange algorithm?
And more. Why FizzBuzz(15), Buzz(5), Fizz(3); in enum and not in the constructor?
Why "mod" attribute, when the rest of the code doesn't use shortened words? It should be modulo.
Why FizzBuzzOperator when FizzBuzzStrategy's initialization is that easy? Also, again there's no requirement for reusability.
The code here is a classic example of why people make jokes about (usually in J2EE) overengineering solutions where even FizzBuzz will be designed for 1000MD-average-task-size scale.
I have switched to Clojure for good. Our FizzBuzzes are oneliners http://www.learningclojure.com/2014/05/fizz-buzz-interview-q...
Re: Why can't programmers design software?
#13Very simple: Because in the precious few hours they have to devote to "pure learning", when between jobs -- they're only motivated to hunker down and bone up the only thing that really matters: the latest tips 'n' tricks for passing all those fun programming quizzes (and the occasional "culture fit" question or two) that are the mainstay of the modern interview process. Designing real, usable, maintainable ... softwa…
Is it though? I give an interview question where I present a spec to be implemented. There's no algorithmic trick, but you do have to know to watch out for common problems (end of array conditions, etc). Sadly though we hired someone against my vociferous objection that failed my question in the worst way - he ditched the spec, attempted a complicated solution, and proudly asserted that "it works" at the end of the i…
Do you ask the same question each time?
Re: Why can't programmers design software?
#14Because the language discourages it? Language, or pretentious Pidgin in this case, limits thinking.
If you're doing your design in the language, you're doing it wrong. (Yes, you have to design something that you can implement in the language. But no, you should not be thinking in the language while you are doing design.)
Re: Why can't programmers design software?
#15Re: Why can't programmers design software?
#16Is it just me? I don't like this design. What's the point of wrapping an algorithm in strategy, when there is no reuse, nor any need to exchange algorithm? And more. Why FizzBuzz(15), Buzz(5), Fizz(3); in enum and not in the constructor? Why "mod" attribute, when the rest of the code doesn't use shortened words? It should be modulo. Why FizzBuzzOperator when FizzBuzzStrategy's initialization is that easy? Also, again…
The Clojure FizzBuzzes may be one-liners, but they are multiple statements, which I'd find easier to read on multiple lines.
Re: Why can't programmers design software?
#17Earlier quoted context omitted.
Is it though? I give an interview question where I present a spec to be implemented. There's no algorithmic trick, but you do have to know to watch out for common problems (end of array conditions, etc). Sadly though we hired someone against my vociferous objection that failed my question in the worst way - he ditched the spec, attempted a complicated solution, and proudly asserted that "it works" at the end of the i…
Do you ask the same question each time?
low n. I'm just starting out.
Re: Why can't programmers design software?
#18I can't tell whether this is real or a parody.
It is parody.
Re: Why can't programmers design software?
#19Is this article some sort of joke? Poe's Law seems to be in force here.
Cannot be anything but a joke. The problem is simple, the solution requires 10 lines. There is no reason, absolutly none, to create an interface for a such simple problem.
Re: Why can't programmers design software?
#20Is this article some sort of joke? Poe's Law seems to be in force here.
Cannot be anything but a joke. The problem is simple, the solution requires 10 lines. There is no reason, absolutly none, to create an interface for a such simple problem.
Until this is done in Reactive programming style, this is far from complete.