I agree regarding obscure code, or anything written in C (** duck **), but of course I don't think that is the case here.
When I started learning Haskell a lot of the "elegant" solutions really bothered me - I couldn't understand them and they seemed obscure. They used many nested function definitions or class instances which tied my brain in knots. I slowly realized, though, that once you knew the definition of a function, you could forget it. The details didn't matter - you just needed to be reminded of its basic operation and type. I think that Haskell's purity (in the technical sense) allows this much more than languages w/ side-effects. Its very easy to extract a chunk of code and wrap it up in a small definition w/o changing the behavior of your program.
Let me illustrate with calculus. These two things say the same thing, but one is more suitable for a beginner while the other is obvious to anyone familiar with the notation:
"Consider a parabola. Look at the slope between two points on the curve. Now move the points closer together. Consider how the slope changes. As the points get closer and closer together, the slope of the line between them will converge on 2 * x, no matter where you are on the curve"
"d (x ^ 2) / dx = 2 * x"
I would expect the "tricks" that Erik promised to show would be along these lines - "tricks" that make our programs more flexible while at the same time "easier" to understand (once you know the basics).