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.
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.
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).
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.
I would be interested by your impressions and ideas on this topic.
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
) ) ) ) )
..............................................................
> 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).I guess you are right, in that the steep initial learning curve could be smoothed for beginners. On the other hand I do not see how a GUI for R could cover more than the bare essentials because the available functionality is so vast. We also have S-Plus at our research institution and even there, I see, that people who do not know about the underlying code have difficulties in using the GUI. I personally believe that it is more a question how one is used to do statistics. Click and drag is the norm. (And I guess it is usually also the norm of how people/scientists use other Software.) In my eyes, using code instead, means that one is able to repeat the steps of an evaluation easily and to document at the same time what has been done. Very soon evaluations (and data handling) can be done far more efficiently than with click and drag. All these advantages outweigh the initial costs by several orders of magnitude. Thus, in my opinion it is more a question of education such that people might realize how they can work efficiently and cleanly. Perhaps one could even say that such an approach is more scientific because, in principal, it can be easily communicated and reproduced. It is, of course, easy for me to make these statements, as in the meantime I have been using S (S-Plus and R) for - gosh - over 10 years. But I see in some projects that I supervise that people get started easily with a snippet of code that I provide and the insight of the usefulness of such a work approach is usually easily within reach. Lorenz - Lorenz Gygax, Dr. sc. nat. Tel: +41 (0)52 368 33 84 / lorenz.gygax at fat.admin.ch Centre for proper housing of ruminants and pigs Swiss Federal Veterinary Office
Dear Phillippe, Very interesting. The URL of the article is http://www.scientific-computing.com/scwsepoct04free_statistics.html. Best regards, Jan Smit 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. > > 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. > > 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). > > 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. > > I would be interested by your impressions and ideas on this topic. > > 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 > ) ) ) ) ) > .............................................................. > > ______________________________________________ > 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 >
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 ------------------------------
Philippe Grosjean wrote:> I would be interested by your impressions and ideas on this topic.I have found that "user friendly" packages make a lot of assumptions and take a lot of decisions for the user. This makes things easy, but you do not really know what is going on, and I'd say this is a hidden cost of "commercial" software. I wrote to the list in February asking how to reproduce some results previously obtained with Statistica. It turned out that Statistica does some data manipulation without telling the user, with poor documentation and no options or choice. Do you trust results obtained this way? I don't. So I'd argue that the lack of a GUI is a good thing, because it forces the users to think a bit more about what they want to do, and gives more control on what is going on. Best, Federico Calboli -- Federico C. F. Calboli Dipartimento di Biologia Evoluzionistica Sperimentale Universit?? di Bologna Via Selmi, 3 40126 Bologna - ITALY Tel - +39 051 2094187 Fax - +39 051 2094286 f.calboli at ucl.ac.uk fcalboli at alma.unibo.it
This has been an interesting discussion. I make the following comment with hesitation, since I have neither the time nor the ability to implement it myself. Using CLI software, an infrequent user has trouble remembering the known functions needed and trouble finding new ones (especially as that user gets older). What might help is an added help facility more oriented towards tasks, rather than structured around functions or packages. Such a help facility might have a tree structure. Want help? Are you looking for information on (1) data manipulation or (2) analysis? If (1), do you want to to (3) import or export data, (4) transform data, (5) reshape data, or (6) select data? If (2), do you want to (7) fit a model or (8) make a graph? And so on.... Once appropriate function(s) are located, the user would be directed (by hyperlinks) to the existing help framework. That could help the problem of knowing what you want to do, but not what it is called. I think that "Introductory Statistics with R" is a step in that direction for the basics, as MASS is for more complex matters. The question is whether such material can be incorporated into a help system that will allow users to find, more easily, what they need. That largely depends, it seems to me, on a great deal of work by volunteers. I agree also with the suggestion that a dedicated editor (or add-in) that could supply arguments for functions might be considerable help. MHP -- Michael Prager, Ph.D. Population Dynamics Team, NMFS SE Fisheries Science Center NOAA Center for Coastal Fisheries and Habitat Research Beaufort, North Carolina 28516 http://shrimp.ccfhrb.noaa.gov/~mprager/
Hi All, GRETL, a Gnu Regression, Econometrics and Time-series Library is open-source, cross-platform, multi-language and fully GUI based. The website is http://gretl.sourceforge.net/ This is NOT a personal plug, simply posted to show what can be done. Andrew
Background: I'm a Computer Science lecturer, and I read the blue book cover to cover before ever setting finger to keyboard with R. Observation: I really only use R for very simple things, but there's practically *nothing* I've done with R since installing it could have been done via menus. I seem to need lots of little R functions, lots of little try this transformation plot that, fiddle with the other... I've had a student use it, I've introduced it to colleauges, and they would not have benefited one iota from a GUI interface. I'm glad that the effort put into R has gone into the things it has.
Hmmmm, interesting thread and minds will not be changed but regarding GUIs...I thought S (aka R) was a PROGRAMMING LANGUAGE with a statistical and numerical slant, and not a statistics application. ;O) Certainly there is an important place for GUIs but I believe that it is very much overemphasized in modern computer culture. My experience and bias--and I started in the 1960's-- is that except for 'trivial' uses, GUIs are a detriment to any reasonably complex CREATIVE computational task. They are adequate for the simple, common task. But even then, typing a command or two is not overly taxing--- particularly when compared to navigating layer upon layer of submenus as is some times needed. If I need to, I will add a little syntactical sugaring when coding and move on. GUIs encourage a passive approach to using computers when solving problems. In addition, it is regretable that a lot of people in the 'workplace' will carry out incomplete and/or incorrect quantitative work because of the real or perceived limitations of the particular (GUI) apps they are using. There is no inclination to go beyond the menu and even then many menu items gather 'electronic dust'. Finally, there are times for many of us when work 'goes home' at the end of the day. That just comes with the territory. I (and most others) can not afford the luxury of S-plus, Statistica, SPSS, etc. at home. So in a sense there is a very real 'loss of productivity' cost associated with using commercial software. Now that does bring us around to supporting R doesn't it? (Mea culpa. And I resolve to do better!) What value does one put on the vitality of the R community? Best regards, Michael Grant, Ph.D. * The requirements for creating packages are on target, and have the desired impact on both the quality and breadth of R. --- Philippe Grosjean <phgrosjean at sciviews.org> wrote:> Hello, > > In the latest 'Scientific Computing World' magazine > (issue 78, p. 22), there > is a review on free statistical software by Felix > Grant ...2.)
My background: I am a biologist coming to R via Bioconductor. I have no computer background in computer sciences and only basic undergraduate training level in statistics. I have used R with great pleasure and great pains. The most difficult thing is to know what functions to use - sometimes I know that one function is most likely available, but there's really no easy way to get it (yes, even going to the archives and reading the help files). I feel that more examples in the help files would definitely be a good way to fully understand the potencial of the functions. I know how difficult this is to do and how much of a time sink it must be. One thing I defeinitely think would be a great improvement is to have a beefed up Object Explorer as Splus does. I think it's the great advantage of Splus when compared to R is to have much easier access to what type of object, col names, classes and so on there are. And how much easier it is to change all these attributes in Splus. I think R 2.0 in Mac did a lot to improve this, but I think that for someone that very frequently needs to know whether the object created turned out to be a vector or a list, the easy access to objects is very, very, very important and would be a great improvement in the ease of use of R.
[...]> I am a biologist coming to R via Bioconductor. I have no computer > background in computer sciences and only basic undergraduate training > level in statistics. > > I have used R with great pleasure and great pains. The most difficult > thing is to know what functions to use - sometimes I know that one > function is most likely available, but there's really no easy way to > get it (yes, even going to the archives and reading the help files). > I feel that more examples in the help files would definitely be a > good way to fully understand the potencial of the functions. I know > how difficult this is to do and how much of a time sink it must be.Yes, I' often have the same problem when it comes to programming in R (data manipulation, formatting etc ...). When thinking about a solution, I often come up with something slow and complicated. A positng to this list usually reveals a very simple solution thanks to a function that I didn't find when exploring help, help.search and the archives (and thanks to those who give me the hint ;-). However, I don't know how to improve this, i.e. how to implement a more sophisticated help.search. Maybe the keywords in the help files or some kind of free text mining would help - well, maybe this is a bit over the top. On the other hand, when it comes to the statistics (I'm a not a statistician) and it's minimal formatting of data etc , I think that developing an understanding of the stats itself is the main probelm and a GUI doesn't help very much in for this. Once the basic understanding is there (which one needs anyway, even with a GUI), the rest is not too difficult. In addition I usually need to script the calculations for many different datasets, and again most GUIs are bad in repeating tasks systematically. I've spent quite some time with learing R (and I haven't stoped yet ;-), but it's devinitely worth it. As a scientists I appreciate it, and since it is a tool that use often, I would not exchange the command-line for any GUI. This list and the many books and manuals (mentioned in the other postings here) do a pretty good job in teaching R! kind regards, Arne [...]
> From: David Forrest > > On Wed, 17 Nov 2004, Mike Prager wrote: > > ... > > Using CLI software, an infrequent user has trouble > remembering the known > > functions needed and trouble finding new ones (especially > as that user gets > > older). What might help is an added help facility more > oriented towards > > tasks, rather than structured around functions or packages. > ... > > Another good (non-GUI) tool for the CLI is keyword > completion. R in ESS > does this, giving you lists of possible functions, variables > and objects, > or feedback if there isn't any. R's CLI completes, but only with > filenames in the current directory.That works only if R was compiled with readline. Thus it doesn't work that way on Windows, for example. Completion still works on Windows under ESS though. Andy> Dave > -- > Dave Forrest > drf at vims.edu (804)684-7900w > drf5n at maplepark.com (804)642-0662h > http://maplepark.com/~drf5n/ > > ______________________________________________ > 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 author of the article says nothing about the large number of hours and weeks that he surely spent learning S-plus! There should be attention to the costs that arise from a wrong or inappropriate analysis, perhaps because the software that is in use makes it difficult to do anything better, perhaps because of statistical skill limitations, often with these two factors working together. Analyses that misrepresent the science, or designs and analyses that conspire together to this end, have serious and costly implications for research. I've refereed several papers recently, in broadly ecological fields of endeavour, with seemingly quite reasonable data, where the mix of author skill and abilities of the package was clearly not up to the task in hand. Relative to getting on top of the statistical issues (for which they will probably end up getting, as they need to, statistical help), the GUI/noGUI issue will be a minor consideration, and hours or weeks spent learning R will be at most a modest consideration. John Maindonald email: john.maindonald at anu.edu.au phone : +61 2 (6125)3473 fax : +61 2(6125)5549 Centre for Bioinformation Science, Room 1194, John Dedman Mathematical Sciences Building (Building 27) Australian National University, Canberra ACT 0200. On 17 Nov 2004, at 10:27 PM, r-help-request at stat.math.ethz.ch wrote:> From: "Philippe Grosjean" <phgrosjean at sciviews.org> > Date: 17 November 2004 8:53:28 PM > To: <r-help at stat.math.ethz.ch>, <r-sig-gui at stat.math.ethz.ch> > Cc: Subject: > > 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. > > 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. > > 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). > > 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. > > I would be interested by your impressions and ideas on this topic. > > Best regards, > > Philippe Grosjean
> If the GPL were not so tight on this point, someone could > commercialize a GUI for R without having to offer their source code > under the GPL. >There is nothing in GPL to stop a commercial GUI for R. Have a look at what Apple do. They have a complete commercial GUI and numerous applications built on a an almost completely GPL'ed operating system. There are loads of shareware GUIs which drive GPL utilities. Most obviously there are plenty of commercial apps which run on GNU Linux. Bill Northcott
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}}
my quick thought: R is a programming language and shouldn't be wrapped up in a GUI to serve the interests of those too complacent to learn to leverage its power. and to echo others: I feel an IDE approach with, say, a code editor and a hyperlinked help system with a richer set of examples is sufficient. we already have the former. cheers
Could I voice my support for the sixth point raised by John Fox? Many users would find such a development to be enormously useful. " (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.)" ********************************************************** Cliff Lunneborg, Professor Emeritus, Statistics & Psychology, University of Washington, Seattle cliff at ms.washington.edu
> From: Patrick Burns > > I think John has exactly the right image -- index to a book -- > but I disagree with his conclusions. > > I read somewhere that an index should not be done by the > author. It was probably written by someone who was bored > of indexing, but the logic was precisely because indices should > be about concepts. The author of a package will have one > concept for a function but not all of the concepts that come > from various fields of study. I suspect that no one outside of > finance would think to index "sd" with "volatility" for (a not very > good) example. > > There could be an index builder that accepts a search phrase and > the function or package that is the successful answer to the search. > If this were open, then R users could contribute to the index who > don't feel qualified to submit code. It could also help diffuse the > frustration of taking too long to find a function by allowing a way > to insure that the exact same thing doesn't happen to others. > > Amazon has a function that says those who bought "The Chicago > Manual of Style" also bought Strunk and White.Would that be the same function that suggested bunch of books on fashion modeling when I look up Frank's book (`Regression Modeling Strategies')? 8-) Andy> In the same way, > the R index could provide a list of terms that overlap the given > search term. For example if we search for "goodness of fit", then > "hypothesis test" might be one of the related terms that pops up. > > No, I'm not volunteering to build the system. > > Patrick Burns > > Burns Statistics > patrick at burns-stat.com > +44 (0)20 8525 0696 > http://www.burns-stat.com > (home of S Poetry and "A Guide for the Unwilling S User") > > John Fox wrote: > > >Dear Duncan, > > > >I don't think that there is an automatic, nearly costless > way of providing > >an effective solution to locating R resources. The problem > seems to me to be > >analogous to indexing a book. There's an excellent > description of what that > >process *should* look like in the Chicago Manual of Style, > and it's a lot of > >work. In my experience, most book indexes are quite poor, > and automatically > >generated indexes, while not useless, are even worse, since > one should index > >concepts, not words. The ideal indexer is therefore the > author of the book. > > > >I guess that the question boils down to how important is it > to provide an > >analogue of a good index to R? As I said in a previous > message, I believe > >that the current search facilities work pretty well -- about > as well as one > >could expect of an automatic approach. I don't believe that > there's an > >effective centralized solution, so doing something more > ambitious than is > >currently available implies farming out the process to > package authors. Of > >course, there's no guarantee that all package authors will > be diligent > >indexers. > > > >Regards, > > John > > > >-------------------------------- > >John Fox > >Department of Sociology > >McMaster University > >Hamilton, Ontario > >Canada L8S 4M4 > >905-525-9140x23604 > >http://socserv.mcmaster.ca/jfox > >-------------------------------- > > > > > > > >>-----Original Message----- > >>From: r-help-bounces at stat.math.ethz.ch > >>[mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of > Duncan Murdoch > >>Sent: Monday, November 22, 2004 8:55 AM > >>To: Cliff Lunneborg > >>Cc: r-help at stat.math.ethz.ch > >>Subject: Re: [R] The hidden costs of GPL software? > >> > >>On Fri, 19 Nov 2004 13:59:23 -0800, "Cliff Lunneborg" > >><cliff at ms.washington.edu> quoted John Fox: > >> > >> > >> > >>>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. > >>> > >>> > >>That would not be easy and won't happen quickly. There are some > >>problems: > >> > >> - The base packages mostly don't use \concept. (E.g. base > >>has 365 man pages, only about 15 of them use it). Adding it > >>to each file is a fairly time-consuming task. > >> > >>- Before we started, we'd need to agree as to what they are for. > >>Right now, I think they are mainly used when the name of a > >>concept doesn't match the name of the function that > >>implements it, e.g. > >>"modulo", "remainder", "promise", "argmin", "assertion". The > >>need for this usage is pretty rare. If they were used for > >>everything, what would they contain? > >> > >> - Keywording in a useful way is hard. There are spelling > >>issues (e.g. optimise versus optimize); our fuzzy matching > >>helps with those. > >>But there are also multiple names for the same thing, and > >>multiple meanings for the same name. > >> > >>Duncan Murdoch > >> > >>______________________________________________ > >>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 > >> > >> > > > >______________________________________________ > >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 > > > > > > > > > > > > > ______________________________________________ > 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 > >