[R] The hidden costs of GPL software?

[Pfaff, Bernhard]

Dear list member,

this thread as well as the first one started by Philippe about the
usefulness of a GUI is interesting and overwhelming alike. IMHO, it
wittnesses the greatness and superiority of R compared to other statistical
programming environments and programs: the core team and all people involved
with it. Everyday I am flabbergasted and amazed anew; learning new concepts,
programming tricks, statistical methods I was unfamiliar with and much much
more: kudos to all of you. Let me now toss in my two cents:

First cent: Comments about a GUI
Although I use Emacs/ESS and R batch mode mostly, a GUI is beneficial in
terms of teaching statistics and/or econometrics with R. This conclusion
draws upon experience nine years back, while I was giving, beside
econometric classes, computer labs at university. At that time we had only
commercial products at hand: RATS, GAUSS and EViews. From a students
perspective EViews (menu-driven) was the most convenient one. The
econometric method comprehension and the interpretation of its application
is of utmost importance. Hence, novices should concentrate on this to
familiarise themselves with the subject. Most of the students got scared and
distracted by learning a command driven programming language too, i.e. this
was too much to swallow at one time. With other words: do not challenge
novices to statistics/econometrics programmatically. A point mentioned by
Phillipe in an earlier email too. 
Now given Rcmdr: I like its flexibility and that everybody can tailormade
his own `version' by adding new menus and functionalities. So to speak, a
very decent ground work has been provided by John Fox and I appreciate it
alot. I can only speak for myself: I am currently writing an `urca' add-in
to Rcmdr, such that the package is more amenable to novice users in a
computer lab for example; that is: they do not have to worry about the
correct syntax or what can be achieved with which function. In order to do
so, two files are needed: one is an addendum to the menu's file and the
other one contains the R functions to be executed within Rcmdr. It is at the
leisure of the instructure to include these into Rcmdr. They can be shipped
in the package's /inst directory, for example. This seems to be a feasible
approach for other package maintainers working in different fields too. Or
would such an approach be to simple?

Second cent: help system
As voiced in earlier emails in this thread the R documentation, contributed
tutorials and the likes as well as the help facilities are indeed great. The
only snag, is a lack of an `easy to find' approach to be taken. Surely there
is help.search(), apropos, help.start() etc. etc. But what would be nice,
would be something similar to `texdoctk' for LaTeX document retrieval. That
is: categorise the manuals, package manuals, vignettes and other contributed
docs with respect to the catergory they belong to. Well, the snag is: who
does this labour intensive work? Hm, I am sceptic, but it might turn out
that this is not a feasible approach to be taken, but maybe my second
suggestion is: making greater use of \concepts and/or \keyword by providing
a file for download on CRAN that contains the \concepts entries & the
function & the package in which it is contained. One could then download
this file and execute a `zgrep' on it, as could be done likewise with a
contents file from an apt repository to find out which file is contained in
which rpm. The advantage would be the decentralisation of the work. It does
not take that long when each package maintainer utilises \concepts in his
.Rd files. Once, a package is contributed to CRAN, one could scan the
tarballs and extract the relevant information into the above mentioned file.
Another advantage would be, that users would find functions of packages that
are currently not in their search path, because the packages have not been
installed. And not a few questions on this list are answered by: `This
functionality is contained in package xyz'. Anyway, I will introduce
\concepts within the next release of `urca'.

Best Regards,
Bernhard   

> 
> "Philippe Grosjean" <phgrosjean at sciviews.org> writes:
> 
> > Peter,
> > 
> > You don't need the ActiveState Tcl distribution to add 
> extensions. If you
> > compile extensions yourself (and these extensions have a compatible
> > license), then you have no problems... (well, almost! You 
> must make sure
> > those extensions compile correctly on all supproted 
> platforms). This is
> > exactly what I do in the tcltk2 package.
> > Best,
> > 
> > Philippe Grosjean 
> 
> I know, it's just that it feels silly that we cannot build on the fine
> work of ActiveState.
> 
> -- 
>    O__  ---- Peter Dalgaard             Blegdamsvej 3  
>   c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
>  (*) \(*) -- University of Copenhagen   Denmark      Ph: 
> (+45) 35327918
> ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)             FAX: 
> (+45) 35327907
> 
> ______________________________________________
> R-help at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide! 
http://www.R-project.org/posting-guide.html


--------------------------------------------------------------------------------
The information contained herein is confidential and is inte...{{dropped}}