[R-gui] The hidden costs of GPL software?

[Duncan Murdoch]

On Wed, 17 Nov 2004 21:40:35 -0500, Zed Shaw <zedshaw at zedshaw.com>
wrote :

>I used to work on a GUI for R, but found that continuing was impossible
>for me.  Part of this was personal, but part was also related to how the
>R community thinks of GUIs.  In general I found that the R community was
>not that interested, and many people were violently opposed to a usable
>GUI.  In the end I felt that my time would be better spent on something
>that would actually be appreciated, rather than ridiculed as useless.

Building a nice GUI is definitely a lot of work, and not everyone will
appreciate it.  But the same can be said about just about any other
aspect of R.  You should go ahead with it if you like doing that sort
of thing, or have a need for it:  and expect that some people will
like your work, some won't, some will claim that their system is
better, etc.

>Having said that, I really would like to give this advice to people
>trying to solve the "R needs a GUI" problem:
>
>*  One half of R is already a GUI.  If it's not, then why are there so
>many plotting functions?

Yes, there is definitely graphical output, and some limited graphical
input.

>*  R is also a programming language.  All this talk about CLI vs GUI
>completely ignores this fact.
>*  There are incredibly fantastic GUIs for many other programming
>languages available.  Take a look at Eclipse for Java as a great example
>of how to create a platform for a language and not get in the way of the
>language.

I've never used Eclipse.  The example I'd cite would be Delphi, and I
know there are others.

>*  Rather than focusing on this false "CLI vs. GUI" dichotomy, maybe
>someone should sit down with users and analyze how they actually use the
>system.  I assume that the folks on the R list would be pretty good at
>analyzing user behavior.  These same people should also be good at
>researching language usability.

I'm not sure of that.  Being able to assess usability and user
behaviour is a pretty specialized task.  There are probably some folks
who can do that, but not very many.

>*  I believe that you actually can have both CLI and GUI living hapily,
>but only after the "programming language", "data management", and
>"plotting" parts are componentized and separated.

The plotting part is already separated:  there is a defined binary
interface to the graphics system.

Separating the language from the data may not be a good idea:  one of
the goals of R is to allow language to be considered as data.  

>*  I found that R would need to go in one of two directions before a GUI
>is feasible:  more like a compiler, or more like a service.
>	* More like a compiler means to make R more like Python, Ruby, Perl,
>and other languages:  have a compiler, make byte code, use a VM, and
>have the UI (no matter what type) use this system.
>	* More like a service means to turn R into a separate service that is a
>"black box".  I tried this route with limited success by exposing the R
>interpreter with a CORBA wrapper.

I think both of these directions are possible.  There has already been
progress in making R look more like a compiler:  the idea of packages
with namespaces is very much along that line.

But R is also a service.  Here R is still lacking, in that the main
interface to the service is through a teletype style interface.  ESS
shows that it's possible to use this interface to put a new GUI on top
of the service, but it would be a lot easier if the interface were
done at a lower level, and if there were a clearer separation between
user interface and service.  Designing this and getting it to work is
very hard work.

Duncan Murdoch