RE: [Fwd: Re: Wikipedia criticism about root]

Hi Andy, {sorry, team. I do not want to go into discussions. I just want to "extract constcructive things" from this "holly war").

First af all, thanks for the critics (!). My personal experience convinced me that even unfair and FUD critics can help to improve "the product".

You wrote:
"class structure or GUI are my primary concerns. I find it hard to use ROOT as a reliable component in a well-engineered application, because many of the design idioms in ROOT data classes seem designed for the convenience of the ROOT GUI rather than a user who only wants to use a select few classes."

I didn't find in your text the critics on "ROOT GUI" (only mentioning about "ROOT guibuilding is added to the ROOT core" - which is not true). What do you mean by the words "... GUI are my primary concerns"?

Thanks.

Regards. Valeriy

-----Original Message-----
From: owner-roottalk_at_pcroot.cern.ch on behalf of Andy Buckley Sent: Thu 6/29/2006 1:43 PM
To: cstrato
Subject: Re: [Fwd: Re: [ROOT] Wikipedia criticism about root]  

cstrato wrote:

> When you go to Bjarne Stroustrup (you know he is the inventor of C++)
> homepage: http://www.research.att.com/~bs/C++.html
> today you will see that he mentions ROOT as one of the successful
> examples of using C++ besides many other applications.
[...]
 > This acknowledgment of ROOT as great framework by the inventor of C++  > speaks for itself!

A friend read your mail and pointed me at this link: http://www.fallacyfiles.org/authorit.html

:-)

> Since one of your main criticisms of ROOT is its lack of using
> templates, let me tell you that this is one of the reasons why I
> like ROOT. For my opinion of using templates, read my comment in:
> http://root.cern.ch/root/roottalk/roottalk05/1085.html

So you don't like templates because an aging Windows compiler didn't implement the standard properly? You're genuinely the only person I've ever encountered to not consider type-safe generic methods and containers to be an enormous boon.

Incidentally, the Java reasons for not implementing templates (or "generics" as they call them) are more complex than those for C++ as the Java world had a significant installed base of Java virtual machines which made bytecode changes impractical. The solution was to implement generics such that the bytecode was unchanged, and their addition plugged one of the few remaining "holes" in the language.

> You don´t like the monolithic design of ROOT? Let me tell you
> that the most successful frameworks are based on monolithic
> design such as MacApp or NextStep (now MacOS X). See my comment in:
> http://root.cern.ch/root/roottalk/roottalk03/3738.html
> which will also answer your question where ROOT got the "T" prefix
> on everything!

Interesting, but I don't see where the argument comes from. (I also note that the ROOT coding style guide that neither the "T" nor the "capitalised method names unlike the rest of the world"

Since it's something I'm familiar with, my obvious counter-example is visible in the package systems of most (all?) current Linux distributions: a typical medium-size application depends on many libraries such as GTK, Pango, ATK, GnomeVFs, etc. All these libraries are available separately rather than in a single monolithic block and I see no argument to say that this is unsuccessful.[*]

> I completely disagree with your criticism on CINT, which I consider
> one of the most ingenous pieces of software ever written:
> CINT allows you to easily write simple macros, analogous to the
> R scripts, and run them immediately. If you want to adhere to C++
> standard, you can simply compile the macro by typing "macro.C+"
> and you will get all error messages. I am developing all parts
> of my program (including the gui part) as CINT macros: When they
> do what I expect, I compile them with ACLIC to remove the errors,
> and then I include the code in my program. Since using CINT/ACLIC
> I see no need to use any debugger anymore (most of the time).

We've clearly had very different experiences: for me, CINT was unstable, buggy and had an annoying tendancy to do different thing based on the call order of theoretically unrelated statements. It was quite unpredictable which bits of ANSI C++ would be understood by CINT and which wouldn't, but in the case of problems the failure tended to be silent, resulting in an untraceable error emerging from an innocent piece of code later on.

Conversion of a CINT macro to compilable C++ was so non-trivial that I rapidly gave up on using CINT/ACLIC at all and just wrote proper C++ linked against the ROOT libraries. My experience with debugging and ACLIC was exactly the opposite of yours: ACLIC created temporary files which, in the event of a compile failure, made the error location extremely hard to track. Maybe this has changed more recently, but these are the issues that Philippe Canal wrote to me about 6 months ago and as far as I could tell, they were still valid criticisms at that time.

Finally, let's assume that given enough time these problems will be solved and CINT will be a complete, ANSI-compliant, bug free C++ interpreter and ACLIC is clever enough to resolve a bunch of the implicit dependencies in CINT scripts that all CINT code will compile. Is it still a good idea? I would argue that the likes of SciPy (www.scipy.org) have got a better approach: you write your scripts in Python which, unlike C++, has been designed for rapid development and interpreted use. The efficiency issues are allayed by the critical path processing tasks taking place in compiled objects rather than in the slow interpreted code. This completely removes the need for *any* compilation, while providing performance roughly 25 times better than CINT [**]. C++ was never designed to be interpreted: it is too baroque and complex for such a task and the idea that a primary user interface should require writing a sloppy set of C++ on a command line is frankly incredible. PyRoot seems a much better interface mechanism to me, but it still presents the problematic ROOT API to users.

> Since you write "the R project have produced a more powerful
> analysis framework...", read my comparison between ROOT and R in:
> http://root.cern.ch/phpBB2/viewtopic.php?t=3410&highlight=&sid=1ebcefbe4cd58f4bbc695fd3c2d36a4c
>
> Besides not using ROOT, it seems that you have never used R with
> large amounts of data. Due to severe memory management problems
> of R most users of Bioconductor, a bioinformatics package of R,
> which I use almost daily, complain in the Bioconductor mailing
> list all the time, that they cannot analyse their data due to the
> memory problems of R!
> These problems of S-Plus, which I used at that time, and now of R
> were the reasons that I was looking for an alternative, and luckily
> I found ROOT, which perfectly fitted my requirements, and I am NOT
> working in the HEP community.

Yes, since writing that I have become aware of R's deficiencies on large data sets. I have no particular complaint about ROOT's efficiency --- largely because it has not been an issue for me --- the user interface, be that CINT, class structure or GUI are my primary concerns. I find it hard to use ROOT as a reliable component in a well-engineered application, because many of the design idioms in ROOT data classes seem designed for the convenience of the ROOT GUI rather than a user who only wants to use a select few classes.

> You are confused whether ROOT is a file format, a stats analyis
> system or what. The same could be said about Apple´s HyperCard.
> Even Apple itself did not understand the power of HyperCard, but
> most users loved it. The same can be said about ROOT.

I'm aware that ROOT has many users, but in my experience most do not love it. I mostly hear complaints, exasperation and desire for alternatives from people I work(ed) with who *have* to use ROOT due to experiment rules or similar. In connection with my critique Web page I've had many contact "fan" emails from people I don't know who express the same views. I've also discussed many of the issues I've raised with prominent C++ and OO specialists in the HEP field and the majority have agreed with me and personally choose to avoid ROOT as a result.

You are lucky if these issues haven't affected you... as a result, presumably you also won't be offended if others campaign to get them fixed?

> P.S.: Someone not using ROOT should not write an article on ROOT
> in Wikpedia!

I *did* use ROOT, more than I would have liked to. Between 2001 and 2005 I spent much of my time using ROOT and frantically looking around for an alternative that didn't have so many problems. Along the way, I wrote the several Web pages that have been referenced here and found several tools which (to my mind) are superior. I added the criticisms to the Wikipedia article recently, while I was writing a graduate lecture course on data analysis and briefly using ROOT again.

Active ROOT users are more than welcome to correct the article where required. Feel free to add criticism to the SciPy, NumPy, AIDA, JAS and HippoDraw pages as well, if you feel that they have design flaws that deserve comment. I don't have anything to say on that, so they are happily untainted by my criticism.

> P.P.S.: You are free to comment on my comments but do not expect
> me to answer your comments since I do not have time to waste.

I also don't have the time to write this, but as I seem to have touched a nerve and analysis system design is an ongoing concern for me, I've taken some time to author these replies. I am skeptical about my (or anyone else's ability) to change the direction of ROOT's evolution, but if users are more aware of both the problems and the alternatives then the field cannot help but benefit. These emails, in addition to the Wikipedia pages and my own Web pages, are now archived for future reference, if anyone is so inclined to find them.

Andy

[*] At least, not in an engineering sense: the reasons for Linux market share are more complex.
[**] Statistic from Paul Kunz re. comparison of HippoDraw+numarray vs. CINT for loops. Received on Fri Jun 30 2006 - 08:49:52 MEST