Response to ROOT criticism?

From: Andy Buckley <Andy.Buckley_at_durham.ac.uk>
Date: Thu, 03 Aug 2006 16:06:24 +0100

A few weeks ago we had the long discussion about ROOT's page on Wikipedia. I'm pleased to note that the page is now more balanced than it was, and the discussion continues, so some progress on the initial topic was made. Good!

During that discussion, Rene Brun said that after the next ROOT release he would respond to the specific technical criticisms that came up in the discussion (http://root.cern.ch/root/roottalk/roottalk06/0823.html). Since the answer never came, this email is a reminder!

I'd like to see how the development team answers some of our points, hopefully without degenerating into another slanging match. To save trawling the previous thread for the topics, here are a selected few in fairly brief form (and _roughly_ in decreasing order of importance from my point of view):

####################

Interactive scripting interface

---

Is C++ really considered as a sensible language for interactive use? Given that it's legendary even among other compiled, strong-typed languages for being baroque and syntactically complex? Is there any intention to use Python, Ruby
(or another language specifically _designed_ for interactive/scripting use) as
the default text UI?

Memory management / object ownership

---

If I pass a histogram to a canvas, say to plot it to an EPS file, and then want to delete the canvas and do some more manipulations on the histogram, I can't do so directly because the canvas' destructor will also delete any objects to which it holds pointers. This over-aggressive memory management forces weird strategies like cloning everything before passing it to a canvas: is that really justifiable?

Global state

---

When I joined this list at the time of the Wikipedia discussion, I saw a reply from Rene to a question about tree-filling
(http://root.cern.ch/root/roottalk/roottalk06/0779.html) where the answer was:

Instead of doing:

    TTree *T = new TTree(...)
    TFile *f = new TFile(...)
you should do:

    TFile *f = new TFile(...)
    TTree *T = new TTree(...)

So, in other words, the order of semantically unrelated statements can matter due to hidden state variables. What's the justification for such subtle and invisible dependence on the state? Doesn't this create pitfalls in development of user code?

Reinvention / compatibility

---

Why doesn't ROOT encourage use of existing standard tools like the C++ STL
(encouraged pretty much everywhere else in my experience) and the established
HDF data formats (which pre-date and provide much of the functionality of the ROOT format)? In the case of the STL, is there any reason for non-use of templated containers in ROOT other than that CINT doesn't understand them properly? In the case of HDF5, wouldn't it be better to extend it for object storage than to re-invent the wheel?

Class design

---

My canonical example of a problematic class structure in ROOT is the histogram classes:

• All histograms inherit from the 1D TH1. Therefore TH1F, for example, has a GetZAxis() method, which should never be used! So the class design renders object polymorphism pointless.
• Histogram data and presentation are conjoined: if I make a histogram const to protect the sanctity of my data, I also can't change its colour. D'oh.
• and more...

What's the justification for allowing the histogram classes (probably the most widely used classes in ROOT) to remain so poorly implemented? (There are, of course, other examples, but I know the histogramming fairly well)

Reflex, Mathcore/Mathmore and Minuit++

---

Can the developers comment on whether these packages, now part of the ROOT project, will remain usable without any dependencies on the rest of the ROOT libraries? I can see no reason for the objects in these classes to inherit from TObject, for example, and to do so would greatly reduce their usefulness to areas of HEP code which don't use ROOT. Comments?

####################

That's it! Well, not quite: others on the Wikipedia talk page, in the previous mailing list discussion (and in real life HEP meetings, of course) have highlighted concerns about ROOT's persistency and other features. But to keep it reasonably short, I've just picked these few.

Thanks to the ROOT team for (hopefully) taking the time to address my concerns. I'd like to re-iterate that I have no reason for opposition to ROOT, no other wares to sell: I'm just enumerating the reasons why I stopped using ROOT. If these issues are addressed, then maybe I'll go back to using it :-)

I think a valid point in the previous discussion was that the dominant component of data analysis time is often the time spent getting the software in a usable state rather than the time spent number-crunching. So before the complaints flood into my email inbox, consider that this sort of "philosophising" *can* have a definite impact on the day-to-day work of data analysis --- just because you can currently persuade ROOT to do what you want doesn't mean that it can't be improved! But if you're not interested in this design discussion, sorry in advance if you have to delete a lot of email.

Best wishes,
Andy

-- 
Andy Buckley: CEDAR @ IPPP, Durham
Work: www.cedar.ac.uk
www.insectnation.org

Received on Thu Aug 03 2006 - 17:08:53 MEST