On Thu, May 19, 2011 at 20:33, Andrew Coppin
To all the people who look at Hackage, see that there are 6 different libraries for processing Unicode text files, and claim that this is somehow a *good* thing, I offer the above essay as a counter-example.
Here is what usually happens: Every library that is *useful* undergoes an iterative process in which is will gradually be improved until a winner emerges. This is like biological evolution and a signal of a healthy community. For a winner to emerge however (like Text in Unicode) - there need to be a clear problem you are trying to solve and the solution must be fairly easy to use. This doesn't always happen if the initial problem is too vague. This is by the way the same model used for the Linux kernel. At some point there was like 3 wifi stacks and 4 USB stacks in the kernel, until people opted to extend the one that was easiest to extend. Haskell's demon are advanced type-level constructions at the library level. If you build a library which is hard to use because you need to understand a complex type-world, then there will be less adoption compared to a simpler library more people understand. Common Lisps demon are complex macros and that you need discipline in the more dynamic typing environment. Also that there is no enforcing of concern separation. On the other hand, a library with a simple type-world may be too simple and not give the guarantees one would like. Hence, for the same problem, you now have justification for the existence of two libraries. My personal gripe is the construction of libraries for the sake of constructing libraries. I like the tools I use to have been used in anger in real projects. That tends to weed out some problems right away because you had an actual user. It also underpins a mantra I learned from the Erlang community: Build tools, not solutions. The library should support your program and not provide a solution. If that is not the case, you are probably better off without the library in the first place. The horror-case I know is Java Apache XML-RPC. It underwent three iterations. v1.x was useful but cumbersome. v2.x improves the interface and is more useful. v3.x is a mistake. The author decided to use reflection, automatic generation and generate interfaces based on classes. That library is very hard to use in practice because there are many things you want to do you can't. It is also a project with a RequestProcessorFactoryFactory class :) -- J.