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

From: Byron Ellis <>
Date: Wed 03 Jan 2007 - 20:13:47 GMT

On 03 Jan 2007 10:42:38 -0500, Jeffrey J. Hallman <> wrote:
> Thoughts from a pro-Smalltalk bigot:

I'm surprised anyone took the idea seriously enough to respond. :-)

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

Yes, but what's pass-by-value other than a possibly clever version of [anObject doSomething:[anotherObject copy]]?

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

I would argue that Smalltalk is heading in this direction with the introduction of Traits and other class composition techniques. Multiple-dispatch is something Smalltalks generally don't do, but it's not something it can't do. Actually, there was a paper just recently (on Arxiv maybe?) that showed a very elegant way of putting multiple dispatch into a single dispatch system. Sadly, I seem to have misplaced the PDF (Just more proof I need one of those Sony Reader things...)

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

More importantly, the reference-based-nature make it much easier to change a method in a class and have the right thing happen. With R it's unclear if you could make sure that all copies of a function are accounted for without resorting to walking the image.... Sort of like the problems with posing in modern Smalltalks.

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

Actually, R's argument list is more like a dictionary than it is like a Smalltalk or C-style argument list so I'd probably opt for something with a Dictionary-like structure if I were building something in Smalltalk. Hmm, R is Dicts all the way down!

However, this illustrates the point of WHY you might want a domain specific language for statistics in Smalltalk. There are somethings that the Smalltalk syntax is just sort of clunky for doing and the sorts of manipulations we commonly do in R is one of them. By the same token some things are a pain to implement in R. User interfaces come to mind. Of course the entire thing would be built on some sort of Smalltalk analysis structure so you wouldn't have to use the R-style if you didn't want to.

> 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

Oh, I tend to agree. I really enjoy Smalltalk development (except for the default lack of reasonable Emacs keybindings...) and there are some really powerful tools in there, not to mention things like Seaside. For example, I was thinking just yesterday that it would be really cool if you could attach a Graphics Device to a VNC server and let people with VNC clients log in and write on the Device John-Madden-Telestrator-Style (henceforth known as Collabotron 3000. It's my idea, I get to name it. :-) ).

In Squeak this would be pretty easy since there's already a VNC server (and client) implementation just lying around waiting to be used. Not quite trivial, but all the bits and pieces are there.

On the flip side, for me, all of these virtues are almost always outweighed by CRAN.

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

I think it does matter, the longer you can stay in the higher level language the better.

> Jeff
> ______________________________________________
> mailing list

Byron Ellis (
"Oook" -- The Librarian

______________________________________________ mailing list
Received on Thu Jan 04 11:24:22 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 - 01:31:06 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.