For example, a common pattern that I find myself repeating in many languages is downloading a bunch of webpages asynchronously and collecting the results in a consistent order. To do this in Go I might wire up a channel and collect the results that way. In C# I might use the BeginAsync functions and possibly locks to collect all my results. And what if one of them times out? Throws an exception?

In almost every language I have had to specifically think about all these situations, making sure I have handled all of the exceptions and timeouts properly and by the end of the day I usually end up with a mudball procedure that is really good at asynchronously downloading webpages, but it is far from reusable.

In Haskell, once I'm done writing my function "downloadWebPage", I just lift it into the context of the problem I'm trying to solve. If I'm trying to download a page asynchronously, I'll use "asyncDl = forkAsync downloadWebPage" to make it a function that downloads a page asynchronously. If I need to handle timeouts, I'll use "timeout 200000 . asyncDl" to make a function that returns Nothing after a certain amount of time. What if I wanted to do this for a list of web pages? Well I just use mapM run the asynchronous, timed out webpage download function over a list of websites.

What if I want to use any function instead of one that download websites? Well you make a library: https://github.com/jb55/async-util

What I find in Haskell/Lisp that I have not seen in many other languages is the idea of a combinatoric API. One where combining functions is your main tool for building abstractions rather than more rigid computation paths. The amount of code that you do not have to write when programming this way is something that you just don't see in other languages.

    sequence [putStrLn "foo", putStrLn "bar", putStrLn "baz"]

    sequence [Just 3, Just 8, Just 5] -- results in Just [3, 8, 5]
    sequence [Just 3, Nothing, Just 5] -- results in Nothing, because Nothing is
                                       -- propagated if it occurs

    sequence [[1, 2], [3, 4], [5, 6]] -- results in every possible list whose first
                                      -- element is drawn from the first list, whose
                                      -- second element is drawn from the second
                                      -- list, and whose third element is drawn from
                                      -- the third list.

    parseDigit = oneOf ['0'..'9']
    parseInt = many parseDigit
    parsePairOfInts = do
        string "("
        p1 <- parseInt
        string ","
        p2 <- parseInt
        string ")"
        return (p1, p2)

The original question was about the mechanisms, not the style or libraries.

I don't really know haskell, so correct me if I'm wrong.

They allow return-type polymorphism, which ordinary OO interfaces do not. And the Monad type-class requires this feature.

Basically, when you call the "return" function in Haskell, (e.g: return 5) -- the code being called depends on the type of the result. The type of the result is determined from the context (by type-inference or rarely, type annotations). In Ruby or Python, there's no easy/direct way to encode something like "return" such that it works with any Monad instance.

One thing is impossible, though: defining two methods that differ only in return type, something like

Most important point:

Something like

    int i = parse(String source);
    long l = parse(String source);
    boolean b = parse(String source);

  class Read r where
    read :: String -> Maybe r

Now you can write various functions that use "read" and they all remain return-type polymorphic. For example, you can write one that loops, requesting the user to repeat entry until parse-able data (of the wanted type) is given:

  repeatReadingUntilValid :: Read r => IO r
  repeatReadingUntilValid = do
    line <- getLine
    case read line of
      Nothing -> do
        putStrLn $ "Invalid input: " ++ show line
        repeatReadingUntilValid
      Just result ->
        return result

Another example is QuickCheck, which uses type-classes to auto-generate fuzz-testers for functions.

For example:

  import Test.QuickCheck

  pretty :: MyType -> String
  pretty = .. pretty print my type here ..

  unpretty :: String -> MyType
  unpretty = .. parse the pretty printing of my type here ..

  quickCheck (\x -> unpretty (pretty x) == x)

I can generalize this property to:

  isInverse f g x = f (g x) == x

  quickCheck (isInverse unpretty pretty)

  commutative f x y   = x `f` y == y `f` x
  associative f x y z = (x `f` y) `f` z ==
                        x `f` (y `f` z)
  transitive f x y z = x `f` y && y `f` z ==> x `f` z

The type system is saving us from writing code here.

As for continuation passing, Python can do explicit continuation passing, but it has caveats:

* No TCO means it doesn't work well in larger cases

* Explicit CPS is ugly. yield-based continuation passing is restricted. You can't implement non-determinism via generators.

So using yield, you can implement most monad instances in Python (excluding non-determinism).

But Haskell can goes beyond a particular/useful monad instance (e.g: Parsing) and has a Monad generalization (basically a type-class that allows lots of libraries to be written such that they work with any monad, not just this parsing monad).

Additionally, monad transformers are a technique to compose monad types together to form a new monad that can do the things each of the monads can.

For example, I can compose the non-determinism monad with the parsing monad to get a non-determinism parser that yields various possible parse results.

But the end result is that in my experience, Haskell code is not much shorter than Python code (I don't have much Ruby experience, but I suspect it's probably on par with Python).

IMO, the main advantage of Haskell over Ruby/Python, is that you don't pay the enormous prices for the high expressiveness that you do for roughly the same expressiveness in Ruby/Python. I find it much easier to maintain Haskell code, it has virtually no runtime failures, it has good performance, and so forth.

I cannot possibly list all of the useful things that are nice about Haskell, the rabbit hole is very deep. But I'll enumerate just a few.

Type-classes:

As a simple illustrative example, let's look at the Show class:

  class Show s where
    show :: s -> String

Example instance:

  data Bool = False | True

  instance Show Bool where
    show True = "True"
    show False = "False"

Note, Haskell has a "deriving" mechanism that allows replacing the above boilerplate with:

  data Bool = False | True
    deriving (Show)

Here's something Python/Ruby cannot directly do:

  class Read r where
    read :: String -> Maybe r

Now, you can compose "read" with other functions to build interesting values, that are still polymorphic on the result type. For example:

  readLine :: Read r => IO (Maybe r)

With Python/Ruby you may be able to encode this via classmethods, but then all the relevant classes have to be modified to inherit from this. You can try returning factories, but then these must return any particular type they're requested. There's no easy/direct way to encode this as in Haskell.

This is basically a safe __unrepr__, which is not implementable in this way in Python not just because of the lack of return-type polymorphism, but also because of mutability/identity concerns. Immutability-by-default is another nice benefit, gets rid of a whole slew of object-identity/aliasing issues.

On top of the extremely versatile type-class mechanism, many useful abstractions are built, which do not exist in Python. Monads are just one of these useful abstractions.

For example, using lists and their instance of the Monad typeclass, I can write the "powerset" function as:

  powerset xs = filterM (\x -> [True,False]) xs

Concurrency:

One of Haskell's models of concurrency is very similar to Erlang, and uses immutable-shared-state threads with explicit-mutable-state. This is great for both performance and simple semantics (the rarity of mutable state makes reasoning about data easy. The preemption makes reasoning about starvation easy). Haskell's threads are also user-level cheap threads, and you can literally create millions of them.

Say we want to do latency-hiding on some expensive procedure. I'll present the Haskell code to do so by creating a thread-pool that preemptively executes the given operation and passes the result to callers that need it:

  preemptively :: Int -> IO a -> IO (IO a)
  preemptively poolSize act = do
    requestMVar <- newEmptyMVar
    replicateM_ poolSize . forkIO . forever $ do
      res <- try act
      responseMVar <- takeMVar requestMVar
      putMVar responseMVar res
    return $ do
      responseMVar <- newEmptyMVar
      putMVar requestMVar responseMVar
      either ioError return =<< takeMVar responseMVar

Then it uses "replicateM_ poolSize . forkIO . forever $ do ...". This means the same as: replicateM_ poolSize (forkIO (forever (do ...))). forever (do ...) executes the given do block in a loop, forever. forkIO executes the forever-loop in its own thread. replicateM_ poolSize executes the given forkIO action poolSize times. So this single line is enough to create our thread pool.

Then comes the code for the thread's single iteration. In each iteration, the thread executes "act" via "try". So any IO exceptions are caught and converted to a value, and placed in "res". Then the thread waits for someone to request a result by waiting on the mvar (takeMVar). Note the requests put on the requestMVar consist of a response MVar to reply to. The thread then places the result of the execution (which may be a value or an exception) into the response mvar.

Then we return an action that asks a thread in the pool for a result, and re-raises the IO exception if there was one, or just returns the threads' result.

Now, if you want to use preemptively, all you have to do is:

  getConnection <- preepmtively 20 (sshConnect remoteHost)

This example is meant to illustrate that real-world, concurrent, effectful programming is nice in Haskell, and not just the theoretical pure stuff.

If I gather from the other answers here correctly, the Haskell money feature (for abstraction) is type-classes.

FYI, I'm keying off of abstractions/features here because I see that as a clear route towards writing less code (less bugs).

On a more elementary level, lots of languages could benefit from algebraic data types. Most languages only support the `product' part of them well, but the `sum' is equally important.

Where product means in terms of C putting things together in a struct, and a sum is more like union. Only that C's unions are dangerous.

There are many interesting features that Python/Ruby/Lisp-variants can encode, but Haskell does with static guarantees, whereas Python/Ruby use dynamism (e.g: general polymorphism, "duck typing", various strong type system features that Python/Ruby do not "need" because they don't attempt to give guarantees, etc).

Dons does a good job showing how my python code is significantly shorter when he writes the equivalent haskell.