Functions are indeed a good tool but at one point, they accumulate more and more parameters or more complex structures as parameters. Eventually, while you still understand the purpose of a function, it is difficult to understand all that it abstracts away.
I am just saying this because I totally relate to the article,it is often very hard to contain or abstract complexity. or it requires nearly equally complex mechanisms or abstractions.
Yes, a function should be short and sweet. This applies very well to functions in Haskell or Scheme (or words in Forth). Those languages (Scheme slightly less so) also have low syntactic overhead for defining a function/word.
It's OK for functions to grow more abstract. Just provide the simple things, too.
E.g. you start out with `map' and `filter', but then realize that `foldr' can express both of them and much more. One viable path is to rewrite the definitions of `map' and `filter' in terms of `foldr'. One should not use `foldr' everytime in the code where a `map' or `filter' suffice.
One can layer abstractions and then use the most specific tool possible that still has all the flexibility you need at each point.
As features accumulate over time, I find this is harder and harder to maintain. But it heavily depends on the situation (abstractions don't always hold as well as originally hoped). I guess I just remember more the times it goes wrong than the times it went right.
Oh, I often have to bang my head against the wall quite a few times, before I hit on the right abstraction.
Having more powerful abstraction techniques, like they are possible in languages like Haskell or Scheme/Lisp, tends to give less leaky abstractions for me.
I am just saying this because I totally relate to the article,it is often very hard to contain or abstract complexity. or it requires nearly equally complex mechanisms or abstractions.