R help - Sep 2000 - What happenes with R-gnome? Suggestions

Hello,

I carelessly sent this to the unfortunate Mr. Johnson, rather than to
the list, so I'm sending it on to the list.  Re-reading it after a
couple days, I think that it might still be worth sharing.

I think I agree with an earlier reply:  GUI's are confining, and
eventually slow you down, relative to programming.  The strong point of
a GUI is that it lets you quickly, easily do a new task the first time. 
You don't have to look in a manual to see what is available, all the
choices the programmer has imagined are there on the menu.  If you want
something that the programmer hasn't imagined, you're out of luck, even
if it should be possible.  Worst of all, when you're done with the first
graph, you haven't improved your ability to generate the next.  I
suggest that if you want to sit down in front of the computer and whip
out a couple of graphs, and walk away forever ( or just for a very long
time), that the scigraphica approach looks like the way to go.  If you
want to be able to painlessly generate many plots, and introduce changes
to any or all of them easily, then you will get carpal tunnel syndrome
from all the hours of pointing and clicking.

Let me give a couple of suggestions about GUI's, since they certainly do
have their place.  

First, take a look at the SAS/Analyst package.  It is a graphical front
end to most of the SAS/Stat package, which generates proper SAS code,
saves it for you, and runs it.  Once you have the (slightly messy and
hard to follow) machine generated code, you can fiddle with it to get
what you really wanted, and run it hundreds of times, and so on. This
seems the best of both worlds: we get the menu and avoid the manual for
a while at least, and we still make some progress towards actually
automating the task.  It's also a great way to get a quick kick-start
into programming SAS.  I think that Lyx and KLyx are a couple other,
perhaps better examples of this approach.  They let you enter Latex code
if you want, generate Latex code when you point and click, and make
great training wheels.

Second, some of us really DON'T LIKE GUI's.  S-Plus exists and is
wonderful (just ask their salesfolks) for those who do, and scigraphica,
and so on.  I have no objection to adding a GUI to R, and would
certainly use it from time to time.  But I'd rather see the developers
limited effort go into developing something a bit better than trellis
graphics for R, and implementing constrained optimization, and so on. 
More on that in the third point.

On this second point, there is a sub-issue: we already have a wonderful
programming environment for R: ESS.  I think that if we do implement a
GUI, it should either be integrated with emacs, or at least not make it
harder to use emacs.

Third, as mentioned above, we really need a lot of things yet in our
programming language. One thing we need (?) is something like an object
editor in ESS.  That is, it would be nice to have an environment in
which we could easily see lists of objects, see the properties of
objects, perhaps edit them, and scroll between objects, and so on.  I
saw this in one of my brief forays into S-Plus, and thought it looked
rather neat. It should make large projects more manageable. I haven't
spotted anything quite like that in ESS yet.    Finally, a really good
constrained optimization package, implementing Khun-Tucker in all its
tedium, would be a wonderful luxury for maximizing entropy and
likelihoods.

I mentioned trellis graphics above.  One thing which would be nice is
more flexible and complicated coplots. A coplot matrix which gives false
colors and or contour lines rather than scatter plots might be useful
for data mining.  Another wonderful capability would be to be able to
"paint" points in one plot, and have them painted in other plots which
you have linked to this one. Rotatable 3-D graphics, with linked plots
for painting, would be nice.  I think that XGOBI lets us do at least
sone of this, though I haven't yet looked into it.  I do know that we
can identify any point on a plot interactivly, and that's incredibly
useful.  But then it's a bear to find on the other view.

I think that if someone takes it into his head to make a GUI code
generator for R, that would be a grand thing, and I would certainly use
it.  But I don't think that that's very high on my wishlist.  I already
have SAS/Analyst, and S-Plus, and so on.  What I really look to R for is
the programming language.  Come to think of it, when I want to quickly
inspect some data, I normally do it in R, since that seems to be the
easiest way to do it, even without the GUI.

Back to the orginal point of the original post:  integrating scigraphica
might be possible, maybe.  They seem to have made provisions for
embedding python, But I think that python was intended from the start
for embedding, wasn't it?  They plan to eventually use a standard object
arcitecture (bonobo) to ease integration, and this might be a good way
for R to move too, though I don't know if bonobo is the right version. 
If you were to work corba or bonobo into R, then it could be a backend
for Koffice, or Gnumeric, or all of them.

Perhaps moving to the object model might be the most important thing to
put on the 
"blue-sky wish list".  It seems to have the most potential to make R
more widely usable in the future.  


-- 
 /\  / _  / _  ---   _   / , _  _    _
/  \/ (- / _)  / () //) / / / )_) ()/ )
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

(I'll comment on this, being the defacto and hence currently very
blameworthy lead for ESS). 
>>>>> "NT" == Nels Tomlinson <tomlinso at
purdue.edu> writes:
    NT> On this second point, there is a sub-issue: we already have a
    NT> wonderful programming environment for R: ESS.  I think that if
    NT> we do implement a GUI, it should either be integrated with
    NT> emacs, or at least not make it harder to use emacs.

That has been considered -- at least a GUI similar to the pull-down
variant that Minitab/SPSS/etc have (it wouldn't be too hard -- we
"know" the objects, etc, and note that we already have object
completion, if we had object discovery, we could actually classify
it).

    NT> Third, as mentioned above, we really need a lot of things yet
    NT> in our programming language. One thing we need (?) is
    NT> something like an object editor in ESS.  That is, it would be

Some of this is in the distant future plans.  We have reached the
point that we really need some work on the general IDE capabilities
(if you've used JDE for programming Java, you slowly realize just how
powerful Emacs really could be for statistical analysis...).

Some issues that might help include speedbar and imenu support (which
exists in various forms but isn't included) and templates (which I'm
not convinced are efficient).  Imenu/speedbar support would provide
object-browser capabilities, which if done well (I've got ideas :-(),
would be better than what S-PLUS 2k currently has, IF you follow a
prescribed environment for development (and that "IF" is really a
hard and fast "IFF").

On a separate tact -- GNOME is cool; it's one of the few desktops I've
enjoyed using recently, but I'm very leery of R-GNOME.  The big issue
really is cross-platform compatibility, and most of the decent Unix
GUI APIs aren't easily cross-platform, sigh... (and yes, and being a
major unix bigot, it's the painful truth).

best,
-tony

-- 
A.J. Rossini				Rsrch. Asst. Prof. of Biostatistics
BlindGlobe Networks (home/default)	rossini at blindglobe.net	
UW Biostat/Center for AIDS Research	rossini at biostat.washington.edu	
FHCRC/SCHARP/HIV Vaccine Trials Net	rossini at scharp.org

CFAR:   M/F: 206-731-3647 (fax=3694) | Email is far better than phone
FHCRC: Tu/W: 206-667-7025 (fax=4812) | Voicemail is pretty sketchy
UW:      Th: 206-543-1044 (fax=3286) | Change last 4 digits of phone for fax
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

On Fri, 1 Sep 2000, Nels Tomlinson wrote:
> Second, some of us really DON'T LIKE GUI's.  S-Plus exists and is
> wonderful (just ask their salesfolks) for those who do, and scigraphica,
> and so on.  I have no objection to adding a GUI to R, and would
> certainly use it from time to time.  But I'd rather see the developers
> limited effort go into developing something a bit better than trellis
> graphics for R, and implementing constrained optimization, and so on. 
Eh?  One of us spent quite a lot of time on optim, which includes
bounds-constrained optimization, so this is a bit peeving.
> Finally, a really good
> constrained optimization package, implementing Khun-Tucker in all its
> tedium, would be a wonderful luxury for maximizing entropy and
> likelihoods.
We would welcome the submission from you of an R package to do that.
I don't know of any code in any language that does that in its full
glory (or even how to specify it algorithmically), and do know of
important special cases that underlie very expensive commercial packages.


There is a tendency in this thread to assume that R has an (unpaid)
workforce, `the developers'.  It's not like that.  Many things get into
R
because R-core members have a need of them (including for teaching) or
sometimes as an intellectual challenge. On the other hand, R is `the result
of a collaborative effort', and the core developers also appreciate using
the fruits of the contributions of others.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

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