I don't do Haskell, but I have worked on projects with lots of small functions, and one of the problems with that is that can be... too many functions. You have to go look up three functions every time you read a block of code. Worse, people start writing the same functions over and over again.
There's probably a bigger picture problem and fix in that kind of situation, but it is something I think about.
> You have to go look up three functions every time you read a block of code.
When you write small, single-purpose functions, you can make them fairly self-documenting with the name alone. If you have to look up a one-line function, it probably doesn't have a very clear function or name.
> Worse, people start writing the same functions over and over again.
That one I've definitely run into.
> There's probably a bigger picture problem and fix in that kind of situation, but it is something I think about.
Mechanisms to search functions by type ("find me a function that takes an X and returns a Y") help quite a bit.
When you write small, single-purpose functions, you can make them fairly self-documenting with the name alone.
Sometimes, although with languages like Haskell there can be a related problem that accurate names for these small functions wind up being almost as long, or even longer, than their definitions.
For instance, the lazy readTVar, modifyTVar, etc. functions have strict analogs called readTVar' and so on.
mapM, foldM, replicateM, and traverse return a monadic value, while mapM_, foldM_, replicateM_, traverse_ and friends discard the return value (giving an m () instead of an m a).
There's probably a bigger picture problem and fix in that kind of situation, but it is something I think about.