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

[Philippe Grosjean]

Thank you all (+ a couple of offline comments) on this topic.
To summarize your comments:

- "Hidden" costs, may be better called "indirect" costs are not so easy to
calculate. In the cited paper
http://www.scientific-computing.com/scwsepoct04free_statistics.html, there
is an interesting advice from a people used to test and wrote about
commercial software. Indeed, the whole context around the use of a
(statistical) software should be taken into account, which would reveil also
indirect costs for commercial packages. Indeed, it is the Total Cost of
Ownership (TCO) that should be better considered in this context.

- This discussion is connected with the many discussions pro/cons for a R
GUI, or any other tool that will facilitate use of R, but loosing one big
advantage: currently, you have to know what you are doing to get a result
with R... What kind of nonsenses would we get from naive people if they can
obtain results with no, or little knowledge?

- R is viewed by some as a statistical development platform, mainly for the
scientific community. It excels there, but, is it even desirable to get it
also used "by the mass"?

- ***Many of you claim for a better help system to find a function more
easily, than for a GUI***. I think this point is very important and should
be placed somewhere high in the "to do" list in order to make R more
accessible to beginners/occasional users!

- There is no possibility to make a commercial GUI for R (thanks to the
GPL), and volunteer R developers tend to work on a problem until they get
the solution they need... And this rarely lead to the development of a GUI
on top of it, conserning statistical analyses. In this way, yes, there is an
intrinsic mechanism that makes R a program by experts, for experts.

- A GUI could cover only the bare essentials, is rather unflexible, etc...
For all these reasons, how would it help to learn such a feature-rich
environment as R? This is not the solution to the problem.

- It is more a question of education: it takes so much time to find a
function in a menu/dialog box, than to consult help pages to find the right
function. However, some categories of people are more accustomished to click
and drag that to read help pages!

- GUIs, by providing access to a limited amount of analyses in an inflexible
way, lead to the phenomenon of "software-driven analysis" where the way data
are analyzed is dependent on the software used.

- Only commercial software care about eye candy stuffs to get clients more
happy to use their software (and thus to sell more); "hidden beneath a
cosmetic veneer" in the original paper. R does not care, because there is
nothing to sell. So, as a consequence, you face the bare power, but sorry,
no eye candy!

- GUI work is slower and more error-prone... So, this should be considered
in the hidden costs AFTER the learning stage... in favor of R!

- "User-friendly" software tend to make a lot of assumptions (to present the
analysis in an easier way), and does not tell about it. These could lead to
nonsenses in some case, and the user even don't know, precisely because
these assumptions are not explained!

- The author of the paper talks about hidden costs, but he does not talk
about hidden benefits, because he does even not notice them: ***all the bugs
that aren't in it*** (I add: transparence in code + possibility for everyone
to propose a patch = a big part of the success of Open Source software,
especially for data analysis software)!

That's all, I think, for the summary!

Otherwise:
Patrick Burns <pburns at pburns.seanet.com> wrote :
>[...]
>I think Ted Harding was on  the mark when he said that it is the help 
>system that needs enhancement.  I can imagine a system that gets the 
>user to the right function and then helps fill in the arguments; all of 
>the time pointing them towards the command line rather than away from 
>it.

Duncan Murdoch [murdoch at stats.uwo.ca] answered:
>That would be helpful, and the only really difficult part would be the
>first part:  getting the user to the right function.  help.search()
>sometimes works, but often people ask for the wrong thing.

>After that, R knows a lot about the structure of its help files, so it
>could display all of the arguments with their defaults and the help text
>that corresponds to each argument, as well as the help text for the rest
>of the help file.

>Probably the main obstacle to getting this is finding someone with the
>time and interest to do it.

Humm, excuse me, but I think that SciViews and JGR *already* do that,... So
it appears that at least two people already spend their time and got their
interest focused on this topic. Also, functions for such purposes will be
added to the R GUI API... Meaning they will be available for a wider use.
And I am close to a solution under Windows where hitting a combination of
keys in ANY program will display a function tip with arguments, or a
contextual completion list for R code.

Finally:

It seems that a GUI for R is not just lacking, it is purposedly lacking...
And there are many argument in favor of this lack. OK for most R users. But
could you, please, consider these examples:

1) I teach basic biostat with R/SciViews-R/R Commander. It is a frank
success and almost all my students install it on their computer and start
using it...
So, the next year, I teach them an advanced biostat course with R. I decide
to give up with the GUI and to present analyses like PCA, MDS, LDA,
clustering, etc... directly in R. For each analysis, I make a small script
(10 lines or so), I explain it and show them how it works and how they can
edit it to analyze other data. It is a fiasco! It seems that a psychological
barrier induced by this unfamiliar object (the script) tends to obscure
everything in the mind of my students. I got returns in this way: most of
the students that started to use R seem disgusted after this second course,
and they switch back to another software with a GUI! When I ask them, they
say: SciViews-R/R commander is nice but limited to simple analyses. For
other analyses, the R scripts are just too complex for me, so I prefer to
use a different software.

2) Second case: I write an original analysis and I want to make it widely
available for oceanographers. Most of them do not want, and will never learn
the S language. They obviously need a simple and easy GUI on top of my R
function, because they want to run the analysis without knowing all the
details...

Obviously, these are concrete examples where a GUI should be a benefit...
unless one consider that R should be restricted to experts only!

Best regards,

Philippe Grosjean

..............................................<°}))><........
 ) ) ) ) )
( ( ( ( (    Prof. Philippe Grosjean
 ) ) ) ) )
( ( ( ( (    Numerical Ecology of Aquatic Systems
 ) ) ) ) )   Mons-Hainaut University, Pentagone
( ( ( ( (    Academie Universitaire Wallonie-Bruxelles
 ) ) ) ) )   6, av du Champ de Mars, 7000 Mons, Belgium  
( ( ( ( (       
 ) ) ) ) )   phone: + 32.65.37.34.97, fax: + 32.65.37.33.12
( ( ( ( (    email: Philippe.Grosjean at umh.ac.be
 ) ) ) ) )      
( ( ( ( (    web:   http://www.umh.ac.be/~econum
 ) ) ) ) )
..............................................................