Re: Response to ROOT criticism?

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.

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.

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!".

> 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.

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? PAW worked like that (Fortran for real programming and KUMACs for quick hacks) so ROOT developers are familar with "two languages" systems.

> Memory management / object ownership
> ------------------------------------
> ... This over-aggressive memory management
> forces weird strategies like cloning everything before passing it to a
> canvas: is that really justifiable?

This is where ROOT != C++. It is the least well understood part of ROOT and I see it cause problems to every ROOT developer, with any ROOT application beyound "Hello world!".

> Global state
> ------------
> 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 ...

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.

> Reinvention / compatibility
> ---------------------------
> Why doesn't ROOT encourage use of existing standard tools like the C++ STL

Because ROOT predates STL? Because vendor support of STL is imperfect?

> templates

I think you will find that even "pure C++" experts do not agree on whether one should use templates. Certainly there are practical problems with compilation speed and compiler bugs.

> 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?

> Class design
> ------------
> My canonical example of a problematic class structure in ROOT is ...

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

> 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?

In my experience with embedding parts of the ROOT toolkit into a large program written in Fortran-90 (yes), ROOT is pretty good at staying out of the way. I think one will find that in practice the ROOT dependancy is not a problem (unless it clashes with some kind of "One shall not link with ROOT" religion).

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada