« Language of the year: 2010 | Main | Testing Client Side Javascript with Jasmine and Node.js »

June 29, 2010


Feed You can follow this conversation by subscribing to the comment feed for this post.

Colin Jones

"Try Clojure!" says the peanut gallery ;) But seriously, if you have a few hours, Rich Hickey has some lectures on at http://clojure.blip.tv that present a much better argument for Clojure than I could. Baked-in immutability for the win! That said, there's certainly a lot of working concurrent code in Java - I just wouldn't want to be responsible for maintaining much of it (see Java Concurrency in Practice for my fears...)


another one from the peanut gallery here. you're right, ocaml and haskell and others ARE full of academic shitbaggery. clojure isn't.


"Maybe it's me."


Paint Can

Your 'seriously' and 'what the hell' links are at worst information dense definitions of core language mechanisms. The ocaml one isn't even difficult to read. Maybe you just need to be a bit more patient and take time to read thoroughly.

Here's a book I like:


I've found that reading this has helped me learn & appreciate the functional approach to programming more. If you're like me and you have enjoyed reading Sedgewick or other algorithms text, it might be good for you as well.


I would have loved this if the blog post contained more technical details and some code snippets about the tradeoffs involved. Functional languages cover a broad spectrum. There are often multiple concepts being explored in a language, then there is the issue of cultural heritage of the respective communities, and the fact that FP languages have traditionally had multiple implementations with different tradeoffs. as an example -> lisp and scheme are functional without being immutable. scheme favors a small spec while lisp includes large number of inbuilt primitives. Clojure introduces persistent datastructures and interesting new concepts like agents and integration with the jvm. I know too little about haskell and ML to make any informed comments about them but they appear espouse static typing unlike lisp / scheme. So if you have a particular beef about a functional language, look further and you will find one that doesnt share those traits.

Andy Kish

The strong type system is the best part of Haskell! The type system is really a happy medium where it's expressive enough (if your program compiles that actually means something) and is not burdensome for the programmer (like certain dependently typed languages). The types are also expressive enough that you can often figure out what's going on just from a function's type alone.

Functional languages may not be your cup of tea, but just because you don't understand them does not mean that they are overrated.


The problem aren't the languages, the problem is people that give up as soon as the language does look like java.

Loup Vaillant

First, learn what is a tagged union (more often called algebraic data type). learn where it can be useful (Option types compared to Null pointers, for instance). Okasaki's book makes a heavy use of tagged unions. You should try and read the first chapters. There is also his thesis, which is very like the book, available on line: http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf

Second, don't be scared. Functional languages tend to be freakishly terse, but the programs written in them are correspondingly short. It may take time to read a line, but reading the whole program is easier.

Third, don't be offended. There are perfectly rational reasons for changing the syntax of those languages, or having a complex type system. For instance function application is written as "f x" instead of "f(x)" because it enables currying, and is most lightweight (function application is the most heavily used language construct, after all). Most of the time, the complexities you see are actually simple things, but unfamiliar.

Finally, think differently. When using a functional language, you don't want to instruct your computer what to *do*. Rather, you want to tell it about what, *is*. Stop to see your code as a string of instructions. Start to see it as a tree of descriptions.


Learning a functional language like Haskell for the first time 'might' give you the worst headache in your entire life. Many people who know Haskell admit that it was after a few months (or even years) of jumping back and forth that they actually "got the language." If you quit Haskell after trying to learn it the first time, it's ok. I did too. However, now I'm finding its complex features powerful, expressive and extremely logical.

Haskell can give grief to people programming in imperative languages for years. So, it's no surprise that newcomers to programming who have just understood imperative languages will need strong painkillers. That's why, don't blindly believe every "I don't under Haskell (or any other functional language)" post or comment. Just put in more time, it'll pay off.


Honestly, yet another comment about how functional programming languages are hype from somebody who never managed to learn one.

Of the two links you provided to support your "academic shitheaddery" claim (whatever that means), one is to the formal language definition for Haskell and the other is a bog standard explanation of common language features.

If you don't want to read the formal semantics of a language, then don't read it. Having this sort of precise definition is required for inventing new useful features. It's not supposed to be a tutorial.

The comments to this entry are closed.