[R] Re: R-1.1.0 is released : GUI

[Thomas Lumley]

On Fri, 16 Jun 2000 cstrato at EUnet.at wrote:


> My first question is:
> Since S/R is a full featured language it would be great to have a native
> compiler, so that I could write stand-alone programs which profit from the
> full speed, and ability to handle large data-sets, of a stand-alone application.
> Wouldn´t this be an option to consider?

It has been considered and a least a byte-code compiler may be done at
some time. The language is not ideal for compiling as it lets programmers
do complicated things to environments which make it hard to distinguish
local and global variables.

As the garbage collector currently takes up a non-negligible fraction of
the time it may provide an upper limit to speed even with compilation. 
 
> Related to the first question and to the GUI question is my second point:
> It would be great if I could wrap some S/R code in a GUI, so that other
> people not knowing the language could use my programs.
> Do I understand it write that the bindings to Tcl/Tk offer just this possibility?

Yes. Bindings to other GUI systems would be possible too.

> Regarding Java: I would really like to learn Java, but everytime I consider
> doing something in Java, I decide to do it in C++, since in my opinion,
> Java does not solve my two problems, speed and size of data.

It depends. Some recent benchmarks suggest that the differences in speed
may be getting less important.  Java graphics are slow under Unix, but
even this is improving.

> Now comes my last question, which I hope the R developers don´t
> misunderstand:
> Most current R developers have decided to re-implement R in Java, called
> "The Omegahat Project" (see: http://www.omegahat.org/)
> If Prof. Ripley mentions in the mail below the problems with Java/Swing,
> and if I consider the problems mentioned above:
> Why do you re-implement R in Java and consider this as ultimate solution?

The Omega project is not a reimplementation of R or S (read its web site).
It is more a framework for developing new statistical computing ideas.  
The syntax is somewhat related to S because the people involved mostly
like S, but the point is to be able to try new things that would be very
hard to do in S (eg new ways of specifying models, dynamic graphics).

> 
> In my very personal opinion it would be great to have one of the
> following two options:
> a, a native R/S compiler

As mentioned above this is harder than it looks but may be possible

> b, an implementation of the R functionality as C++ classes.

This is probably impossible. R does not look like C++ classes.  The
mathematical functions are available as a separate C library and it is
possible to embed R (at least under Windows) in other programs.  It
is/will be possible to communicate in DCOM and CORBA between R and C
programs, too. You can also code bits of your program in C or Fortran and
call it from R

As the two independent implementations of S are not terribly different in
speed it seems that R is slow because it implements the S language, which
is designed to make statistical programming easy for the user, not for the
computer. With todays computers this is a good balance for most people --
most code takes a lot longer to write than to run, and statistical
analysis costs are a small fraction of total project costs in most
cases. Java (and Tcl, Python and Perl) are popular for the same sort of
reason -- they waste computer time rather than programmer time.

We are trying to speed up R, but it's unlikely to be more than a factor of
two or so faster no matter what we come up with.


	-thomas

Thomas Lumley
Assistant Professor, Biostatistics
University of Washington, Seattle

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._