Imperative programs read like English. Functional ones read like Apache.

The Main difference is, a functional programs mainly talks about what things are, not what they do. For instance:

  // C(++)
  int square(int n)
  {
    return n * n;
  }

  -- Haskell
  square :: Int -> Int
  square n = n * n

The C code reads like a procedure to follow: "return n times n to whoever called you" (I'm anthropomorphising square(), here). The Haskell code reads like a description: "the square of n is n times n".

That was the first major difficulty. Now the second one: functional code is often like reversed imperative code:

  // C(++)
  int compute(int n)
  {
    int x = foo(n);
    int y = bar(x);
    int z = baz(y);
    return z;
  }

  -- Haskell
  compute :: Int -> Int
  compute n = baz (bar (foo n))

  -- alternate definition
  compute n = baz . bar . foo $ n
    where g . f = \x -> g (f x) -- function composition
          f $ x = f x           -- function application

So, in the Haskell code, you see that the data flows from right to left, instead of top to bottom. Like Unix pipes, only reversed.

The final difficulty is getting used to the fact that functions are passed around directly. In C++, Java, or Python, we often pass around objects, who may or may not hold the same methods than the others that where passed around in the same way (that's polymorphism). Subtype polymorphism is neat, but most often, you need it because you want one method to change depending on various factors. A simpler way to do this is pass around the function directly.

That leads to some powerful, though uncommon in the imperative world, idioms. For instance, you can write your own customized loops. Imagine for instance that you want to process lists in Haskell:

                                -- A List is either
  data List a = Empty           -- an empty node,
              | Cons a (List a) -- or a cons cell,
                                -- with an element and a list.

Now let's process the list

  inc-all :: List Int -> List Int
  inc-all Empty      = Empty
  inc-all (Cons e l) = Cons (foo e + 1) (inc-all l)

  dbl-all :: List Int -> List Int
  dbl-all Empty      = Empty
  dbl-all (Cons e l) = Cons (foo e * e) (inc-all l)

See how much they have in common? There's a way to factor out that, with a map:

  map (a -> b) -> List a -> list b
  map f Empty      = Empty
  map f (Cons e l) = Cons (f e) (map f l)

Note that the first argument is a function, hence the (a -> b) between parentheses. Using it is very simple:

  inc-all l = map (λe -> e + 1) l
  dbl-all l = map (λe -> e * e) l

And Haskell can make it even more concise, with what we call partial application. Haskell functions actually have only one argument. Multiple arguments are simulated by having the function return another function. Here:

  add :: Int -> (Int -> Int)
  add x = λy -> (x + y)

Which is the same as:

  add :: Int -> Int -> Int
  add x y = x + y

Or even

  add :: Int -> Int -> Int
  add = λx -> (λy -> (x + y))

So, inc-all and dbl-all above can be written as:

  inc-all = map (λe -> e + 1)
  dbl-all = map (λe -> e * e)

Without those fundamentals, one doesn't stand a chance at understanding real world functional code. It's just too different. It's no harder, though. The main difficulty here is to change your mindset.

Now I haven't talked about macros…