[R-gui] [Rd] R GUI considerations (was: R, Wine, and multi-threadedness)
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