[R-gui] Re: [R] Feedback about SciViews?

Tue Apr 29 23:32:39 MEST 2003

I'm probably setting myself up for a nice long flame session, but here 
we go:

On Tuesday, April 29, 2003, at 09:10  PM, Zed Shaw wrote:

>
> I think that maybe you should listen to what people have to say about 
> their experience trying to write these GUIs.  Maybe if you started to 
> hear things like what Philippe and myself continue to complain about, 
> and started to fix them, then you might find that even your own 
> development projects improve.  Basically, start listening to your 
> users more and don't assume that you can impose your way of doing 
> things on other people.  A classic example is how the R code insists 
> on checking to see it is connected to a pty, and if not it aborts on 
> any errors.  Or that R uses jumps to maintain the event loop, but 
> doesn't provide a convenient way to override this behavior.  Simple 
> things like this cause others tons of headaches, but are so simple to 
> fix.
>

Well the pty thing I'll give you---irritating as hell---but as for R's 
exception handling and its ease of repair, your statements somewhat 
disingenuous. R's exception handling mechanism is simply How It is Done 
in C. Go look at the Python source code sometime, what do you find? 
That's right. setjmp()/longjmp() for exception handling. Just like R. 
Just like Objective-C and AFAIK Perl as well.

This is, of course, the point where the C++ people jump in and proudly 
point to their exception handling and boldly claim that THEY don't have 
these problems. On Windows using VC++ they're right---exception 
handling is actually provided by the OS kernel rather than being a 
userspace thing (the so-called Structured Exception Handling services) 
and VC++ takes advantage of those capabilities. G++ used to use 
setjmp()/longjmp() to implement exceptions (offering no advantage other 
than C++ vs Macros) but my understanding is they now use something else 
far more complex. My understanding is also that it is far buggier so 
advantage: push.

All that said, it would be nice if TRY { } CATCH { } was available 
(throw is already available in the form of error(), though it is less 
formal than most exception mechanisms). BUT, I disagree completely with 
your assertion that it is a "simple fix." To survive an exception there 
is a great deal of work that needs to get done, especially in the 
memory manager, to ensure the environment is in a defined state---to 
let people willy-nilly override exception handling is just going to 
cause massive headaches as would the conditional header file required 
to harmonize R's exception handling with the myriad of other exception 
handlers would also induce much pain (setjmp()/longjmp() is standard, 
but what actually goes on the heap isn't). Having a context argument (a 
la Java) might help to some degree but that would involve changing 
literally every single R function as well as every function in every R 
package. The change itself probably wouldn't be complex, but it is by 
no means a trivial task.

> I won't go into specific complaints about R as a large scale 
> development language as I don't think anyone working on R is 
> interested in hearing them (that's called "industrial autism" BTW).  
> All I can say is, if you want people to use R to write their programs, 
> maybe you should make R behave more like every other

More likely, they've heard them before, squinted, scratched their heads 
and asked "so, tell me again why you want to implement Tetris in R?" R 
_isn't_ a scripting language. It shares many features with scripting 
languages, high level constructions, automatic memory management, etc 
but its a data analysis language. More importantly, an interactive data 
analysis language (which is where the pty weirdness comes from). It's 
purpose (near as I've been able to fathom) is to make the manipulation 
of real data as much like pushing symbols around on a piece of paper in 
Inference 101 as possible. In this regard it is fundamentally different 
in philosophy from the languages you name below.

Does that mean we should ignore the other languages? Hell no. There's 
some good implementation ideas there---if the extensible SEXP idea ever 
gets off the ground I hope it looks something like Python's new object 
implementation. Its pretty clean and a joy to work with. There's also 
some good object lessons there--Perl's "What Was I Smoking" XS for 
instance. Most of the stuff is pretty sophisticated though, not simple 
features at all.

In fact, I'm not sure what simple features you have in mind? I suppose 
the first thing to come to mind is the memory manager, its what I 
thought of when I started messing around with R's underbelly---it 
becomes especially problematic when datasets get large (something I 
work with, "unable to allocate vector of size xxxx" is a familiar face 
these days). The first thought is "hey, Look at Python! Reference 
Counting! Yes." Well, no. R objects are like strings and tuples in 
Python--semantically (and literally) immutable objects so the reference 
counting scheme doesn't really help since you always have to make a 
copy anyways (this is mark-and-sweep right? I'm too lazy to walk across 
the room and look it up). Ideally we'd want (well, I'd want) a 
copy-on-write scheme, but it seems those are difficult to implement and 
probably even harder to shoehorn into an existing system. There are 
other things: R in Databases for instance. This seems like a good idea 
(I still like it), but how to do it? First we have to find and 
implement an entirely new class of algorithms. Most of your standard 
algorithms assume uniform access to all observations and covariates 
(via matrix multiplication or whatever), which is definitely not true 
of a database where your access to data is anything but uniform. So, 
this necessitates the development of some set of online algorithms, 
which may or may not exist for an arbitrary algorithm. Next there's the 
question of Security. Java has a lot to say about this, and it would be 
nice if we could do similar things in R as the DB server process is 
almost definitely running as a user who is not the one accessing the 
server. And so on, but I digress as these aren't really simple features 
from languages and all of the languages you've mentioned (except maybe 
Tcl) aren't terribly well suited for that sort of duty either.

> scripting language on the planet.  Take a look at how Python, Perl, 
> Lua, Ruby, Tcl, Java, and others do things.  Try to find out from 
> people what features of these languages they like and then try to 
> emulate those features.  I think if you just adopted a few really 
> simple features from these languages, you'd improve R tremendously.
>
> Anyway, enjoy your day.
>
> Zed A. Shaw
> http://www.zedshaw.com/
>
>
> On Tuesday, April 29, 2003, at 02:31 AM, Martin Maechler wrote:
>
>>
>> R for Windows already comes with a (simple) GUI.
>> Many of the R developers would rather think mostly about GUI
>> efforts that are platform INDEPENDENT, such as the standard Tcl/Tk
>> package (try "library(tcltk)" and the demos from "demo(package =
>> "tcltk")" in R), and the RGtk (http://www.omegahat.org/RGtk/) one.
>>
>> For that reason, in the Bioconductor project 
>> (http://www.bioconductor.org),
>> the  "tkWidgets" package has been developed (built on top of R's
>> standard "tcltk" package -- which from 1.7.0 on does not need
>> extra efforts for installation on Windows).
>>
>> Excuse that this sounds a bit negative, but platform independence
>> is one of the strengths of R.
>
> _______________________________________________
> R-SIG-GUI mailing list
> R-SIG-GUI at stat.math.ethz.ch
> https://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui
>
Byron Ellis (bellis at hsph.harvard.edu)
"Oook" - The Librarian