[R] GUI's for teaching

Marc Schwartz mschwartz at medanalytics.com
Fri Jun 28 19:58:40 CEST 2002


> -----Original Message-----
> From: owner-r-help at stat.math.ethz.ch
[mailto:owner-r-help at stat.math.ethz.ch] On
> Behalf Of Mark Myatt
> Sent: Friday, June 28, 2002 4:15 AM
> To: MSchwartz at medanalytics.com
> Cc: 'R Help'
> Subject: Re: [R] GUI's for teaching
> 
> [SNIP]
> 
> On Windows, I use Visual SlickEdit which can do a lot of the IDE
stuff.
> On Linux, I use KATE which can do some of the IDE stuff but will
> probably move over to SlickEdit when my next license renewal comes up.
> These are pretty good tools but are not really capable of really tight
> integration with R. I suppose what I would like is something like the
> Delphi IDE for R (i.e. something more than a good editor).

I cut my C programming teeth on Borland products back in the late 80's
and early 90's, so I am familiar with those IDEs and some of the more
recent (dare I say it....) Microsoft versions. I even used early
versions of Turbo Pascal/C and did some ASM coding on both the early
Apple 6502 and Intel 8086 platforms. 

In comparison to the primitive tools of that era, the new IDEs do
provide an enhanced level of productivity in coding by enabling
functionality that is well documented and need not be re-listed here.
The ongoing popularity of third party tools (such as editors) does
however suggest that there still seems to be a need for 'best of breed"
solutions and/or perhaps language independent common solutions.

These IDE tools however, come at a substantial cost in time and
resources for the development teams, whether they are in a commercial
shop or in an open source environment such as R.

If one were to use a "community standard" of some nature and I stand to
be corrected on this by R and S-Plus users, a comparison of R to S-Plus
V6 would be at least a starting point. By starting point, I mean that
this is how at least some basic expectations of functionality should be
defined. Clearly, this is fraught with problems on a variety of levels,
like comparing the personalities of two biological siblings. They come
from the same "gene-pool", but have evolved in differing environments
with varied impacts on their behavior and have underlying genetic
variations. The availability of a version of SP6 without command line
access (GUI only) is a good example I think. My apologies to the
genetics experts in the group for my gross over-simplification.

While I am not an active S-Plus user, I have demo'd the application. I
do not believe that it has a full set of features akin to a tightly
integrated IDE, despite the substantial GUI in place and the
application's commercial for-profit development environment.

Based upon a quick re-review of the S-Plus Programmer's Guide online
(http://www.insightful.com/support/documentation.asp?DID=1), my take is
that the "debugging" features (page 205+) are not of IDE level
functionality. Even in that document, comments still appear relative to
adding code to display/print intermediate values, etc.  There are no
graphic screen captures in that part of the document, so my
interpretation/impression may be lacking key facts. Someone please
correct me if that is the case.

R does have several of those same core debugging functions (ie. debug(),
traceback(), browser() and recover()).

To close my thought-loop on the IDE, as with anything else, priorities
are established by the needs of the community. Neither SP6 nor R has one
at this time and I would imagine that this is a result of some conscious
resource allocation decisions by the core teams on both sides. That is
not to say that having one would be bad, simply that other tasks are
higher in priority for the core groups.

I believe that in this thread, R development priorities and resource
allocation have been mentioned and I would agree with the general
sentiment that core functionality would be a higher priority. Such
GUI-based enhancements may be appropriate for additional contributions
over time and perhaps by a team of folks with the time, resources and
support to accomplish that task.

As I am typing this, I just got Dr. Harrell's follow up post on GUIs and
agree that there are certainly things that can be done to enhance
aspects of the user-interface and help resources.  That being said, two
thoughts:

1. If determined to be of value to the R community at large, these
features will likely appear in time.  That is the natural progression of
any product as you don't go from version 1 to version 5 in one step.

2. Let's not lose sight of just how much R already does and honestly,
how well it does them.

I am constantly impressed by what the R-Core team has done and the
contributions of the R Community to the effort, including this list.  My
hats off to the group for providing a phenomenal product/tool and to the
continued progress being made.

Regards,

Marc


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._



More information about the R-help mailing list