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

A.J. Rossini blindglobe at gmail.com
Mon Nov 22 07:33:05 CET 2004


I don't think we are using GUI differently.  I'll reference some
experiments that I disliked that used Emacs/ESS pull-downs in much the
same style as SPSS/Minitab/etc.

More amusing, I actually got them to "write and evaluate" SAS
equivalents for regression model fitting as well as the same for R.

I didn't like them.  I'm not about to publish them.  They slowly
become an RSI hazard.  The only nice use was that they were templates
(and I should say that forming a general notion of statistical
templates is on my "to-do" list, probably more like a "never-do"
list).

With respect to applications programming and "statistical
programming", I could write a book.  Here is a subset of issues, and
it's not complete:

applications programs have to be mildly optimized (i.e. can't be too
slow), and are generally left alone except for maintanance.
Generally, there is a specification to which the program has to be
written, and metrics for evaluation are based on code quality, not
just the output.


statistical programs (and I'm thinking "data analysis", not
infrastructure coding or refactoring analytics to be more general)
usually have to be "finished", rather than "almost done".   Usually no
optimization is done, and extensions happen in a less specified way. 
More importantly, in idea cases they follow but don't religiously obey
an analysis plan (usually due to holes in the plan, not the program)
and metrics are based on comprehensiveness of results rather than code
metrics or the "path taken".

Sometimes application programs have to be written to get the job done
(thinking of applications programming as a subset) and other times,
it's just a pile of code (or the GUI generated hodgepodge mix of MS
Excel).

best,
-tony


On Fri, 19 Nov 2004 22:55:08 -0500, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
> On Fri, 19 Nov 2004 13:50:59 +0100, "A.J. Rossini"
> <blindglobe at gmail.com> wrote:
> 
> >Note that there are bits and pieces of IDE components within ESS,
> >provided that you use some of the other tools available (in
> >particular, ECB).  I've not finished integration, but it provides
> >tools comparable to JDEE (the Emacs Java IDE), which isn't far off
> >from Eclipse in many ways.
> 
> Yes, definitely, and if R itself had more of the infrastructure to
> support a full IDE, I imagine you'd expose it in ESS as soon as anyone
> did.
> 
> >Currently, it does provide limited source code navigation within the
> >file, for example to functions and "data assignments".  Next would be
> >some of the code generation tools, but that becomes tricky.
> >
> >Applications programming is NOT statistical programming, and this
> >point needs to be hammered in, sometimes.  There is a duality with R
> >(and similar interactive (not necessarily interpretive) programming
> >languages used for data analysis such as Lisp, Perl, and Python)
> >
> >An IDE for statistical analysis is different than what one wants from
> >a GUI, or from an IDE for applications programming.
> 
> I can see the need for differences between IDEs for interactive vs
> compiled operation, but what sorts of differences do you think are
> specific to statistical programming vs application programming?
> 
> By the way, I think we're using "GUI" differently.  For reference,
> when I use it I'm distinguishing it from a teletype style command line
> interface.  In my usage, vi and Emacs are both GUIs (though vi is a
> pretty limited one).  Command line R is not.  Windows Rgui is mixed,
> in that the console acts like a teletype (you can only add input at
> the bottom), but there are also GUI elements.
> 
> Duncan Murdoch
> 


-- 

best,
-tony

---
A.J. Rossini
blindglobe at gmail.com



More information about the R-SIG-GUI mailing list