[R-gui] (renamed) What do we do?

[A.J. Rossini]

>>>>> "thomas" == Thomas Friedrichsmeier <thomas.friedrichsmeier@ruhr-uni-bochum.de> writes:

    thomas> I have come to think, that the "endless discussions" are still partially due 
    thomas> to one or more misunderstandings. I support Phillippe in that we really 
    thomas> should start making concrete steps, and as part of that I view the draft I 
    thomas> suggested for a common plugin-specification. Let me try to sum up very 
    thomas> shortly the premises that made me arrive at thinking, that such a 
    thomas> specification would indeed be a good idea. Maybe then we can spot, where 
    thomas> exactly we don't agree (if there is still disagreement, which I suspect):

    thomas> A1) We have ultimately failed in agreeing on one single large project. Rather 
    thomas> we have split up into several different ones. Some of those projects may 
    thomas> fusion at some point of time, others may be given up. Still, we will have 
    thomas> several different R-frontends.

This is not a bad thing!  

    thomas> A2) We have also failed at trying to agree on a common toolkit/general 
    thomas> approach. As a matter of fact, this is one of the reasons for A1. Also, we 
    thomas> all have an opinion on which toolkit/approach is best suited for our needs, 
    thomas> but unfortunately we don't agree on which one that is. Discussions of the 
    thomas> form lets simply all use Tcl/Delphi/whatever are completely futile (as are 
    thomas> discussions "extend R to have a GUI" vs. "GUI around R").

This is not solvable.  If it was, we'd all be rallying around ESS and
someone would've embedded R within Emacs (similar to the current
PostgreSQL embeddings and language interface that has been done for
XEmacs), to solve Peter's complaint.  After many years sheparding that
project, I've learned that people have strange, senseless opinions,
and it's best not to challenge them, just let them learn by their
mistakes...  :-).

    thomas> A3) Apart from toolkit and general approach, there are a number of further 
    thomas> important differences between projects.

    thomas> B1) Despite A1-3, many, if not all projects will want to offer a GUI-dialog 
    thomas> for e.g. a t-test.
    thomas> B2) Despite A1-2, there are only so many different ways to do a GUI for a 
    thomas> t-test "in principle".
    thomas> B3) This "in principle" (i.e. the thing that all GUIs for a t-test will have 
    thomas> in common) can be formalized in a relatively straightforward way.
    thomas> B4) B3 is possible without sticking closely to any particular toolkit.
    thomas> B5) since B4, it can be done in a way that is useful to projects using 
    thomas> different toolkits/approaches/differing in other ways.

    thomas> C1) There is a _lot_ of problems to which not only B1, but also B2-5 apply, 
    thomas> even though B1-5 may not apply to _all_ problems.
    thomas> C2) from C1 and B5 it seems reasonable to try to come up with such a 
    thomas> specification, and we will be able to share a lot of effort despite A1-3.

This is what I view as minimal practical gain.  I can do a GUI right
now for the t-test in about 4 different toolkits (Java, tcltk, python,
emacs lisp; maybe more, but I not going to change from being
"read-only" in Perl), and there are a number of obvious and completely
different approaches, all of which are appropriate WITHIN CONTEXT and
AUDIENCE.  However, that there are a number of "equally good" (modulo
context/audience) choices.

Rather than discussing, it would be better to be coding and
displaying examples.  

I'm not strongly in favor of designing the guts without seeing the end
results -- you can refactor the guts later as you find out what you
really will need.  To design them right the first time without
examples is a bit backwards, though exceptions occur (DTL comes to
mind :-).

So talk about XML vs. an associated list conf-file, etc, is sort of
silly.  You can write simple translators for that sort of thing, or
refactor the guts later.

Everyone wants to run a project and being in control; but to agree on
goals with the final outcome requires people to swallow something and
take up pieces, as well as "release ownership and trust others".  It's
the problem with opensource, and why successful projects (like R) mean
something about the people involved.

Anyway, what I'd like to see is people generating cool and novel use
cases; GUIs that REALLY simplify life, not just the "here's a t-test
widget", but perhaps add another dimension (a simple interface to
re-simulation methodologies for sensitivity analysis, or other tasks
which reduce the computation/programming level).  Stuff which knocks
my socks off, that we can all agree on the statement that "we need to
publish this in JCGS/JSS now".  I'm less concerned about refinements
at the backend -- optimizations and flexibile interfaces will come at
some point.

Both Tony Hoare and Don Knuth said, long ago, "premature optimization
is the root of all evil" (in software design), and I'd add premature
flexibility to that, as well.

Anyway, while that sums up my long-winded opinion, I'm still eager to
see if anyone comes up with something good.  (and of course, that
means, "better than ESS" :-).   I think it's possible.

And it's fine to figure out the primary use cases as well as to agree
on definitions first, before coding.  I think this is why people are
talking at loggerheads, though it's somewhat useful.  In fact, it
would be worth writing out what you want to do.  Here's my interests:

Audience: moderate/experienced programmers interested in data analysis
Tools to develop: GUI/IDEs for largish projects using modern
    programming methodologies (literate programming, extreme
    programming, aspect-oriented programming).
Languages: Statistical languages, such as S(R/S-Plus); SAS; Stata; 
    SciPython; XLispStat, and any that interface with them.
Goal: support both programming and data analysis cross platform and 
    more importantly, UNIFORMLY
    cross-language. (extraction/display/manipulation of 
    electronic documents, workbooks that support literate statistical
    analysis) 

Sounds like SciViews, eh? 

best,
-tony

-- 
A.J. Rossini				Rsrch. Asst. Prof. of Biostatistics
U. of Washington Biostatistics		rossini@u.washington.edu	
FHCRC/SCHARP/HIV Vaccine Trials Net	rossini@scharp.org
-------------- http://software.biostat.washington.edu/ ----------------
FHCRC: M: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email
UW:   Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX
(my tuesday/wednesday/friday locations are completely unpredictable.)