On 03 Jan 2007 10:42:38 -0500, Jeffrey J. Hallman <[EMAIL PROTECTED]> 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
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Byron Ellis ([EMAIL PROTECTED])
"Oook" -- The Librarian
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
