I reproduce my contributions to the discussion bellow:
In many cases, Root doesn't do what experiments need - their philosophies are just different. In those cases, experiments can't really expect much help from Root core team. One example is the persistency: the persistency architecture of Atlas is based on transient-persistent separation. Data in files are not the same as transient objects. This should help to make both persistent and transient view more manageable and to allow for easier schema evolution. But this is not at all how Root works - Root files are just a direct dump of transient objects and its "schema evolution capabilities" are very limited. So to implement Atlas architecture, we are going against Root philosophy - which is certainly not easy. [The funny detail is that LCG Persistency Blueprint document requires persistent-transient separation too ... and the choice of Root persistency was based on that document, while Root doesn't satisfy it.] This is certainly related to the incredible fact that Root file format is completely undocumented and experiments have no control at all about its evolution. (Compare that with HDF5 :-)
It is true that Root has been for long time formally forbidden in CERN and LHC++ alternatives offered by CERN IT (Objectivity, Iris Explorer, ...) were unusable. And it is also true that Root team (very small at the beginning) has reused a heroic job in writing a very usable alternative Framework - Root - and has provided an excellent User Support (I see that as the most important source in the Root success).
When the disaster of LHC++ has been officially recognized, if was just the product which has changed (Root has replaced LHC++), but not the policy (as before, no alternatives are allowed). Root is certainly infinitely better tool that its LHC++ predecessors. [I'm really impressed (I'm serious) what Root team has reused to implement using completely inappropriate implementation language.]
Most of Root functionality is just a simplified re-implementation of things which exists elsewhere (most often in a Java world, but not only). Just to name the most obvious examples:
- Reflection exists in all languages except C/C++.
- Persistency is available elsewhere going from simple Java serialisation, through sophisticated Object-Relational tools to efficient file formats like HDF5.
- 3D graphics is much better done in OpenInventore (which is used by three out of four LHC experiments, but not supported by LCG-Root) or Java3D.
- SQL has its standard API - JDBC, which is written in Java but can be used transparently from C++.
- etc.etc.etc.
And users have to use limited re-implementation instead of the more functional original for two reasons:
- Technical: Root architecture makes it very difficult to replace one its component with a third-party alternative. We may discuss to which extent it is the fault (or intent) of the Root team and how far it is just the direct consequence of the C++ limitations.
- Political: LCG/AA doesn't allow (even talk about) any alternatives which would be in competition with Root. Examples ?:
- At the beginning of LCG/AA, it has been scheduled to set up a RTAG group to study a potential Java role. The name of the RTAG has been then change from "Java" to "future language" and RTAG has been later silently canceled.
- Proposals to present FreeHEP/JAS software in LCG have been refused.
- AIDA has been supported only with incomplete (Anaphe) implementation, its API has been modified (so it has become incompatible with other AIDA implementations), the LCG/AA/AIDA team has been reduced to a fraction of one person. All other implementations of AIDA have been refused.
- etc.etc.etc.
In several cases where other solutions have been silenced, often in a quite arrogant way. Alternative presentations are not allowed, and people have been even forced to remove their software from the repository because it didn't follow "the official party line". [And the fact that Root itself has suffered from that treatment before doesn't justify it !]
So why were Root sirens so successful ? I see several reasons for that:
- Root does everything just well enough. For almost all components, there is a better alternative (OpenInventor for 3D, Qt for GUI, HDF5 for files, Doxygen for documentation, almost all AIDA implementations for histograms,...), but there is no other place where all those things are ready-to-be-used in one package. [This is, however, very frustrating for some developers, who provide better alternatives and can't get them accepted because they "don't work well with Root" - for reasons technical or political.] After the collapse of LHC++, users were happy with just any tool which at least worked - what difference it made to have it. And Root was certainly best placed to satisfy that.
- Root is easy to install and works everywhere. User just downloads a tar file (actually not so big), untars it and it runs. With many other HEP packages, a user should go through a calvaric process of downloading gigabytes of stuff (and you never know what exactly you have to get), learning obscure management systems, setting up all environment variables and configuration files, ..., to finally find out that she has a bad luck because she is using a slightly different version of GCC or Linux kernel.
- Root is easy to use (as long as you don't want to do funny C++ tricks). Ideal for a beginner (so for most of us). Less useful, however, if you want to use real OO with Abstract Interfaces,... or advanced C++ techniques. Using third-party packages is often a problem too (but you don't need them in Root, do you ? :-).
- Root offers known look&feel - that of PAW - with bigger functionality. So the migration is (was) easy.
- Root user support is (was) excellent. The answer to any bug report / feature request usually came within minutes, the fix/implementation within hours. With all other packages, user has to wait sometimes week even to get any response at all.
[Just note that technical points - i.e. 1,2,3 - are satisfied by Java much better. Which is certainly not surprising as Root is in many respects just a naive reimplementation of Java (Java itself is implemented is C++).]
Certainly, as I have already mentioned, Java VM itself is written in C/C++ (at least the Sun implementation) so one can say that even Java applications do use C++. As a low-level language, C++ can be used to write higher level Frameworks/Languages. But it is completely unsuitable for End Users. C++ is a proto-language, it lacks many fundamental components (like reflection and memory management). Anyone writing User Framework for End Users in C++ has to finish C++ first - he has to implement all missing functionality. This is what both Java and Root teams did. By doing that, however, you are changing C++ - user doesn't use C++ any more, she uses modified C++. Java authors have done it by cleanly defining the syntax/semantics/pragmatics of the NEW language - Java. Root authors pretend to give C++ to a user, but they don't. Root both extends and restricts C++ and creates a very badly defined pseudo-language. And that is partly because Root users are not really using C++ that it is so difficult to connect Root with other C++ Frameworks (which have probably implemented missing C++ features too - in a different/incompatible way).
