Yeah, maybe I've been a little too enthusiastic about code golfing. I've noticed that haskell programs usually have short functions (compared to imperative languages). I love this---I love how when you get a function down to four or fewer lines, you can tell its structure in a glance. Yes, some Haskell structures can look confusing at first, but I find that with practice looking at them, they start to look natural. Like the way that your mind pictures &&& splitting the input---I'm sure you find that doesn't take any effort and feels like a common and natural pattern. It seems to work like that with much of Haskell. Oh, can I bring up one other intermediate variable elimination situation? I used to do things like func :: IO MyData func = do x <- readMyData return $ someProcessing x When I first encountered Monads, I was confused by functions that move things into Monads, like 'liftM'. But I am starting to see the light. I realized I could do func = someProcessing `liftM` readMyData Or func = readMyData >>= someProcessing I was explaining to a friend that Haskell's abstracted patterns seem confusing to me, coming from an imperative background. She only has a little experience programming, so I tried giving some analogies. Say you are an imperative programmer and you are do a physical simulation of automobiles. You see that they all have an engine, so you write some code that handles abstracted common features of engines. In Haskell, abstracted patterns are more like this--say you have a a forklift that manipulates boxes. say that's your "function." Then you write a function that produces a forklift that manipulates boxes that are inside trucks. In the imperative world, it's like "huh? where does that get you?" But it makes more sense now. D