Re: [Rd] Am I missing something about debugging?

From: Jeffrey J. Hallman <jhallman_at_frb.gov>
Date: Wed 03 Jan 2007 - 15:42:38 GMT

Thoughts from a pro-Smalltalk bigot:

"Byron Ellis" <ellis@stat.harvard.edu> writes:
> While a Smalltalk-style debugger would be pretty awesome, I suspect
> R's semantics would make restartable exceptions pretty difficult and
> R's current implementation would make getting the continuation-like
> object you'd need pretty difficult, at least across the range of
> platforms supported by R.
>
> A solution, of course, would be to implement R's interpreter in
> Smalltalk as a domain-specific language. Vista Smalltalk apparently
> hosts a Lisp/Scheme interpreter and I know of at least one Lisp
> implementation for Squeak, which serve as pretty good starting points
> for an S-like language. :-)

I've programmed extensively in both Splus/R and Smalltalk, and I am much less enamored of this idea than I used to be. R and Smalltalk are fundamentally different and require different mindsets to write decent code. Here are some of the differences:

  1. Smalltalk objects are passed by reference, while R passes by value.
  2. Smalltalk programs consist of messages sent to objects (receivers) and assignments. R programs consist of function calls and assignments.
  3. Smalltalk is single-inheritance and single-dispatch. R has multiple inheritance and multiple dispatch.
  4. The simplicity of the Smalltalk model is in part responsible for the fantastic development tools. Single dispatch lets every method belong to a particular class. In fact, everything in the system is an instance of some class, including messages, methods, and even classes themselves. The system browser essentially just browses (and lets you edit) classes, and that's essentially all that you need. There are other browsers, but they're really just different views into the same thing.
  5. The style of programming is different. One example is how to implement a computation with some inputs that have default values. In R, you would write a function like this:

   myFun <- function(arg1, arg2 = default2, arg3 = default3){    ...
   return(aComputedResult)
   }

   and call it any of these ways:

   answer <- myFun(arg1 = 1)
   answer <- myFun(arg1 = 1, arg2 = 2)
   answer <- myFun(arg1 = 1, arg3 = 3)
   answer <- myFun(arg1 = 1, arg2 = 2, arg3 = 3)

   The naive way to do the same in Smalltalk uses 4 methods implemented in the    class of arg1. The one that does the actual computing looks like this:

   myFunArg2: firstNumber arg3: secondNumber

     ....
     ^ aComputedResult          "'^' is the return operator."

   The other three methods are:

   myFunArg2: aNumber
     ^ self myFunArg2: aNumber arg3: default3

   myFunArg3: aNumber
     ^ self myFunArg2: default2 arg3: aNumber

   myFun
     ^ self myFunArg2: default2 arg3: default3

   and the four ways you can invoke these are:

   answer := 1 myFun.
   answer := 1 myFunArg2: 2.
   answer := 1 myFunArg3: 3.
   answer := 1 myFunArg2: 2 arg3: 3.

   Compared to R this is kind of clunky, with a combinatoric explosion in the    number of methods as the number of arguments increases. To avoid that, an    experienced Smalltalker might instead create the class MyFunArgs to    implement the idea of "arguments for computing myFun". MyFunArgs would    have instance variables arg1, arg2 and arg3, and myFun would be invoked by    sending the message 'compute' to an instance of myFunArgs. MyFunArgs would    have an initialize method that set up the default values, so that

   MyFunArgs arg1: aNumber

   returned an instance with arg1 set to aNumber, arg2 set to default2, and    arg3 set to default3. Then you'd call it in one of these ways:

   answer := (MyFunArgs arg1: 1) compute.
   answer := ((MyFunArgs arg1: 1) arg2: 2) compute.
   answer := ((MyFunArgs arg1: 1) arg3: 3) compute.
   answer := ((MyFunArgs arg1: 1) arg2: 2; arg3: 3) compute.

For all of these reasons and more, R code does not translate cleanly to Smalltalk, and even writing an R interpreter in Smalltalk does not really take advantage of the Smalltalk way of programming.

On the other hand, Smalltalk is a very nice language, and with a bit of work to set up the fundamental classes (e.g., Matrix, Vector, StatisticalModel, etc...), a very nice data analysis environment could be created using it. The virtues of such a system would be many. First and foremost is that, at the level of 'computing on the language', Smalltalk is easy to understand, as it really consists of only a few simple ideas consistently exploited to create a sophisticated system. Second, there are free Smalltalk implementations that can create complicated GUI applications much more easily than can be done in R or Splus. Third, even the slowest Smalltalk interpreters are faster than the R interpreter. Of course, in many cases this would not matter since R and Smalltalk programmers alike can always call out to C or Fortran for numerically intensive computations.

Jeff



R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Thu Jan 04 06:14:19 2007

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Thu 04 Jan 2007 - 00:31:02 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.