Re: Response to ROOT criticism?

From: Andy Buckley <Andy.Buckley_at_durham.ac.uk>
Date: Mon, 07 Aug 2006 13:05:47 +0100

Konstantin Olchanski wrote:
> On Thu, Aug 03, 2006 at 04:06:24PM +0100, Andy Buckley wrote:

>> I'd like to see how the development team answers some of our points ...

>
> Andy, I think most people agree that you raise valid questions. The
> problem is what to do with the answers.

Thanks :)

> ROOT is the way it is because it is the way it is: it is pointless
> to say "in 1996 you should have used language X instead of Y",
> "in 1998 you should have inherited class C from class B,
> not from A", etc.

I wouldn't say it's entirely pointless: deprecation mechanisms, refactoring and various other ideas have received plenty of attention in software engineering for years. No software, including ROOT, should be a design set in stone.

> One can accept ROOT as it is and look at it's history as a lesson
> for the *next* ROOT. Or one can step forward and say "I will write
> a better ROOT myself!".

I've thought of that, but unfortunately no-one pays me to write analysis systems! However, I've found solutions elsewhere for the ROOT functionality that I need, so maybe there isn't so much to do. I think the point about "lessons to be learned" is a good one.

>> Interactive scripting interface
>> -------------------------------
>> Is C++ really considered as a sensible language for interactive use? ...

>
> "Back then", before Ruby, Python, etc, C++ was the obvious choice.

I'm not sure C++ was the *obvious* choice, but that leads into a whole raft of opinion. What's done is done.

Personally, I think there's a strong argument for deprecating C++ as an interactive UI language and concentrating on the Python/Ruby interfaces (and/or a simple interpreted language for simple data handling and plotting tasks, cf. gnuplot).

> Also considering that one has to know C++ to use ROOT anyway (to do
> anything useful beyound "hello world!"), why should the user have
> to learn yet another language?

That's how things *are*, but not necessarily how they should be. I'm actually surprised that data analysis users, who are not career programmers, are expected to use a language as difficult as C++ *interactively* to analyse data. I think gnuplot and R's use of high-level data analysis languages are much more user friendly, despite arguable flaws in the implementation.

That way, programmers always have the option to use the C++ API if they want to build a custom application system using the analysis system libraries. Hippodraw works much like that, and I think it's a neat solution: you just need to learn Python (a simple, relatively safe language) to analyse data, but you can also write custom apps based on it using C++. No need to learn two languages unless you want to do two very different things.

> We have this problem in the real world all the time. Try
> these instructions in the wrong order:
>
> Open door
> Walk into room
>
> We learned the relationship between rooms and doors and stay
> out of trouble (unless presented with unusual doors). Same in ROOT,
> one has to learn that TTree and TFile are connected and have
> to be used in the right order.

I don't find the analogy convincing, for various reasons. Mainly, real-world analogies fail because software is *not* the real world, so it's unclear that they're meaningful. There's a lot of psychology in learning how things work in the "real world" and, rightly, good software design aims to avoid that painful trial and error process.

For example, if TTree's constructor always required a TFile to be supplied as an argument, then a) the dependency would be obvious and b) you could write to several files at the same time without having to issue gROOT->cd() calls. Personally, I find that much more friendly than having to learn by trial and error, like a child working out how doors operate :)

Incidentally, side-effects (which I suppose is what this point was about, rather than global state per se) are probably the hardest thing to deal with when analysing and debugging programs (cf. functional programming's total lack of side effects), so actively encouraging them is very odd.

>> the established HDF data formats (which pre-date and provide much of the 
>> functionality of the ROOT format)?

>
> Never heard of "established HDF data formats". Are they the HEP
> equivalent of the ISO network stack layers?

Try http://hdf.ncsa.uiuc.edu/HDF5/ . They're widely used, but not in HEP. It's impossible to say why, but the lack of ROOT support is certainly an issue.

> By definition, there cannot be any "logical perfect class structure
> that stays perfect and logical through 10 years of evolution".

That's not by definition :) However, I think that observation just reiterates these classes could and should be fixed to better align with the result of those 10 years of evolution.

Andy Received on Mon Aug 07 2006 - 14:06:22 MEST