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

[Peter Dalgaard BSA]

cstrato at EUnet.at writes:

> For this reason I am currently thinking to re-write my programs in C++, since
> my program needs 2hrs in S-Plus on a 733MHz machine with 1GB RAM, and
> would take much longer in R.

er, why? Sometimes R is faster, sometimes S.

> 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 is being considered, and have been considered for quite a while.
The main problem is that R is a kind of language (known as Functional
Programming Languages) which it is difficult to write compilers for.
There are many run-time decisions (anything with generic methods for
instance) and the sys.parent() and substitute() family of facilities
are a compiler writer's nightmare...

The large data set issue is somewhat orthogonal. Some techniques have
already been developed to access databases without storing all
variables in memory (one of the R<->SQL interfaces has virtual
dataframes, e.g.).

> 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. Try it and see. Take a look at the demo codes. Speed is not among
its virtues though, since it involves two interpreted languages.

> 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.
> 
> Besides that Java is re-inventing an old technology of the seventies:
> Do you remember UCSD-Pascal, which was developed at UCSD to make
> Pascal machine-independent? It compiled Pascal code into "p-code" (also
> called pseudo-code), which in effect was a virtual machine. It did not
> succeed because it was way tooo slow. About 15 years later Sun tries to
> sell this as a new principe. Although computers are much faster now, Java
> still suffers performance problems, and I do not want to waste computer
> power, so I decided to stick with C++.

Well nowadays there's such a thing as just-in-time compilers (yes I've
been subjected to p-code on an 8MHz PC-AT...), but I don't think I
want to go into that discussion.

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

No that is not what is going on. The point of Omegahat is not to
re-implement anything. Rather to the contrary it is an attempt to get
tools and languages to interoperate. So the ability to fire up Java
classes from inside R and calling R from Java is much more in the
direction that Omegahat is moving. A lot of this stuff is experimental
in nature -- perhaps things like Swing will *become* much more viable
when standard computers have considerably more CPU and RAM than today.
Already today, however, some neat things have been coded up in Java
and would be nice to try and tap into.

> In my very personal opinion it would be great to have one of the
> following two options:
> a, a native R/S compiler
> b, an implementation of the R functionality as C++ classes.

I think you would find that the speed of a) will disappoint you
somewhat and any attempt at b) will lose a substantial part of the
functionality. R is a language of a quite different type than
the traditional compilable languages, and this carries an
expressivity/speed tradeoff by nature.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)             FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._