If there is no real difference the one that is better supported (with
tutorials, examples etc.) will dominate the other. I don't see a
reason to unify them. Let them duke it out :)
-deech
On Wed, Jul 7, 2010 at 1:46 PM, Jonathan Daugherty
Anyway, the point remains, we need a single goto database library.
Though the lack of response to this thread makes me think no one particularly thinks this is a problem.
This is an interesting problem. For my part, I suspect the proliferation of high-level database libraries is going to continue. If you were to convince the present package maintainers to pitch in and build a Grand Database Library, inevitably someone would come along and build another one for whatever reason. Also, I don't think the dust has settled on techniques for database access in Haskell in any case, even for RDBMSs in particular.
Since I couldn't agree more that duplication of effort is a sad thing, I think a good place to start is for people to write database library binding-only packages that get used by higher-level libraries like HDBC and Takusen. Such libraries should include memory management hooks specific to the sematics of the engine in question. There are a couple of libraries for this on Hackage already, but they don't appear to be used by any of the high-level database abstraction libraries.
Otherwise I'd ask: what qualifies as a "go-to" library? Which users should it satisfy? How accessible should it be? Most answers I can think of lead me to believe enough people will be put off by it that other libraries will pop up. :)
-- Jonathan Daugherty _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe