Re: Response to ROOT criticism?

From: Andy Buckley <>
Date: Mon, 07 Aug 2006 13:12:02 +0100

Rene Brun wrote:
> Andy Buckley wrote:

>> Incidentally, I'm not the only one who finds current ROOT memory
>> management awkward: it wasn't even one of my criticisms until a bunch
>> of other people contacted me to say it was their number one complaint!
> This is a vague and poor statement.

How would you like me to be more precise? It's true: people contacted me to say that they think the way ROOT manages memory (de)allocation is a big problem. Note that the phrase "This is a vague and poor statement." is self-consistent :-)

>> My complaint isn't that there *is* a global state: that's debateable.
>> It's that classes like trees and histograms, even if they're only ever
>> memory-resident, are over-sensitive to that global state and - worse -
>> manipulate it via invisible side-effects.
> This is a void argument or rather an argument of somebody with no > arguments.

I think it's a very good argument. What problem do you have with it?

>> I wouldn't rule out selection effects in that observation: people who
>> wish to use HDF rather than ROOT are unlikely to contact the ROOT
>> developers!

> So why is it a problem then? Be consistent with yourself.

Because this is meant to be about making a useful system for scientific analysis, not empire building. If people are choosing to use other tools *because* ROOT doesn't interact with what they want to use, then shouldn't ROOT think about providing that functionality, rather than saying "not our problem"? You seem to be arguing for tunnel vision, and given that that can only curtail the usefulness of ROOT for the scientific community, I can't agree.

>> That's a shame, because I think it's an interesting point: templates
>> are dynamic through polymorphism, i.e. good class hierarchy design.
>> I'd be interested to know of a circumstance where they aren't flexible
>> and generic enough, as much for personal information as anything else.
> No, I am sorry, C++ templates are static. That's why you can do > type-checking at compilation time.

I think the issue here is a difference in priorities: I consider type-safety, such as offered by templates, to be significantly more important than interactive use of C++ code.

>> And this isn't just because of CINT's inability to understand them?

> Again the proof that you are making statements about something that you 
> do not know. You can perfectly use templates with CINT. But because 
> templates are statically defined in the source, one is forced to
> generate dictionaries for the concrete class instances to use
> interactively or make I/O with.

I see no technical reason why CINT, provided with a knowledge of what a std::vector<T> class does, and a dictionary for class T, shouldn't be able to work out how the combination should behave. That's what I mean by "inability to understand templates".

CINT has no intrinsic concept of what "template <class T>" or the "<...>" notation means, but if you tell it that there's a static class whose name contains angle brackets and provide it with an individual dictionary for each static template instantiation, then it'll make do. A bit of a hack, really.

> It would be good if templates could be defined at run time.

Yes, it would but no-one else in the world needs it to do so, because no-one else tries to interpret C++. Because that's not what it's designed for. And this is exactly why I hardly ever use ROOT interactively.

>> And what's the excuse when it comes to STL components like
>> std::string, which are actually static template instances and are
>> much safer and more flexible than char*?

Just thought I'd reiterate this: the above templates argument doesn't explain why other standard library components like std::string aren't used, given that it offers many advantages, is implicitly constructable from char* (so there are no legacy code issues) and is just as static as char*.

>> As long as I can continue to
>> use Minuit without the need for dictionaries and libCore, I'm happy.
> So you will be unhappy. To use Minuit interactively, you need a dictionary.

...or any other interactive user interface written around Minuit.

Personally, I'm still happy, because I compile this sort of application. If I wanted scriptable use, I'd probably write a Python wrapper using Boost.Python. To imply that (ROOT) dictionaries are the *only* way is a misrepresentation.

Reducing unnecessary dependencies provides the opportunity for different uses to arise. You've already said that too many dependencies can kill a project: is the ROOT solution to this is to make sure that any dependencies get absorbed *into* ROOT?

> AHAHAH! You probably forgot a long list of other candidates. This is > the typical argument of a teen ager computer scientist [...]
> you will fail in your projects if you do not understand this point. > Probably simply a question of experience. [...]
> Let's talk about this in a few years, if you are still in the field.

Why would I stay when treated like this? :) Never outside this list have I been so vigorously attacked in what should be a technical software discussion. So can we leave the personal jibes out of it, please?

Incidentally, like Julius, I lost heart in this discussion even before it began, and I suspect it's now time to stop. My points are made, anyway. If there are any more (civil) responses to be made, please CC me directly.

Andy Received on Mon Aug 07 2006 - 14:12:49 MEST

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