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

Hi, i think the opposite is true!
The vantage on interpretation over compilation is not that compile is slow. Compiling time is already <http://www.diccionarios.com/consultas.php#> negligible in comparison with search for bugs and developing code.
The problem is in the process of developing software, and the problem of compiling code
is that in compilation time you can't take decisions depending on the state of the system.
The compiled languages are not good for many tasks because are not an intuitive form
for the human mind to thing in the process compile-execution. The difference between static and dynamic allocation is an example for this: In interpreted languages generally (cint is an exception) there is no difference between this two methods because all the memory is allocated in the moment anyway. But the people thinks in interpreted
form when programs and many time can't adapt to the concept the the memory and types of
object have to be known before the compilation. Really we work in "interpreted form" when we interchange information: when we share
a kitchen recipe we think that it is "interpreted" by the other person speak to that person not
to explain how to build a machine to do the recipe, but directly saying how to do the recipe!
The future is really in interpreted languages. The only need for a compiled language today is for algorithms where the time to develop it
is many times less than the time that this algorithm will be running. Very simple logic but with a need for a veeeeery fast execution: simulations, data adquisition,
but surely not high level data analisis, were the more time is used by human mind to "process" and
interpret results, not to draw an histogram or make a fit. Interpreted an compiled languages have a very different syntax because its different interpretation
of the problem.
Many projects tried to interpret compiled languages and compile interpreted language but but none
of them had a big success, and in the future the gap will be larger.

Bye to all.

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
>
>
>
>
>
Received on Wed Jul 05 2006 - 14:17:46 MEST