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

Jeffrey J. Hallman m1jjh00 at frb.gov
Thu Oct 20 18:26:05 CEST 2005


>>>>> "p" == Peter Kleiweg <pkleiweg at xs4all.nl> writes:
  p> My advice about VisualWorks Smalltalk: don't. It may work well 
  p> on Windows. On Linux, it is a disaster. Nothing works the way it 
  p> is supposed to on Linux. I have tried one application in 
  p> VisualWorks: BottomFeeder. Dozens of versions and bug fixed. But 
  p> there are no fixed for the incompatibility between the virtual 
  p> machine and my Linux box. It can't display jpeg's. Windows keep 
  p> jumping around the screen. It doesn't know about size of fonts, 
  p> so on many parts of the interface, parts of text are missing. 
  p> Standard key combinations, copy and paste, all work completely 
  p> different from other Linux applications. You can't install the 
  p> program in the Unix way. It saves its internal state in a binary 
  p> form that gets being corrupted, and you have to make a clean 
  p> install regularly, loosing all your old data.

I haven't used BottomFeeder, but I do wonder whether or not you've
corresponded with James Robertson about the bugs you've experienced. My
experience with him is that he is eager to hear about and fix them.

  p> Mind you, this is software developed by someone from 
  p> VisualWorks, presenting this as the prize horse of what 
  p> VisualWorks is capable of.


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

  p> Squeak works much better on Linux than VisualWorks, but it still 
  p> shares many disadvantages with VisualWorks. The main obstacle is 
  p> its use of a virtual machine for everything. It is like working 
  p> in a completely different environment, were none of the rules of 
  p> your usual environment apply. You cannot use your favourite 
  p> software to do your programming and organising. I write programs 
  p> in Python, C, PostScript, R, and half a dozen other regularly, 
  p> all from Emacs. If I want to program VisualWorks or Squeak, I 
  p> have to do so from within VisualWorks or Squeak, with its own 
  p> editor. I can use none of the tools I rely on for all my other 
  p> tasks. And of course, something written in VisualWorks is 
  p> completely useless in Squeak, and vice versa.

VM vs native code is an argument that may never end.  Smalltalk and Java
both use VM's to get cross-platform capability.  You can think of the R
interpreter in the same way.

And you don't like having an image, preferring to code in Emacs and storing
the code in files.  In the Smalltalk world, we like to say: "Source code in
files.  How quaint!"  Having all your code resident in an image while you're
developing it enables a lot of productivity-enhancing stuff in the IDE. I
could go on all day about why Smalltalk is such a nice environment to program
in, but http://www.whysmalltalk.com  does a better job of it than I am likely to.

I don't have much experience with Squeak, but I have developed several
VisualWorks applications that used to run on Solaris and now run on Linux.
Moving from Solaris to Linux was very easy, and I've ported a couple of them
to Windows with not much trouble either.  As for portability between Smalltalk
dialects, that is usually pretty easy for non-GUI stuff.  The ANSI standard
for Smalltalk does not cover GUI libraries, and each of the major Smalltalk
environments has it's own way of doing GUIs.  But then, you can't easily port
Qt apps to GTK or wxWidgets either.  


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

  p> No. A program should respect the user's chose of platform. I 
  p> write a program in Python with Tk. On Linux it looks and feels 
  p> like a Linux program. On Windows, it looks and feels like a 
  p> Windows program.

You've got to be kidding.

  p> Why would you want a GUI for something like R in the first 
  p> place? It is a programming language. That is its force. Nothing 
  p> beats the command line. A GUI can never offer the same power, 
  p> unless it offers the same openness as the OS it is running on. 
  p> It has to incorporate an editor to do the programming. Except 
  p> without the GUI, I can use any editor I like. I don't need a 
  p> GUI. Linux running X and my favourite windows manager is all the 
  p> GUI I need.

Among other things, I develop applications that are used by nonprogrammers to
do their own jobs.  For example, we just published the H.6 release, which
shows various money supply numbers.  There are several applications involved
in processing the data that eventually show up on the release.  There are
PostScript templates, R programs, some SAS, some Smalltalk and a bunch of
shell scripts.  Different people get involved at various stages.  The idea
that all of this could be done via command line is ludicrous.  Come to think
of it, I don't know why you even use Emacs.  Why not just use 

cat > myFile << EOF

and type everything in?  


  p> -- 
  p> Peter Kleiweg
  p> http://www.let.rug.nl/~kleiweg/

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



More information about the R-SIG-GUI mailing list