Adding System.FilePath
Sven Panne
sven.panne at aedion.de
Fri Mar 16 11:24:22 EDT 2007
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.
More information about the Libraries
mailing list