Playing code golf with Python, this is the shortest I could get:
https://gist.github.com/tghw/3702360
Definitely a little unpythonic.
https://gist.github.com/tghw/3702360
Definitely a little unpythonic.
You have
f=lambda x,y=1,a='Fizz',b='Buzz': ...
def f(x,y=1,a='Fizz',b='Buzz'): ...
\x -> x
I think CoffeeScript gets it probably the most right of languages I've worked with, in that the choice of punctuation makes intuitive sense... "Hey! It's an Arrow. It goes from here to here".
FWIW, I don't like the word "lambda" either... Naming things with one letter are generally a bad idea that we'd do better to divest ourselves of, but there is a bit of legacy to deal with. Either way, they make a field (and statistics is a major offender here, with p-values and t-tests and whatnot), terribly inaccessible.
> The bottleneck when writing code is almost never keypresses.
No, it's readability and that often comes with terseness. Every line break because I have to spell out lambda or every refactoring that removes the function from its original context so I can avoid a line break is bad for readability. In that aspect the '\' in Haskell does great. Also in Haskell anonymous functions are so important that they definitely deserve their own special character to shorten many expressions.
I only see this becoming a problem if it is used in excess, like in C++ and especially in C++11.
I don't like it... I don't what I'd do if starting from scratch, and there might not be better, but it definitely causes readability pain.
> the '.' in so many object oriented language
I have less of a problem with this, because there's some non-programming analog to be found (Section 1.1, Article 3.2, etc.). That said, I think, at some point, it's harmful to OOP in that it makes it hard to sort out properties and messages, and the roles of one or the other.
I agree 100% on readability - the problem for me comes when words get mapped onto abbreviations and symbols that are almost entirely constructed and/or alien to most readers.
Full list here: https://github.com/haskell/haskell-mode/blob/master/haskell-...
I normally forgive languages being hard to learn if the bring enough utility.
As a lisper, I prefer names and prefix operators - there's a few exceptions where infix operators add improvements to the language, but I dislike having user-defined operators (they make searching a pain, although Hayoo eases some of that).
What is really great is how Haskell enables you to write extremely succinct code by providing powerful abstractions and tools. The fact that you have a type annotation already gives enough meta information in the code that you often can omit a long name. The fact that Haskell functions tend to be short in lines gives you something that is closer to an equation than a command language.
I don't know how to put this in words, but I'll try: Naming things well in programming is the most difficult task after mastering the very basics. I think this is because names are not fundamental for algorithms and programs but are like bookmarks for the programmer and their human brain. In C, a function with one-letter argument names is a nightmare, in Haskell, it actually improves readablity over a verbose version with whole-word names. And then, I have seen a lot of functions that were named very specific in terms of a problem the programmer tried to solve at the time, that however where quite generic, or could have been very generic (think of `sort_customers_by_name()` instead of a `sort_by()`.
I share your dislike of extreme operator usage. It is a problem that whatever permutation of +-!@#! are used as operators in libraries for functionality that the user rarely needs. But the general approach of haskell for succinctness is a good one.
I suppose these things are a matter of taste as much as anything else. But when people talk about a Haskell program being 'elegant', I never think to myself "what, that mess?"
It's not: with def() you have to explicitly write return, while with lambda it is implicit.
For tghw's solution to work you'd have to have a print outside of the function call (since you can't print from a lambda). With the def, you can print inside of the function (and don't need a return, since you're just printing).
map(print, some_list)
print(*[1,2,3], sep='\n') def do(gen):
for x in gen:
pass
https://twitter.com/jooon/status/25054586175
But that isn't a whole lot shorter than the solution pcmonk posted in the thread.
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.
If you don't like typing it, have a macro. Otherwise, as Objective C shows, the verbosity of code is not relevant at all. It's what it says and what it does, which is.
And access modifiers are + and - rather than static and nonstatic.
Objective-C definitely isn't above using lightweight syntax. Where it favours verbosity is APIs.
But I hoped you'd see beyond the direct comparison of lambdas with Objective C's blocks.
I'm saying that short code doesn't automatically translate to more readable or better code, Objective C's message syntax is the proof (if I have to be painfully specific about it).
I write a lot of JS and typing out "function" or "return" was never on the list of things I found a problem, despite I also work in C#, which uses the short => variation.
Yes, short code doesn't automatically translate to readible code. But neither does long code.
You can't wheel out objective-c's fondness for long self-documenting message names as self-evident proof that the syntax for lambdas must be verbose.
Long message names are good because they let you clearly describe what is otherwise a big black box of unknown behaviour.
The syntax for a lambda will always be a lambda, so it doesn't need to be spelt out explicitly each time. Shorter syntaxes such as used by Haskell are easier to visually pattern match on and so can actually aid comprehension.
It's not as simple as longer is always better and anyone who disagrees is obviously foolish and lazy.
for x in range(100):
print x%3/2*'Fizz'+x%5/4*'Buzz' or x+1for ($i = 1; $i <= 100; $i++) {
$str = str_repeat('Fizz', !($i%3)&1) . str_repeat('Buzz', !($i%5)&1);
echo $str ? "$str\n" : "$i\n";
}' '.join(["FizzBuzz" if n%15==0 else "Fizz" if n%3==0 else "Buzz" if n%5==0 else str(n) for n in range(1,101)])
['Fizz' * (not bool(i % 3)) + 'Buzz' * (not bool(i % 5)) for i in xrange(1,101) if i % 3 == 0 or i % 5==0]
EDIT: I hate lambdas. Also I'm not saying the above is pretty or a good idea, but I had some fun.
from itertools import cycle , izip
[(f + b or x) for f, b, x in izip(cycle([''] * 2 + ['Fizz']), cycle([''] * 4 + ['Buzz']), range(1, 100))]
Edit: not sure how to post code in comments. e.g. * is lost
> Edit: not sure how to post code in comments. e.g. * is lost
Put a couple of blanks before each line. This displays it in a monospace font, too.