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

Hi Valeri (both of you ;-) )!

Thanks for your replies. It was not my intention to argue for the replacement of CINT as a central ROOT component. Thanks for your concise portrayal of the heavy duty work CINT is doing at the core of ROOT. Let me comment on some other points, though.

I appreciate point 3 made below, especially in view of the response given by Valeri Onuchin: for the end user the interface defines the efficiency with which he uses the software package. During long years of intensive work with computers I've learned to always look for the best tool suited for the job, since CPU cycles are cheap while human brain cycles cost heavily. Why re-invent a possibly flawed own solution where a perfect one does exist already? Just to keep this sentence on the right scope I'll mention as example that I do all automatic text processing with Perl since it definitely is _the_ tool optimized for the job (okay, awk might do for simple stuff). This means that increased processor speed will never deprecate interpreted languages which offer unique constructs to solve certain problems very efficiently. Or, to rephrase it:

"There is no silver bullet."

Applying this to ROOT leads me to my earlier conclusion, that the primary interface for end users should not require mastery of the quite complex C++ language but instead use something better adopted to scripting, since scripting is the job that needs to be done by the user. Of course anybody who knows C++ sufficiently well would at some point use CINT/ACLiC. While the PyROOT interface exists and is also documented in the User's Guide, it is not well represented on this mailing list and e.g. in the Tutorials section of the website. I understand that the core ROOT team has their hands full with developing and supporting the C++ code and interface, and I'm unfortunately not in the position to work on that either, so consider this simply wishful thinking.

The situation is quite similar with the design issues which have started this thread. I fully agree with Valeri Fine that my suggestion for improvement of the user interface does not solve any "internal ROOT problems". After discussions with Jan, whom I wrongly included in my general statement in the last mail, I have come to see that the people who actually do the development work seem to get it done quite well in the style they prefer. While I may not like certain design decisions which caused me troubles, the ROOT team is not paid to my life easier; that would again be wishful thinking ;-)

On 5 Jul 2006, at 10:15, Valeri Onuchin wrote:

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

Ciao,

                     Roland

--
TU Muenchen, Physik-Department E18, James-Franck-Str., 85748 Garching
Telefon 089/289-12575; Telefax 089/289-12570
--
CERN office: 892-1-D23 phone: +41 22 7676540 mobile: +41 76 487 4482
--
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.
	-Doug Gwyn
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w--- M 
+ !V Y+
PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++>++++ h---- y+++
------END GEEK CODE BLOCK------










application/pgp-signature attachment: This is a digitally signed message part