Re: Response to ROOT criticism?

From: Arthur E. Snyder <>
Date: Thu, 3 Aug 2006 10:32:53 -0700 (PDT)

While there are certainly problems with ROOT and it design and documentation and with C++, ROOT has on overwhelming advantage over the alternatives -- it's support! While I often find it hard to figure how to do something or ecounter seemingly bizzare behavior, if I post a queastion I get the answer (usually from Rene B).. Sometimes within an hour when it's the middle of the night in europe!

-Art S.

A.E. Snyder, Group EC                        \!c*p?/
SLAC Mail Stop #95                          ((.   .))
Box 4349                                        |
Stanford, Ca, USA, 94309                      '\|/`                 o
phone:650-926-2701                              _          BaBar
FAX:650-926-2657                          Collaboration

On Thu, 3 Aug 2006, Andy Buckley wrote:

> 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 ( 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
> ( 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:
Received on Thu Aug 03 2006 - 19:33:14 MEST

This archive was generated by hypermail 2.2.0 : Mon Jan 01 2007 - 16:32:00 MET