101–110 of 156 posts
There's something minor that's always bothered me about the usual description of FizzBuzz: > If the number is divisible by 3, print Fizz instead of the number. If it’s divisible by 5, print Buzz. If it’s divisible by both 3 and 5, print FizzBuzz. In a strict interpretation, the first two sentences could be seen as incorrect. If a number is divisible by 3, you cannot just print 'Fizz' and move on. You also have to che…
When you write too much Haskell, your Python code starts to look like this: print('\n'.join( 'FizzBuzz' if x%5==0 and x%3==0 else 'Fizz' if x%3==0 else 'Buzz' if x%5==0 else str(x) for x in range(1, 101))) I would really like to have a "let" expression in Python to avoid having to write a new function with a def statement when you could get away with a simple lambda or generator expression.
In the generator case you can define a poor man's let like this: def let(x): yield x And use it by "iterating": ... for x in range(1, 101) for divisible_by_5 in let(x % 5 == 0) Still not as nice as having actual syntax for it.
import contextlib
@contextlib.contextmanager
def let(*values):
yield values
with let(1, 2, 3) as (a, b, c):
print(a, b, c)Earlier quoted context omitted.
Something annoying about python is that the word "lambda" is so long for what are supposed to be one-off functions. You have f=lambda x,y=1,a='Fizz',b='Buzz': ... But it's actually shorter to say def f(x,y=1,a='Fizz',b='Buzz'): ... I much prefer Haskell's \x -> x Style lambdas.
The jury is still out on whether this is a good thing or not. IMHO, the objective of the crippled `lambda` really is to make the programmer refactor into reusable functions instead of having λs littered everywhere, which would hurt maintainability.
IMHO, if a feature is useful enough to have in the language, it deserves a good implementation. If it isn't, it shouldn't be there at all. And if it is useful sometimes but doesn't fit well in other situations, providing better alternatives in those situations is a more effective way to avoid dubious code than just artificially crippling the entire feature to discourage its use.
There's something minor that's always bothered me about the usual description of FizzBuzz: > If the number is divisible by 3, print Fizz instead of the number. If it’s divisible by 5, print Buzz. If it’s divisible by both 3 and 5, print FizzBuzz. In a strict interpretation, the first two sentences could be seen as incorrect. If a number is divisible by 3, you cannot just print 'Fizz' and move on. You also have to che…
The description is declarative, there is nothing implied about "moving on".
There's something minor that's always bothered me about the usual description of FizzBuzz: > If the number is divisible by 3, print Fizz instead of the number. If it’s divisible by 5, print Buzz. If it’s divisible by both 3 and 5, print FizzBuzz. In a strict interpretation, the first two sentences could be seen as incorrect. If a number is divisible by 3, you cannot just print 'Fizz' and move on. You also have to che…
This is why the description is good. Sure, it tests whether you can write a set of statements a computer can understand. But it also tests whether you can understand the intent behind a set of statements a human would make, without going on a diatribe about how the definition is not good enough. After all, if English was a formal strict language where only one right way existed to express something, we wouldn't need…
If you just solved the fact that one meaning can have many expressions, we'd still need programmers (and, more relevantly, system analysts) just as much.
The relevant problem is that English isn't a formal strict language where a particular expression can only have one meaning (and, more importantly, that, people don't use it that way even when it superficially seems to be.)
That is, the problem that requires specialized work to develop unambiguous requirements for the implementation of (among other things) information systems isn't that English maps (many expressions) -> (one meaning), but that it maps (one expression) -> (many meanings).
it looks like the author was trying really-really-really hard to prove a point, thus turned a single function into an OOP architecture.
I know that Java is known for bloat, but that's a bit too much of an exageration
write the haskell solution in python, I already ported it to Rust:
https://gist.github.com/seanjensengrey/d053e7fa709e0699e291 If free version. t = {} t[0,0] = lambda x: x t[1,0] = lambda x: "Fizz" t[0,1] = lambda x: "Buzz" t[1,1] = lambda x: "FizzBuzz" def tests(x): return (x % 3 == 0, x % 5 == 0) for x in range(1,101): print t[tests(x)](x)
If, lambda, logical operators except == and string concatenation free version (Python 3)
for x in range( 1, 101 ):
print( [ x,'Buzz','Fizz','FizzBuzz' ][ (x%3==0)*2 + (x%5==0) ] )Since we're all sharing our fizzbuzzes, here's mine (from my blog http://seriously.dontusethiscode.com/2013/04/29/bad-intervie... ) Note that this solution is generalised for any divisors and generates an infinite sequence. from itertools import chain, combinations, count from operator import mul, add fizzbuzz = lambda terms: (lambda terms: ({x%d:w for d,w in terms}.get(0,str(x)) for x in count(1)))(tuple((lambda (d,…
When you write too much Haskell, your Python code starts to look like this: print('\n'.join( 'FizzBuzz' if x%5==0 and x%3==0 else 'Fizz' if x%3==0 else 'Buzz' if x%5==0 else str(x) for x in range(1, 101))) I would really like to have a "let" expression in Python to avoid having to write a new function with a def statement when you could get away with a simple lambda or generator expression.