[R-gui] [Rd] R GUI considerations (was: R, Wine, and multi-threadedness)

[Byron Ellis]

And I so wanted to stay out of this particular discussion, I hope  
you're proud of what you've done. *cracks knuckles* Right, lets get  
to it then.


On Oct 19, 2005, at 3:43 PM, Jeffrey J. Hallman wrote:

> If you're looking for a GUI toolkit that:
>
>    1.  Is cross-platform,
>    2.  Has a good collection of widgets that look good on all  
> platforms, and
>    3.  Is easy to work with from R
>
> then it is hopeless.  There is no such toolkit.

There is in fact such a toolkit. I'll give you a hint, its name ends  
in "step" and its heavily used under a different name by a company  
named after a fruit. It works quite well from R, doesn't require  
another language and frankly the binding between it and R was  
actually pretty pleasant as these things go. By my count it took 2727  
lines of C and 411 lines of R to bind, a good half of which are  
technically unnecessary. Right now it probably doesn't run under  
Windows and Linux/BSD/Solaris/Your Favorite POSIX Compliant UNIX at  
the present time, but thats mostly because I don't care rather than  
because it can't.

>
> As one poster mentioned, most of the better GUI toolkits are very
> object-oriented, because that paradigm is a good fit for GUI  
> programming.
> There are a few programming environments out there that do have  
> nice GUI
> abilities, but they all use base languages that are not very R- 
> like, and so
> the potential R GUI programmer is faced with having to use two very  
> different
> languages for his creation.  And even if that obstacle is  
> surmounted, there

This is only a problem because people seem to insist on using R's  
object system in a way that is not actually very compatible with R's.  
To misquote Robert at DSC, "their primary complaint about R is that  
its not Java." If you think about it for a moment, R's environment is  
actually quite well suited to GUI tasks because, well, because it has  
environments. Imagine drawing into a window (you're a plotting tool  
or something). Really, you're a function executing in an environment  
(oh ho!) that has access to certain system resources, in this case a  
canvas of a certain physical and logical dimension. Responding to  
events could take on a similar structure---you're really executing in  
an Event environment that has certain bound symbols. Obviously you  
get to keep your lexical environment so event handlers that need to  
share state can in the usual way. Its not particularly difficult and  
doesn't even need to involve objects in any real way, except as  
little stubby things with attributes you can modify or poll.

> remains the difficulty of trying to package up his work in such a  
> way as to
> make it easily installed by others.  Things are always breaking in the
> interfaces between R and whatever you're using.  Trying to keep it  
> all running
> and packaging it for deployment are thankless, gargantuan tasks.

How is this different than releasing any piece of software?

>
> There is a better way, and that is to give up on R.  Start over with
> a better programming environment, one that is object oriented, as  
> flexible and
> dynamic as R, is cross platform, easy to program in, and has decent  
> GUI
> facilities already.  Then port the stuff in R that does statistical
> programming, and you have the best of all worlds.
>
> The environment I am thinking about is VisualWorks Smalltalk, which  
> is free
> for noncommercial use.  As a language, Smalltalk is both simpler  
> and more

Did you just use the words "cross platform" and "VisualWorks  
Smallktalk" in the same email? Have you ever used VisualWorks on  
something other than Win32? I'd rather use Squeak. At least then I  
know it'll have an equally childish interface on every platform.

> powerful than R, and the VM it runs on is much faster than the R  
> interpreter.

Contrary to popular belief the speed of R's interpreter is rarely the  
limiting factor to R's speed. People treating R like C is typically  
the limiting factor. You have vector operations, USE THEM.

> It has superior garbage collection and the best IDE in the business.
> Callouts to C are just as easy as they are in R, but would likely  
> not be
> needed as often due to the faster VM and much better programming  
> facilities.

But not portable across Smalltalks. Whoops. Oh, and there's still a  
helluva lot of Fortran code out there that nobody wants to port.

> Interfaces to various databases are possible, and the most powerful  
> web
> toolkit (Seaside) is written in Smalltalk and runs under VisualWorks.

Because I spend all my time writing web shopping carts in R?

>
> There are a couple of other Smalltalk environments around that  
> could also be
> considered.  Squeak is an open source cross-platform Smalltalk that  
> is not as
> fast as VisualWorks, but still must faster and more robust than the R
> interpreter.  Smalltalk/X is another possibility, though it works  
> only on
> Windows and Unix.
>
> Think about it.  Once you have a basic math package that can handle  
> matrix
> programming and various mathematical functions, building the various
> statistical modeling tools on top of them is not that hard.  What  
> makes S and
> R so much better than SAS is their programmability.  Smalltalk is  
> like that,
> only better.
>

As it happens, I've thought about it. At length. To the point of  
having images that actual test out the idea of implementing these  
libraries whilst my simulations run in the background (we can discuss  
the effects on my degree progress at a later date). Smalltalk has  
some very clever features. I'm a particular fan of the notion that  
"breakpoint" and "exception" aren't different things for example.  
Unfortunately its also turns out that these "basic math packages"  
are, in fact, quite difficult to do well especially when multiple  
platforms are involved. For example, it took GSL 5 years to get to a  
'1.0' release and its still using CBLAS, an even older piece of code,  
to do most of its vector and matrix operations.

Assuming you manage to pull that off (see you in 2010!) I'm still not  
convinced it would work as most Smalltalks (Squeak especially) take  
on a self-contained nature, meaning that they Don't Play Well With  
Others. The only time *I* really use a GUI is when I'm preparing a  
presentation or a paper in which case I need to be table to talk to  
all manner of different pieces of software, something which is  
generally ignored Smalltalk. At least with the current R GUIs I can,  
you know, cut and paste. Sure, you can get Smalltalks to do this sort  
of thing too, VisualWorks can do a fair amount though how well varies  
widely with platform (hey! Just like R). Even better, the  
programmatic interfaces vary from platform to platform and Smalltalk  
to Smalltalk. I could continue, but I'm getting hungry---suffice it  
to say that Smalltalk isn't some sort of panacea despite being a very  
nice language, too much James Robertson for you.

So, you've got a lot of work (implementing a robust scientific  
library) ahead of you for dubious gains (a rich GUI, maybe a better  
programming language and a whole raft of new problems). It seems like  
the better idea would be to pull a Java and shameless hijack the  
interesting bits from Smalltalk rather than go the other direction.

Oh, and since you suggested googling yourself,

I gotta go with Alan Z on this one, a<-1 is ambiguous is the worst  
possible way, := would probably be a better choice. Looks less like  
the APL symbol, but who cares?

>
> Jeff Hallman
>
> _______________________________________________
> R-SIG-GUI mailing list
> R-SIG-GUI at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-gui
>

---
Byron Ellis (ellis at stat.harvard.edu)
"Oook" -- The Librarian