> > > (In comparison, take a look at something as simple as logging. Through > people inventing abstractions, and abstractions on abstractions, it's > actually turned into something difficult to manage. Using SL4FJ, > putting in the right bindings .jar so it routes through Log4J -- and > don't forget log4j.xml -- which you have to use because your > dependencies use it, and then, what about that library that will try > to select Log4J or Commons on its own, but it's using Commons because > it found it in the classpath, and now you don't remember which file > configures that, and...) >
This is a nice point. I don't think that the original author of commons logging wanted his system to become "de facto" standard and logging abstraction system: http://radio.weblogs.com/0122027/2003/08/15.html But commons logging grew and spreaded into so many projects that it is really hard to get rid of it now. Remarkable piece of history to learn from :-) > > > On Mon, Sep 7, 2009 at 8:32 AM, Lukáš Vlček<lukas.vl...@gmail.com> wrote: > > Hi, > > just a note: Wouldn't it be better to talk about MapReduce as opposed to > > Hadoop? This means that for each algorithm implemented in Mahout it > should > > be clearly stated wheter it is MapReduce based implementation or not (or > > using other ways to make it scalable). I can imagine it could be useful > to > > abstract from Hadoop to the point where it would be possible to use > > different MapReduce providers. I am not sure wheter there is any > consensus > > about how MapReduce interfaces API should look like but Mahout could be a > > good candidate for a project to define and create abstract MapReduce API. >
