Skip to content

The hidden costs of GPL software?

37 messages · Philippe GROSJEAN, Jan P. Smit, (Ted Harding) +17 more

Messages 26–37 of 37

#
Dear list members,

This has been a stimulating discussion, now spread over three lists.
Although I'd like to address issues that have been raised on all three
lists, I expect that more or less everyone reads r-help, so I'm just posting
these comments there.

(1) As everyone else, I've had experience with a number of other statistical
packages and programming environments in addition to R (including, more
years ago than I care to say, the mainframe predecessor of the MicrOsiris
package mentioned positively in the SCW article cited by Philippe in his
original message). I don't believe that extensive point-and-click GUIs for
broad statistical packages/programming environments such as Stata, R,
S-PLUS, or SAS are very helpful: They tend to be labyrinths that are
difficult to navigate. Some of the suggestions for other kinds of GUIs
(e.g., aids to command specification) seem to me more promising. Moreover, I
don't think that one should expect to learn an extensive system such as R or
SAS without doing some reading. My own experience is that S (i.e.,
encompassing R and S-PLUS) is easier, not harder, to learn than its true
competitors. 

(2) On the other hand, one can build quite nice graphical interfaces to more
limited packages. A couple of examples that I particularly like are SAS JMP
and Cook's and Weisberg's Arc (built on Lisp-Stat).

(3) Similarly, my Rcmdr package was meant to be a limited-purpose GUI,
useful for basic-statistics classes. Its range has grown somewhat to cover
linear and generalized-linear models, and I plan a few more modest
extensions (including the ability to incorporate other classes of
statistical models more easily). As a technical matter, I don't think that
it would be hard (although it would be time-consuming) to produce a much
broader extension, but the result (in my opinion) would be as dubiously
useful as the GUIs for SAS or S-PLUS. By the way, if there were something I
could wish for here it would be a slightly broader set of Tk widgets to be
included with the Tcl/Tk that installs with R for Windows, since using
widgets outside of this set creates installation obstacles for lower-level
users.

(4) Several people have pointed once more to the difficulty that novice
users experience in locating functions to perform particular tasks or in
figuring out how to use them once found. I suspect that even people who have
been using R for a while occasionally have a brain-cramp that leads to a
search through documentation. I know that I do. In my experience, the
various facilities for searching documentation in R work pretty well. 

(5) I think that examples in help files and vignettes can be useful, but are
not substitutes for text-books, manuals, and journal articles. It certainly
should not be the job of statistical software to teach the statistics,
although of course it can be used to help do that. I doubt that many list
members would look favourably on the statistical-methods "decision tree" in
MicrOsiris, for example. One solution is to include PDF "manuals" with
packages. I've done this, for example, with my effects and Rcmdr packages.
The introductory manual supplied with Thomas Lumley's survey package is
another, similar example. Maybe there's a better way of integrating such
non-vignette manuals with the help system -- something like
help(manual=package).

(6) As has been pointed out, e.g., by Duncan Murdoch, solving the
function-locating problem is best done by a method or methods that
automatically accommodate the growing and changing set of contributed
packages on CRAN.  Why not, as previously has been proposed, replace the
current static (and, in my view, not very useful) set of keywords in R
documentation with the requirement that package authors supply their own
keywords for each documented object? I believe that this is the intent of
the concept entries in Rd files, but their use certainly is not required or
even actively encouraged. (They're just mentioned in passing in the Writing
R Extensions manual.)

--------------------------------
John Fox
Department of Sociology
McMaster University
Hamilton, Ontario
Canada L8S 4M4
905-525-9140x23604
http://socserv.mcmaster.ca/jfox
#
John Fox wrote:
Then, take a look at the tcltk2 package in the SciViews bundle (probably, in
the next version, I will take it out of the bundle). You have there tile
(themable widgets with notebook tabs, progress bar, and many more... and
very soon combo boxes and lists/trees). You have also the famous tkTable,
and a separate combobox and a tree, and a support for tooltips everywhere...
Just propose if you need more! All this runs under Windows, but I still got
problems to compile it under other platforms.
I tend to have the same opinion than John (although I thing that both a good
manual, and a better online help could be beneficial): a PDF manual is much
more readable than a wiki! Why not to propose PDF manuals in the \doc
section of CRAN which have a GNU Free Documentation License
(http://www.gnu.org/copyleft/fdl.html), so that the manual could be
progressively enhanced by many authors?

Best,

Philippe Grosjean
#
"John Fox" <jfox at mcmaster.ca> writes:
Strategically, that might actually be a valid (and valiant) design
goal! From my limited experience with Rcmdr and SAS Analyst, I'd say
that Rcmdr is almost there, just a few little niggles like not
remembering values from the last time a form was filled in.
Argh. Please stop poking at my guilty conscience.... Wrapping Tcl/Tk
extensions as R packages has been on my wish list too for some time,
with tktable as the obvious first candidate. (It's not just on
Windows; the default Unix/Linux installs of Tcl/Tk tend to be pretty
minimal too. On Windows we have this instructive twist on the BSD/GPL
debacle, that ActiveState made a very nice Tcl/Tk distribution with
all sorts of "batteries included", but we cannot bundle it with R as
they are restricting redistribution.)
#
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
#
Peter Dalgaard wrote:
Humm, in my view, this is a feature! The first time the user calls the form,
it creates the corresponding R script. If the user needs to make
corrections, or to run the analysis a second time, he is now supposed to
work with this script! By not remembering last values in a dialog box, Rcmdr
makes the script edition more obvious than recalling the dialog box
again,... even for lazy people! Otherwise, you are sure that those lazy
people will not switch to script: they will call the same dialog box again
and again.

Of course, one has to explain to the students that this is a feature.
Otherwise, it may look like a bad design, especially in comparison with
other "better designed" GUIs!

Best,

Philippe Grosjean
#
"Philippe Grosjean" <phgrosjean at sciviews.org> writes:
I know, it's just that it feels silly that we cannot build on the fine
work of ActiveState.
#
At 09:45 PM 11/18/2004, John Fox wrote:
[...]
That should prove extremely helpful.  Would it be practical to have the 
complete index installed with base R?  That would help identify useful 
packages not yet in a user's installation.
#
Dear Philippe,

I was aware of your tcltk2 package and will likely use it (if the standard
widget set distributed with R for Windows is not expanded) when it becomes
cross-platform.

Thanks for this.
 John

--------------------------------
John Fox
Department of Sociology
McMaster University
Hamilton, Ontario
Canada L8S 4M4
905-525-9140x23604
http://socserv.mcmaster.ca/jfox 
--------------------------------
#
Dear Peter,
I've thought about remembering dialog values, but I guess so far I've been
too lazy to do it or, to put a better construction on it, too distracted by
other things. It shouldn't be hard to do -- just a matter of maintaining a
data base of previous entries that are flushed when the active data set
changes. Actually, the linear-model and generalized-linear-model dialogs
already do this.

I'd be interested in the other little niggles as well.
I certainly don't want to press this issue, since I'm grateful for what
you've already done (and it's surprising how much mileage one can get from
the basic widget set). I see this as primarily a Windows problem because
users of other computing platforms (possibly with the exception of some Mac
users) tend to be more sophisticated about installing software.

Regards,
 John
#
My very dear Prof. Dalgaard:
Peter Dalgaard wrote:

            
You, of all people, should hardly have a guilty conscience about 
not doing enough on R!  I, and many others, are continually awed by the 
accomplishments of you and the rest of the R Core Team. 

      spencer graves
#
I inadvertently directed this response to the R-Gui
list this morning. To those receiving a double
receipt, I give my apologies. My intended list was the
R list.
--- Duncan Murdoch <murdoch at stats.uwo.ca> wrote:

            
...
...
[snip] [snip] [snip]
...
I guess we'll just agree to disagree. :O)
1.)The LACK of programming support? Isn't that a bit
of an overstatement? There are materials available, as
of ciurse you are aware. At one time or another many
of us may find it difficult to determine some 'key'
programming information at the moment. But you know
something, I've  had that happen using the packages
like you describe--this includes wired IDE help,
original documentation, and 3rd party books. I accept
that as a condition for using both free and commercial
software. And if the particular burden is too great,
then I don't use the product. Such is life :O)

2.)As you indicate below, R doesn't not have a VB or
VC++ style IDE. R doesn't have the development
environment of Smalltalk or the commercial LISPs
(sigh...) But, really, an IDE is a bit more than a
GUI, wouldn't you agree? A GUI is just one component
of an IDE.

Perhaps part of our difference is how we view
programming. I view it more as a form of expression
using a LANGUAGE. Like any language, e.g., English,
French, Chinese, you have to develop a degree of
fluency to express yourself. Some people are
comfortable working with a phrase book and others put
more effort in to learn to converse sans book. Both
approaches are quite legitimate in that either can get
the job done. (And both can fail miserably!)
real GUI would be nice at times even for a grump like
myself. And not having such is a cost. But in my case
that cost is not the deciding factor. The fact is, I
by preference do a lot of coding--both at the
quick/dirty scale and the project scale--in R that I
could do in C/C++, FORTRAN, BASIC. I have those tools
in commerical form with IDEs

Why R? The turn around is so fast by comparison. R/S
is language in which I can much more easily and
quickly express myself.  The development team has done
a lot of work developing my high-level language for me
:O). (Note--my second hacking language is  lisp-stat,
also an interpreted, higher functionality language.) I
don't use most of R's capabilities, and 'not knowing
that which I do not know' is not an issue. When I need
something new I am able to learn it incrementally on
top of what I already know.
...
Did I suggest banning GUIs? I don't think so. Your
world is one where there are benefit for your
clients--the students. My world is turn around and
documentation. Coding is easier to document than a
complex sequence of menu actions. Indeed I would get
laughed out of Dodge City if I documented a set of
calculations: " next I clicked ...". It's that just
different requirements lead to different needs.
...
[snip]
...
Of course that is the case, but the limitations in a
given GUI is one more thing that puts such people in
rationalized comfort-zone with their actions.
(Typically I see this with EXCEL apps--99.9% of the
people in my trade run away from statistical
software.)
More than once I have seen this occur in a senior
scientist review capacity after management has seen
the product and 'accepted' its results. Doom, doom,
doom...shoot the messenger! Oh woe, oh woe!:O(.

Best regards, Duncan
Michael
3 days later
#
FYI, just noticed that the GPL is about (="a draft of which is due next
year") to be revised into GPL v3. Maybe they will solve part of the problems
you mention. Not much substance yet, but see

 GPL 3 to Take on IP, Patents, eWeek, November 22, 2004
 http://www.eweek.com/article2/0,1759,1730102,00.asp

and the slashdot discussion

 GPL Revision Coming Soon, slashdot, November 22, 2004
 http://slashdot.org/article.pl?sid=04/11/22/1746225&tid=117

Question to Martin Maechler: Is it ok to change the subject title to, say,
"Problem with GPL (Was: RE: ...)" when replying to a message? This thread
has covered quite a wide range of topics this far.

Cheers

Henrik Bengtsson