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.
Really well presented series of lectures:
http://www.seas.upenn.edu/~cis194/lectures.html
Cheat sheet:
http://blog.codeslower.com/static/CheatSheet.pdf
Books:
http://learnyouahaskell.com/chapters
http://book.realworldhaskell.org/read/
"What I Wish I Knew When Learning Haskell":
http://dev.stephendiehl.com/hask/
Haskell Tutorial for C Programmers (useful for anyone coming from an imperative world):
http://www.haskell.org/haskellwiki/Haskell_Tutorial_for_C_Pr...
Hoogle (API search engine):
http://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Func...
Fascinating to hear how the same ideas are expressed both ways.
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.
After that make sure you are using Hoogle to search for functions that already exist!!! http://www.haskell.org/hoogle/
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).
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.
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.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.
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.