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

[Jeffrey J. Hallman]

>>>>> "b" == Byron Ellis <ellis at stat.harvard.edu> writes:
  b> 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.

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

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

This is interesting.  However, I wonder how you can do GUI programming with
the current R single event loop. If an event comes in while some other code is
executing, do you interrupt, handle the event, and then resume?  Would not R
require major surgery to make it reentrant?  What if I want to display a screen
while continuing to do other stuff?  It seems to me that R would need
something like the S setReader/setMonitor stuff to run a GUI.

  >> 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.

  b> How is this different than releasing any piece of software?

If your software is all done in a single environment that already handles
cross-platform issues for you, it becomes much easier.  As an example, I had
Splus code that handled a lot of date arithmetic by calling C code.  I had to
use C because S6 is so slow.  When I ported to R, I found that R was fast
enough that I didn't need the C code.  As a result, I no longer have to build
a .so for Linux and a .dll for Windows.  In fact, I never could get the .dll
for Windows working.
 
  >> 
  >> 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

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

I use VisualWorks on Linux (and before that, on Solaris) every day.  I've only
played around with it a bit on Windows.

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

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

That's not always possible.  Even when it is, sometimes 'vectorized' code is
less readable than slower code that handles one element at a time.  I really
value readability.

  >> 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.

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

I used f2c on some LINPACK routines and did a bit of cosmetic cleanup by hand.
My experience porting about 12000 lines of Fortran to C with f2c was pretty good.

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

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

No, but you might want to do something like Statserver, or present real-time
statistical analysis of a live data feed over the web.

  >> 
  >> 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.
  >> 

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

True enough, but you don't have to do everything.  In my work, I couldn't care
less about sparse matrices.  Bluebook S got a lot of mileage out just the QR
and SVD decompositions.  The ATLAS kind of optimizations are only necessary if
your work is very compute intensive and/or uses big matrices that don't fit into
the processors L2 cache.  With processor speed and memory increasing
exponentially every year, I just haven't found it worth spending hours of
programming time to save seconds of run time, especially since the run times
decline every year.

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

I think we're talking about different domains here. I'm not an academic, and
most of the programs I write are used by others who are not programmers.  

As for not playing well with others, VisualWorks is very buzzword compliant.
Web Services, Corba, sockets, XML, ODBC, etc...   Perhaps your real objection
is to source code in the image rather than in files.  You might look at Store,
the VisualWorks code management facility that does version control and such
using relation databases as the back end.

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

Too bad they missed most of the best bits.  R already has more of them than
Java does.