That complex function will turn out to be not all that complex at all; it can be written as just three simple functions composed together! -- Why this requires to learn Haskell, instead of ML or Scheme or Erlang?
I'm not debating the opinion that Haskell is great language to learn, but the benefits of learning the language were not clear to me after reading the article. Does anyone care to elaborate?
Haskell will show you that when you thought you broke your code down into small functions in those languages, you were wrong in ways you currently can't even see and they're still shot through with duplication and mixing of concerns.
This is really the core of the "it changes how you program"; the environments you mention are so full of conflation of IO and mutation and state that you don't even see it, because it's just the way it is. Haskell will ungently pry those apart for you, if you stick around long enough to actually become proficient. You can take this back into other programming languages where this separation is not enforced, but I'm not convinced you can learn it where it is not enforced. The feedback cycle is so direct in Haskell ("Type Error: ...") and so diffuse in other languages (two months later "Aw crap, I should have isolated IO from non-IO better...").
(Oh you think that last parenthetical is a joke? Ha! I wish.)
For me, learning Haskell was like visiting a third-world country: enlightening, very different, but ultimately I leave feeling very grateful that I'm not a permanent resident. All in all, I would recommend the experience.
Deleted comment
What if f is a function of n-arity
(define compose (f g) (lambda (x) (f . (g x))))
If g is n-arity
(define compose (f g) (lambda (x) (f (g . x))))
I gave them all the same name because naming things is hard.