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

From: Valeri Onuchin <Valeri.Onoutchine_at_cern.ch>
Date: Wed, 5 Jul 2006 10:15:17 +0200

Hi,
I'd like to add a small comment to support Valeri's arguments for right choice of CINT instead of "other interpreted languages", in context of future perspectives.
In my opinion, many modern interpreted languages like Python, Perl, PHP etc. might dissapear in the neareast future when processor speed will be increased by a factor of 10.
 At the present, it takes few seconds to compile 100s lines of C++ script with ACLiC on an average machine. When, with having faster processors, this time will be decreased to a fraction of second - the difference between interpreted and "non-interpreted" language might dissapear. To run interpreted script, it will be passed through compilation step, and then compiled code will be executed. In this case, the winner will be a language which has a better compiler, producing the fastest, the most optimal binary code. The compiler which can provide a code running on multicore processors. At the moment (and, I think, in the nearest future) such a language is(will be) - C/C++.

Regards. Valeriy

-----Original Message-----
From: owner-roottalk_at_pcroot.cern.ch on behalf of Fine, Valeri Sent: Mon 7/3/2006 7:41 PM
To: roottalk
Subject: RE: [Fwd: Re: [ROOT] Wikipedia criticism about root]  

> > One way to improve this situation would be not to expose the C++
> > interface to the casual user, but instead recommend that people use
> > a higher level and less error prone (think object ownership)
> > interface language.

May I comment the last clause?

My point is, each experiment is free to "recommend that people use a higher level and less error prone (think object ownership)".

However, that can be done on the top of the ROOT only.

Some rationales are following:

1. CINT is the main ROOT engine. One cannot remove CINT and replace it with another engine because the CINT (C++ interpreter) is needed to provide ROOT I/O first of all for C++ codes.

No other language, no other interpreter can provide I/O for C++ programs based on the definition of the data-structure provided in form of C++ class descriptions automatically.

Any other approach would have required the invention

1. a separate "data definition language"
2. a separate "scripting language" ( "data manipulation" language)
3. etc etc etc . . .

and all above should be useful for C++ codes. Could two (at least) extra components the user may have learned in addition to the C++ language make the user's life simpler and the code more robust?

There were some arguments around Java. However, it was not Rene Brun and ROOT team to decide LHC (HEP and HENP) are to use very C++. "C++ is given" period. There is no reason to argue now whether it was for good and for bad. Anyway, there was no ROOT at the time of that decision. No "modern perfect" language can change the fact http://www.interactions.org/cms/?pid=1024296 "CERN confirms LHC start-up for 2007".

C++ I/O is the key component that no other system provides and that made ROOT success for very C++ applications. (As soon as Wikipedia article is concerned)

All above mean the "C++ scripting" is a "free bonus" of the ROOT I/O system.
Many ROOT miracles are due the internal CINT engine too. The ROOT system ability to "understand" C++ class definition automatically does allow making many (complex otherwise) things trivial. (Do not say Java can do that too. See the paragraph above. We are speaking about very C++ language. )

This means:

1. One is getting the "C++ scripting" with ROOT for "free".
2. There is nothing wrong with the idea to add some dedicated scripting language on the top of the ROOT system. However, it requires an extra (and no trivial) job someone has to pay for. It is not "free".
3. I agree, "One way to improve this situation would be not to expose the C++ interface to the casual user". Any body is free to take over such sort of the job (see Root/Python and Root/Ruby example). However, no extra language can replace CINT (C++ interpreter) as the core ROOT engine.
4. Any extra (external) scripting language may not simplify ROOT and cannot eliminate the internal ROOT problems either.
5. The best way "not to expose the C++ interface to the casual user" is to provide "experiment-wide" / "task-wide" etc GUI. In the other words in can be done on "ROOT user level".

This means lack of the non-C++ "scripting" language" is not ROOT system fault first and then ROOT does provide the Python and Ruby scripting as a part of the system. This means the Wikipedia paragraph has nothing to do with the reality:
http://en.wikipedia.org/w/index.php?title=ROOT&action=edit&section=9 "

                   CINT interpreter

An additional criticism is that the standard ROOT command line and scripting interface uses the CINT "C++ interpreter". This can be unstable and encourages programs to be written in ill-defined non-ANSI compliant C++. More fundamentally, the idea of using a complex, strongly-typed language as a primary user interface is of dubious wisdom. The Python and Ruby interfaces offer access to ROOT's behavior through more suitable and stable interpreted language"

One would appreciate the paragraph's author to remove / revise it.

Thank you.

My best regards, Valeri Fine Received on Wed Jul 05 2006 - 10:15:28 MEST