Haskell syntax just seems pretty crazy. I know nothing about it, but I just read it and wish that maybe one could use a few more lines and get better understandability at the expense of terseness.
It's the difference between Eclipse and Emacs. Haskell actually encourages "internalization" of abstractions through terser syntax.
Emacs is like that, you internalize the editor which makes you 5x more productive than you are with an editor that externalizes the abstraction requiring your brain to use another layer of translation (the visual one).
If you learn Haskell, you'll find it quite enjoyable (I do now). The way I think in that language is so much more abstract and precise than it ever was in Python / Scheme / Erlang / Ruby / Javascript.
[EDIT] To whomever is downvoting these legitimate comments, speak up why you think they are inappropriate for this discussion instead of downvoting.
Someone told me this: with Haskell you end up reading a lot more up-front than you do "playing around" up-front. The reason for this is the type system which can feel like a straight jacket at first unless you understand it well.
Don't read the monad tutorials. At all. Get a feel for the language with http://learnyouahaskell.com/chapters (you don't need to read the whole thing through, but probably should).
Once you've played with the basics then you should absolutely read the http://www.haskell.org/haskellwiki/Typeclassopedia which gives you a very thoroughly walking through of the Type System and is essential but heavy reading to be at all productive with Haskell.
One strategy no one really told me about: search for functions based on their type and less their "name".
Then after that, Gabriel Gonzalez writes some really great noob-intermediate friendly tutorials on Haskell in-general: http://www.haskellforall.com/ (don't start with his stuff though as you should have familiarity with Haskell basics first!!).
Once you're proficient, having Hoogle built into your command-line, using CTAGS + codex, Lambdabot + Emacs, and GHC-mod + emacs is pretty crucial to my workflow.
Hoogle in the commandline is really powerful, CTAGS + codex is basically CTAGS for haskell source files (if you don't know what ctags are look it up), and lambdabot is a powerful tool that is tough to explain but it's the omnipotent haskell bot sitting in the #haskell IRC channel (but you can install it on your machine and query it from Emacs).
> The reason for this is the type system which can feel like a straight jacket at first unless you understand it well.
This is a biggy. It'll feel like the type-system has a personal vendetta against you when you first start. Especially if you come from a language that allows you to coerce types. Basically stop thinking you can get around the type system and instead follow them. See them as connectors of computations rather than carriers of values.
Some of that is just unfamiliarity, doubtless. Optimizing code to be read by people unfamiliar with the language is probably not a good habit. I recall once wading into a C++ code base and coming across the line:
using namespace std; // using namespace standard
On the flip side, people certainly do go overboard with cramming things into a single line (an affliction not at all unique to Haskell) and in particular overuse of "point free" style where it's inappropriate can lead to particularly unreadable code for those not well versed in the particular tricks used to make the code point free (and that's an affliction more unique to Haskell). I don't see either problem in the code in the article, though.
Indeed. But I am not sure if "crazy" is the right word. Perhaps a better one would be "dense". It is not unlike reading a mathematical proof - one paragraph might need an one semester course to be explained.
This is perfectly nice:
firstBatch = take 10 myDoubles
This is not that nice:
sieve (p:ps) xs = h ++ sieve ps [x | x <- t, rem x p /=0]
where (h,~(_:t)) = span(< p*p) xs
But that's because there's just too many things going on. A comparable Java code would likely span a page.
I guess, for a trained eye, it is way easier to understand what's going on given those two lines, then a full page program, which would likely hide bugs in side effects.
I think such sieve examples do not do languages a favour: It is slow and it's not true, that the Java code is that long. However I agree that it's nicer in Haskell, but the naive variant as given here (and often in fibonacci examples) is very slow compared to the naive version in a standard imperative language. My take: http://pastebin.com/JGnSPEaH. That is 19 vs 37 lines.
Every language that differs from the structure you're familiar with will seem crazy until you learn how to read it. Be that Haskell, Erlang or Japanese it's no different.
One of the best intro programming books around, just happens to be about Haskell. Miran has a knack for explaining complex technical concepts.
Haskell's structure is actually incredibly readable - significant whitespace enforces uniformity across all codebases, and syntactically separating function type signatures from function declarations is far more readable than, say, Scala where it's all crammed together in one line.
You do have to learn all the operators though, but again, Miran's book is really good for that.
