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

Roland Kuhn wrote:
> 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------
>
>
>
>

I do believe that CPU speed improvement closes gap between being interpreted and compiled. I'm working in some big software company, and what I learned from customers is that they need some kind of metalanguage. At the best this metalanguage need to contain one instruction like
OutputData=doRightJob(InputData)
Recent success with Tcl shows it clearly. It is better to debug 10-string script than 100-line C++ program with all that overhead (inheritance, incapsulation, templates etc). And no kind of ACLiC can save the world here for ROOT. Received on Wed Jul 05 2006 - 15:51:10 MEST