mahout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukáš Vlček <>
Subject Re: What's the plan for Mahout?
Date Mon, 07 Sep 2009 08:10:14 GMT
> (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:
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<> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message