
On Tue, Sep 28, 2010 at 02:23:58PM -0400, Johan Tibell wrote:
On Tue, Sep 28, 2010 at 9:57 AM, Ian Lynagh
wrote: I don't understand why the number of functions is such an issue. To me, ease of use is more important.
But more functions hurts ease of use!
But we're not really talking about adding another 150 functions; we're talking about adding 1 additional concept (monadic functions). If you know about the {map, filter, ...} concept and the *M concept then you already understand {mapM, filterM, ...}. Likewise *WithKey. As someone else said, it would be nice if the documentation grouped the functions by their "root" (e.g. all the filter* functions together.
An API gets harder to grasp the more functions it has and knowing which function to use gets harder when the number of functions increases.
I think the code is easier to read and maintain if it isn't full of const's, \_'s, etc. I'm not convinced it's harder for an expert to write with, and I think a beginner will generally prefer having the functionality they need directly available, rather than having to compose functions together.
OO map data type get away with about 10-15 functions, we have 150!
I'd need to see a comparison to comment.
I've written about this topic before on haskell-cafe. That post contains a somewhat more thorough arguments for not adding too many functions to APIs. Let me know if you can't find it.
A link would be useful. Thanks Ian