I generally don't particularly like giving punctuation meaning that, well, isn't punctuating. The bottleneck when writing code is almost never keypresses.
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.
So what about the '*' in C or even better the '.' in so many object oriented language.
> 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.
When you're writing Haskell in emacs (like you should be), you enable haskell-font-lock-symbols in haskell-mode, and it displays the lambda as it should be (plus a bunch of other symbol corrections for ::, ->, =>, (), ||, &&, etc.)
I cannot agree enough. Someone give me a call when a Haskell-like language with readable syntax appears. I really like the ideas behind Haskell, but the syntax is so unfriendly that I cannot be bothered to really start using it. Less special characters, please.
There really aren't that many special characters (certainly no requirement for non-ascii) in the core language - perhaps the sin is allowing almost unlimited user defined operators in code, which leads to monstrosities like ekmett's lens infix operators: http://hackage.haskell.org/package/lens-4.1.2/docs/Control-L...
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).
I really like scheme & clojure and I think I have done a lot more scheme and clojure than haskell. (And even a alot more of Python). However, I think that Haskell by itself has a great syntax (with some legacy cruft, granted).
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 have very limited familiarity with Haskell, but I find the syntax pretty clean and readable - I spend most of my time getting my head around functional/lazy/etc semantics, which make my head hurt (in a good way) - that presumably implies that the syntax is successfully exposing those semantics to my poor OO/duck-typing coddled brain.
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?"
You don't need a return, just a print (since we are doing FizzBuzz).
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).
I use this function to force evaluation of elements in a generator:
def do(gen):
for x in gen:
pass
It evaluates all elements of a generator with storing them in memory. If you don't mind generating some garbage, you can just use the list function instead.
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.
One of the most effective ways to hurt maintainability of code written in any given programming language is to try to make some language features artificially awkward to use in the hope that programmers will then do something else. When has that ever worked?
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.
So what's if it's shorter. You'll run out of screen? You'll wear down your keyboard?
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.
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.
The parent wasn't saying code should be short, they were saying the syntax for lambdas should be short.
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.
You have
But it's actually shorter to say I much prefer Haskell's Style lambdas.