Re: [Fwd: Re: Wikipedia criticism about root]

This one also seems not to have reached the list when I sent it earlier:

Fons Rademakers wrote:
> I am aware of the comments and points of view of Andy, but did not
> feel inclined to remove them or move them to the discussion page myself
> since that could be interpreted as censorship by the authors.

Well, now is a good time for discussion, then! I guess you're also aware of my more extensive criticisms at
http://www.insectnation.org/howto/problems-with-root

I was contacted a while ago by Philippe Canal about some aspects of this page, to which I replied but was never sure if they were considered valid criticisms or not. I would appreciate feedback on which of these are significant and which aren't (or have been fixed).

> We are
> well aware of some of these issues, but they all have a good reason for
> being like they are for the time being (STL, doxygen, etc. did not exist
> when we started with ROOT,

The STL wasn't available in 1994 (when ROOT was started), but the draft did exist and standardisation came soon afterwards. Anyway, I would argue that that doesn't explain why ROOT still doesn't use the STL: CLHEP was started in 1992 and uses the STL extensively.

Similar things could be said about CLHEP and Doxygen: conversion to use Doxygen requires little more than adding a few extra / symbols with code that's already adequately commented. This can be done gradually with little effort: much less than maintaining a custom C++ parser and HTML generator! Of course, I wouldn't mention this but for Doxygen's output being far more user friendly than that on the ROOT API pages: a significant factor in code where the API is very much exposed to users.

And, of course, I still can't fathom why the TH1 classes "have a good reason" for having a GetZaxis() method :-)

> the system is "monolithic" because all
> components or plugins use infrastructure provided by the core of the
> system, it is just as monolithic as the successful Java class library).

There is definitely a case for better choice of words on the Wikipedia page here. The library segmentation is quite reasonable and I can understand the reason for bundling many components together. However, it's unclear to me why projects that have no natural dependency on the ROOT core infrastructure (e.g. Reflex, Minuit++ and the math libraries) need to be bundled with ROOT rather than just linked against. I believe there may have been some issues with these packages breaking the ROOT "capitalised method names" convention, but that seems a case for a thin wrapper library rather than conversion and encapsulation of the original package.

I remain confused about whether ROOT is a file format, a stats analysis system, a simulation framework or what. But to use any single piece (the file format being a good example) I have to use whole system. Guy Barrand rewrote the ROOT I/O system as a stand-alone library (Rio) several years ago, but for some reason this approach was dismissed and largely ignored.

Unfortunately, I don't know of any single word that describes the above accurately. Perhaps because it's less of a technical issue and more a reflection of the attitude that ROOT should be *the* single-source analysis package for HEP. Encouraging use of interoperable data formats and "tool-agnostic" utility libraries would allow physics users to choose their interface of choice without compromising the results. At the moment, much of HEP computing still suffers from a culture of re-invention, and "assimilating" useful stand-alone packages only encourages this trend.

> However, as you might know, ROOT is still evolving and over time some of
> these issues might be addressed.

I understand that the majority of use for ROOT is for histogramming, statistical manipulations on data trees etc. Hence, it would be nice to see improvements in the histogram class structure, error combination code, etc. --- after 14 years of ROOT I find it surprising that these areas are not more "polished". This seems more urgent than ODBC support or development of apache modules...

> Also the alternatives Andy mentions,
> AIDA, CLHEP, HippoDraw, JAS, etc. are themselves nothing more than first
> attempts and in that not even successful first attempts.

I asked Paul Kunz, the author of HippoDraw, what he thought of this. He informs me that "It is not correct to say first attempt for HippoDraw. HippoDraw was first done in 1990 with Objective-C as the OO GUI language and C as the core. It was my second project in OOP at that time. The current C++ was designed to replace the C code about 4 years ago after over 10 years experience in OOP design." HippoDraw has over 800 active users in the Mac OS X community alone. Unsuccessful?

Similar things could be said about CLHEP and JAS. If anything, CLHEP suffers from a development deadlock: I have opinions on this as well, but the wide use of CLHEP indicates that it has certainly not been an outright failure. The same applies to ROOT: in both cases there are improvements to be made.

Not that it matters, but personally I find HippoDraw a relative joy to use --- enough to recommend it to graduate students in a recent course on data analysis. Particularly for writing custom applications, the histogramming class structures in HD and JAS/JAIDA make a lot more sense than the ROOT ones. Hence, I'm afraid, I don't use ROOT much anymore, so my apologies if I'm out of touch with recent developments.

> If you or somebody else wants to update the ROOT wiki page, please be
> our guest.

Yes, please do!

Andy Received on Wed Jun 28 2006 - 18:22:23 MEST