R devel - Oct 2005 - [R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)

>>>>> "K" == Kasper Daniel Hansen <khansen at
stat.Berkeley.EDU> writes:
  K> On Oct 19, 2005, at 3:43 PM, Jeffrey J. Hallman wrote:

  K> <SNIP>

  >> Think about it.  Once you have a basic math package that can handle  
  >> matrix
  >> programming and various mathematical functions, building the various
  >> statistical modeling tools on top of them is not that hard.  What  
  >> makes S and
  >> R so much better than SAS is their programmability.  Smalltalk is  
  >> like that,
  >> only better.
  >> 
  >> 
  >> Jeff Hallman

  K> I would claim that this quote kind of shows that you have no idea  
  K> what you are talking about regarding good, debugged and trustworthy  
  K> statistical procedures. Why do you think people are actually using R?

Kasper, a few minutes spent Googling my name should disabuse you of the notion
that I have no idea of what I'm talking about.  But to answer your question:
I think people are using R because it's readily available, with a lot of
good
stuff already built in.  

I am not suggesting that you tell undergraduate statistics students to write
everything in Smalltalk, since the class libraries to support statistical
programming in Smalltalk do not exist yet.  What I am saying is that if you
compare the languages themselves, along with their programming environments,
Smalltalk is superior to R.  What it lacks are class libraries implementing
statistical procedures.  I do maintain that those really are not that hard,
once you have the matrix and math libraries.  My experience with S and R goes
way back to the days of blue book S version 3.  S called out to C code to
handle matrix and mathmetical stuff, but used S code itself to glue it all
together in a somewhat object-oriented way. 

  K> I could say "well, given an environment that could interface to C,
  K> building a GUI on top of that is not really that hard", but that  
  K> would be incredible naive as well.

Indeed it would be.  But statistical programming is easier than that.


Jeff

A couple of non-flame comments and a question -

(1) I have used Smalltalk in various forms and recommend it
highly as an environment (try Squeak for a free implementation);
it is the origin of the model-view-controller paradigm for
interaction with a GUI. Tcl/Tk is also nice with its
event-driven model.

(2) DON'T keep re-implementing the same statistical algorithms
all over the place! Putting together software that can be
trusted is non-trivial - if you want to add to the available
resources I applaud you for it, but ADDing is not simply
translating to another language (though, if the "old" language
is no longer available or supported there are good reasons to do
so. :-) I use a package to accomplish something and I need to
trust the output from that package. I don't look for a "swiss
army knife" but rather a package that does what I need and does
it well (though I prefer packages that have more functionality).

(3) I like R because of the model which returns results in
"objects" (though, as a Smalltalker, I don't see much OO in the
language - maybe I missed something).

(4) AI seemed to make more demonstrable progress when they
started separting the reasoning mechanism from the rules and
data (as in the old "expert systems").

And the question:

Is there a "simple" way (e.g. some socket based mechanism) to
feed commands into R and retrieve the results of those commands?
 This would require that I program the sequence of commands I
want to use (or a means to generate them) and then be able parse
the resulting structure - I understand. But it would also allow
separation of the computation, the "statistical reasoning", and
the UI into (potentially) separate units which would not even
need to be on the same machine to inter-operate.  If there is a
reasonable way to do this, please tell me.

Thanks.

Walter Johnston



---- On Wed, 19 Oct 2005, Jeffrey J. Hallman (m1jjh00 at frb.gov)
wrote:
> If you're looking for a GUI toolkit that:
> 
>    1.  Is cross-platform,
>    2.  Has a good collection of widgets that look good on all
platforms, and
>    3.  Is easy to work with from R
> 
> then it is hopeless.  There is no such toolkit.
> 
> As one poster mentioned, most of the better GUI toolkits are
very
> object-oriented, because that paradigm is a good fit for GUI
programming. 
> There are a few programming environments out there that do
have nice GUI
> abilities, but they all use base languages that are not very
R-like, and so
> the potential R GUI programmer is faced with having to use two
very different
> languages for his creation.  And even if that obstacle is
surmounted, there
> remains the difficulty of trying to package up his work in
such a way as to
> make it easily installed by others.  Things are always
breaking in the
> interfaces between R and whatever you're using.  Trying to
keep it all running
> and packaging it for deployment are thankless, gargantuan
tasks.
> 
> There is a better way, and that is to give up on R.  Start
over with
> a better programming environment, one that is object oriented,
as flexible and
> dynamic as R, is cross platform, easy to program in, and has
decent GUI
> facilities already.  Then port the stuff in R that does
statistical
> programming, and you have the best of all worlds. 
> 
> The environment I am thinking about is VisualWorks Smalltalk,
which is free
> for noncommercial use.  As a language, Smalltalk is both
simpler and more 
> powerful than R, and the VM it runs on is much faster than the
R interpreter.
> It has superior garbage collection and the best IDE in the
business.
> Callouts to C are just as easy as they are in R, but would
likely not be
> needed as often due to the faster VM and much better
programming facilities.
> Interfaces to various databases are possible, and the most
powerful web
> toolkit (Seaside) is written in Smalltalk and runs under
VisualWorks.
> 
> There are a couple of other Smalltalk environments around that
could also be
> considered.  Squeak is an open source cross-platform Smalltalk
that is not as
> fast as VisualWorks, but still must faster and more robust
than the R
> interpreter.  Smalltalk/X is another possibility, though it
works only on
> Windows and Unix. 
> 
> Think about it.  Once you have a basic math package that can
handle matrix
> programming and various mathematical functions, building the
various
> statistical modeling tools on top of them is not that hard. 
What makes S and
> R so much better than SAS is their programmability.  Smalltalk
is like that,
> only better.
> 
> 
> Jeff Hallman
> 
> _______________________________________________
> R-SIG-GUI mailing list
> R-SIG-GUI at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-gui
> 
>

> Is there a "simple" way (e.g. some socket based mechanism) to
> feed commands into R and retrieve the results of those commands?
> This would require that I program the sequence of commands I
> want to use (or a means to generate them) and then be able parse
> the resulting structure - I understand. But it would also allow
> separation of the computation, the "statistical reasoning", and
> the UI into (potentially) separate units which would not even
> need to be on the same machine to inter-operate.  If there is a
> reasonable way to do this, please tell me.
You're roughly describing, how things are done in rkward 
(http://rkward.sourceforge.net). R and GUI do not run on different machines, 
not even in different processes. They run in separate threads, however, and 
there's a high level of separation between the two. There are probably 
similar implementations, which can be reused more easily in new projects. 
However, if you want to have a look at one possible way to do it, this 
documentation may be useful to you:

Usage perspective/overview:
http://rkward.sourceforge.net/development/en/documentation/api/UsingTheInterfaceToR.html

Main low level interface:
http://rkward.sourceforge.net/development/en/documentation/api/classREmbedInternal.html

Regards
Thomas Friedrichsmeier