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

[(Ted Harding)]

On 17-Nov-04 Philippe Grosjean wrote:
> Hello,
> 
> In the latest 'Scientific Computing World' magazine
> (issue 78, p. 22), there is a review on free statistical
> software by Felix Grant ("doesn't have to pay good money
> to obtain good statistics software"). As far as I know,
> this is the first time that R is even mentioned in this
> magazine, given that it usually discuss commercial products.

Hi Philippe,
Thanks for a most interesting post on this question. Further
comments below. Felix Grant's article is excellent, and well
balanced.

> In this article, the analysis of R is interesting. It is
> admitted that R is a great software with lots of potentials,
> but: "All in all, R was a good lesson in the price that may
> have to be paid for free software: I spent many hours
> relearning some quite basic things taken for granted in the
> commercial package." Those basic things are releated with
> data import, obtention of basic plots, etc... with a claim
> for a missing more intuitive GUI in order to smooth a little
> bit the learning curve.

It would better represent the balanced view of the article
to further quote:

  "In fact, the whole file menu in R looks either elegantly
   uncluttered of frightenly obscure, depending on your point
   of view."

  "It [the effort of learning] is the price paid, just as the
   dollars or euros for a commercial package would be. For
   that price, I've learned a great deal -- and nor only
   about R. And I shall remember it when I next have to find
   a heavyweight solution for a big problem presented by a
   small charitable client with an invisible budget. It's a
   huge, awe-inspiring package -- easier to perceive as such
   because the power is not hidden beneath a cosmetic veneer."

This last remark is, in my view, particularly significant.
See below.

> There are several R GUI projects ongoing, but these are
> progressing very slowly. The main reason is, I believe,
> that a relatively low number of programmers working on R
> are interested by this field. Most people wanting such a
> GUI are basic user that do not (cannot) contribute... 
> And if they eventually become more knowledgeable, they
> tend to have other interests.
> 
> So, is this analysis correct: are there hidden costs for
> free software like R in the time required to learn it?
> At least currently, for the people I know (biologists,
> ecologists, oceanographers, ...), this is perfectly true.
> This is even an insurmountable barrier for many of them
> I know, and they have given up (they come back to Statistica,
> Systat, or S-PLUS using exclusively functions they can
> reach through menus/dialog boxes).

Non-GUI vs GUI is not intrinsically linked to Free Software
as such. There are well-known FS programs which are essentially
GUI-based -- as an easy example, consider all the FS Web
Browsers such as Netscape, Mozilla, ... . If you want the
graphics experiences offered by the Web, you're in a graphics
screen anyway, and so it may as well be programmed around
a GUI. Others, such as OpenOffice, have deliberately built
on a GUI approach in order to emulate The Other Thing.

There are a lot of FS programs which offer a GUI, usually
somewhat on the basic side, which nonetheless encapsulates
the entire functionality of the program and saves the user
the task of composing a possibly complex command-line or
even a script.

The comment "hidden beneath a cosmetic veneer" is, in my
view, somewhat directly linked to commercial software.
If you sell software, you want a big market. So you want
to include the people who will never learn how to work
software from a command line; and the sweeter the taste of
the eye candy, the more such people will feel enjoyment
in using the software. The fact that their usage is limited
to what has been pre-programmed into the menus is not going
to affect many such people, since typically their useage
is limited to a very small subset of what is in fact possible.
This in turn leads, of course, to the phenomenon of
"software-driven analysis", where people only do what the
GUI allows (or, more precisely, easily allows); and this
leads on in turn to a culture in which people tend to believe
that Statistics is what they can do with a particular
software package.

S-Plus does its best to compromise: as well as GUI access
to a pretty wide range of functions, there is the Command
Line Window where the user can explicitly type in commands.
(I dare say many R users, in S-Plus, may tend to work in
the latter since they are already used to it.) But, as always
in a GUI, one can tend to get lost in the ramifications.
Also, things like the big arrays of tiny icons you get when
you click on the "2D Plots" or "3D Plots" buttons in the
S-Plus toolbar can be trying on the eyes and time-consuming
to pick through.

> Of course, the solution is to have a decent GUI for R,
> but this is a lot of work, and I wonder if the intrinsic
> mechanism of GPL is not working against such a development
> (leading to a very low pool of programmers actively involved
> in the elaboration of such a GUI, in comparison to the very
> large pool of competent developers working on R itself).
> 
> Do not misunderstand me: I don't give up with my GUI project,
> I am just wondering if there is a general, ineluctable
> mechanism that leads to the current R / R GUI situation as
> it stands,... and consequently to a "general rule" that
> there are indeed most of the time "hidden costs" in free
> software, due to the larger time required to learn it.
> I am sure there are counter-examples, however, my feeling
> is that, for Linux, Apache, etc... the GUI (if there is one)
> is often a way back in comparison to the potentials in
> the software, leading to a steep learning curve in order to
> use all these features.

Often, I think, in the Free Software world, people get involved
because they want to produce something which achieves a task.
Once they have a program which does that, then their aim is
satisfied. The GUI, in many cases, would be additional work
which would add nothing to what the software can do in terms
of tasks to be achieved. So in such cases, yes, I would tend
to agree that there is an intrinsic mechanism that discourages
work on a GUI for its own sake. You can add to that the fact
that once a developer has got to the point of creating such
software, successful in the tasks, they may have got beyond
the point at which they can readily sympathise with users who
have not acquired such skills: they no longer perceive, from
their own experience, that there is a problem.

However, this leaves people like you, having colleagues who
"come back to Statistica, Systat, or S-PLUS using exclusively
functions they can reach through menus/dialog boxes." By this
experience, you are aware of the problem, and rightly feel
that they would be helped by having access to the sort of
GUI/Menu interface that they are used to using.

One genuine benefit that the GUI offers, especially to
beginners with a particular software package, is that the
resources of the software can perhaps more easily and rapidly
be explored through the GUI, rather than searching laboriously
through the documentation of functions, extra packages, and
so on. This means that they more readily come to perceive
what is available though of course this is limited to what
the GUI will show them. But a good "Help" window can break
that barrier.

Perhaps R itself is less helpful than it might be in this
respect. The R-help list bristles with queries of the form
"How can I do X?", which I think is evidence of a problem.
While some of these queries clearly originate from people
who have taken no trouble to explore readily accessible
information, many others can not be so easily dismissed.

If you know something about what you're after, once you
realise that a judiciously formulated "help.search" can
throw up a lot of possibilities you are well on your way.
So, for instance (as in a recent query about 2-D Fourier
transform for spatial data) 'help.search("fourier")' gives
relevant information.

This, though, still fails for information in packages which
you have not installed. Perhaps I'm about to reveal my own
culpable ignorance here, but I'm not aware of a "full R info"
package which would be installed as part of R-base, being
a database of info about R-base itself and also every current
additional package, such that a "help.search" would show
all resources -- including those not installed -- which
match a query (and flag the non-installed ones as such so
that the user knows what to install for a particular purpose).

Whether this needs to be supplemented by a GUI is a point
that could be discussed from several points of view.
Philippe's biological/oceanographic users no doubt would
be considerably helped, provided they can in due course
come to the point where they can start to work "beyond
the GUI" (if indeed they need to).

Personally, however, I find that GUI work is slower and
more error-prone than command-line work. Swanning the
mouse around the screen, visually idebtifying icons and
buttons, clicking on this and that in order to see whether
it's what you want, and so on, is much more time-consuming
than typiing in a command.
And God help you if you accidentally click on something
destructive!

I'll close with an immortal quotation (from Charles Curran,
of the UK Unix Users Group):

  "I can touch-type, but I can't touch-mouse"

Best wishes to all,
Ted.

> I would be interested by your impressions and ideas on this topic.
> 
> Best regards,
> 
> Philippe Grosjean  
> 
> ..............................................<°}))><........

                                                   /\
                                                 /   |
  .............................<°}))><........  :)    >=---
                                                 \   |
                                                   \/

Best wishes to all,
Ted.


--------------------------------------------------------------------
E-Mail: (Ted Harding) <Ted.Harding at nessie.mcc.ac.uk>
Fax-to-email: +44 (0)870 094 0861  [NB: New number!]
Date: 17-Nov-04                                       Time: 12:34:31
------------------------------ XFMail ------------------------------