On Friday 16 March 2007 15:32, Bulat Ziganshin wrote:
it is just the source of our current problems with base. of course, it is easier to add something to base instead of refactoring it. so we have that we have - more and more features added here and it makes refcatoring more and more problematic. now FPS team wants to implement something in Base via bytestrings that will make them unremovable from base. i think that it is old way, new way to make software is small building blocks which are maintained independently [...]
I'm slowly getting tired of your arguments: If you think that your way is the right way, implement whatever you like and come back with what you've got afterwards for discussion, this is OpenSource SW, after all. Having highly modular libraries with perfect APIs everybody likes would be great, but this is not where we are and is not where we will be in the near future. Stopping all further improvements just because there is a Grand Shiny Master Plan in somebody's brain doesn't get us anywhere. I'm a big fan of the 80:20 rule, and my hope is that my tiny proposal might get us a long way until the upcoming API wars (there *will* be some, I can guarantee you, looking back at past discussions) are settled. Go ahead, split base, keep GHC/Hugs/nhc98 alive while doing it, implement your I/O on the tons of platforms we currently support, but be prepared for funny dependency cycles, built-in compiler knowledge, nasty platform/performance hacks, etc. The reason the libraries currently look as they are is not that the people writing them have been idiots or have never heard about the fundamentals of good SW design, the reason is that the libs slowly evolved from something rather simple and are maintained in a evolutionary manner with very few "big bangs". We do not have 100 paid people working full-time on this, after all... Cheers, S.