Well, xmonad is an excellent example :-)

Pandoc:

http://johnmacfarlane.net/pandoc/

XMonad:

http://xmonad.org/

I'd say xmonad[1]! It is a very light and fast tiling WM.

There's also a couple of elegant and blazingly fast web frameworks, such as Yesod, Snap and Happstack[2].

1: http://xmonad.org/

2: http://www.haskell.org/haskellwiki/Web/Comparison_of_Happsta... http://stackoverflow.com/questions/5645168/comparing-haskell...

I'll expand a little, because I've been feeling the same thing recently.

Python has syntactic support for list[0] comprehensions, which can be used a little like maps:

  def addOne(n):
    return n+1

  l = [1, 2, 3]
  [ addOne(n) for n in l ] # [2, 3, 4]

a little like filters:

  def isOdd(n):
    return n % 2 == 1

  l = [1, 2, 3]
  [ n for n in l if isOdd(n) ] # [1, 3]

and a little like folds/reductions:

  def accum(s):
    acc = s
    def a(n):
      acc += a
      return acc
    return a

  l = [1, 2, 3]
  reduce = accum(0)
  [ reduce (n) for n in l ][-1] # 6

You can also do Cartesian joins, though I rarely see these.

There are a couple of problems I've run into. The first is that Python's libraries are just not engineered with the idea of using list comprehensions in this way - folding is as awkward as it looks above, exceptions thrown in the list comprehension functions will terminate the comprehension, many python functions alter state and return None rather than a useful output, and so on. The second is that they're amazingly uncomposable, syntactically:

   l.map(addOne).filter(isOdd).reduce(accum(0))

is what I'd write in Scala, which is extremely tractable. In comparison, here's the equivalent in python:

  [ reduce(nr) for nr in [ nf for nf in [ addOne(nm) for nm in l ] if isOdd(nf) ] ][-1]

You note that I've had to rename the elements, because they "leak" to their surrounding comprehension - this can be quite confusing the first time you see it. Also these are fairly trivial comprehensions, which call functions rather than evaluate expressions in-place - this is well-supported and very idiomatic, but makes comprehension composition much harder.

I find Python's comprehension style very convenient, and I'm sure you could produce an excellent theoretical abstraction over it, but if you're coming at it from the point of view of wanting them to be map/reduce or something equally reasonable-about, you're going to be disappointed. Python isn't an object-oriented language, and isn't a functional language - the more I use it the more I think it's something akin to a collection-oriented language. Maybe that's just the way I use it. :)

[0] and also set comprehensions, dict comprehensions, and generator (lazy list) comprehensions, which are wonderful but exacerbate both the problems I talk about.

Sure. What I meant is that while python does have first-class functions, you don't make much use of it in idiomatic style. Much of the logic is still encapsulated in bloated, less flexible classes and/or imperative style variables you create to hold middle values.

If you wanted to use first-class functions in your code pervasively, then you lack the massive libraries and compiler optimizations available to Haskell. As a result, first-class functions are only used at a superficial level in Python, perhaps as key arguments to some functions.

In a language like Haskell, on the other hand, you make use of the first-class nature of functions all the time.

It's common to have pipelines like:

foldr step 0 . map convert . concatMap (chunks 2) $ inputList

  where

    step = ...

    convert = ...

Almost everything in that pipeline takes a function as a parameter. Also note how chunks takes an integer, partially applying the function, and returns a new function that is now ready to take a list to chunk into groups of 2. You really get used to this stuff.