Re: Response to ROOT criticism?

Hi Andy

Although you are waiting for Rene´s answer I cannot resist:

1. Reinvention: Please answer me the following questions? a, Why do you reinvent CEDAR? Use ROOT instead! b, Why did Kemeny&Kurtz reinvent BASIC? There was already FORTRAN! c, Why did Kernighan&Ritchie reinvent C? There was already PASCAL? d, Why did J.Chambers reinvent S? There was already SAS!
2. Global State: It seems that for guys like you McDonalds needed to write on its coffee cups: "Warning: Coffee is hot! Do not drink while driving!" Analogously, the ROOT developers should write: "Warning: Do not create large trees w/o creating a TFile!"

BTW, for your info:
As long as a tree fits into memory, you do not need to create a file first!

Christian

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