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

[Jeffrey.J.Hallman@frb.gov]

Walter Johnston <walterj at ureach.com> wrote on 10/20/2005 12:21:09 PM:

> 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).

I agree with you here, and that is the reason why I disagree somewhat with
your second point.  If you have C code that implements statistical
algorithms and/or structures, and you want to use it in Smalltalk, it is
usually a good idea to write wrapper classes that put an object-oriented
face on the procedural code.  This is particularly true if you hope to
reuse the code.  You want to make the interface look and feel like
Smalltalk to reduce the cognitive dissonance of whoever is using the
wrapped code.  But as an experienced Smalltalker, I'm sure you already know
this.

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

A couple of my VisualWorks apps communicate via sockets with R.  I am
sending the code to Walter via private email.  If anyone else wants it,
just ask.

Jeff