A couple updates from the Smalltalk world

I was going through my list of links for this blog (some call it a “blogroll”) and I came upon a couple items that might be of interest.

The first is, it appears that Dolphin Smalltalk is getting back on its feet again. You can check it out at Object Arts. I had reported 3 years ago that it was being discontinued. So I’m updating the record about that. Object Arts says it’s working with Lesser Software to produce an updated commercial version of Dolphin that will run on top of Lesser’s Smalltalk VM. According to the Object Arts website this product is still in development, and there’s no release date yet.

Another item is since last year I’ve been hearing about a branch-off of Squeak called Pharo. According to its description it’s a version of Squeak designed specifically for professional developers. From what I’ve read, even though people have had the impression that the squeak.org release was also for professional developers, there were some things that the Pharo dev. team felt were getting in the way of making Squeak a better professional dev. tool, mainly the EToys package, which has caused consternation. EToys was stripped out of Pharo.

There’s a book out now called “Pharo by Example”, written by the same people who wrote “Squeak by Example”. Just from perusing the two books, they look similar. There were a couple differences I picked out.

The PbE book says that Pharo, unlike Squeak, is 100% open source. There’s been talk for some time now that while Squeak is mostly open source, there has been some code in it that was written under non-open source licenses. In the 2007-2008 time frame I had been hearing that efforts were under way to make it open source. I stopped keeping track of Squeak about a year ago, but last I checked this issue hadn’t been resolved. The Pharo team rewrote the non-open source code after they forked from the Squeak project, and I think they said that all code in the Pharo release is under a uniform license.

The second difference was that they had changed some of the fundamental architecture of how objects operate. If you’re an application developer I imagine you won’t notice a difference. Where you would notice it is at the meta-class/meta-object level.

Other than that, it’s the same Squeak, as best I can tell. According to what I’ve read Pharo is compatible with the Seaside web framework.

An introduction to the power of Smalltalk

I’m changing the subject some, but I couldn’t resist talking about this, because I read a neat thing in the PbE book. I imagine it’s in SbE as well. Coming from the .Net world, I had gotten used to the idea of “setters” and “getters” for class properties. When I first started looking at Squeak, I downloaded Ramon Leon‘s Squeak image. I may have seen this in a screencast he produced. I found out there was a modification to the browser in his image that I could use to have it set up default “setters” and “getters” to my class’s variables automatically. I thought this was neat, and I imagine other IDEs already had such a thing (like Eclipse). I used that feature for a bit, and it was a good time-saver.

PbE revealed that there’s a way to have your class set up its own “setters” and “getters”. You don’t even need a browser tool to do it for you. You just use the #doesNotUnderstand message handler (also known as “DNU”), and Smalltalk’s ability to “compile on the fly” with a little code generation. Keep in mind that this happens at run time. Once you get the idea, it’s not that hard, it turns out.

Assume you have a class called DynamicAccessors (though it can be any class). You add a message handler called “doesNotUnderstand” to it:

DynamicAccessors>>doesNotUnderstand: aMessage
| messageName |
messageName := aMessage selector asString.
(self class instVarNames includes: messageName)
ifTrue: [self class compile: messageName, String cr, ' ^ ', messageName.
         ^aMessage sendTo: self].
^super doesNotUnderstand: aMessage

This code traps the message being sent to a DynamicAccessors instance, because there is no method for what’s being called for at the moment. It extracts the method name that’s being called, looks to see if the class (DynamicAccessors) has a variable by the same name, and if so, compiles a method by that name, with a little boilerplate code that just returns the variable’s value. Once it’s created, it resends the original message to itself, so that the now-compiled accessor can return the value. However, if no variable exists that matches the message name, it triggers the superclass’s “doesNotUnderstand” method, which will typically activate the debugger, halting the program, and notifying the programmer that the class, “doesn’t understand this message.”

Assuming that DynamicAccessors has a member variable “x”, but no “getter”, it can be accessed by:

myDA := DynamicAccessors new.
someValue := myDA x

If you want to set up “setters” as well, you could add a little code to the doesNotUnderstand method that looks for a parameter value being passed along with the message, and then compiles a default method for that.

Of course, one might desire to have some member variables protected from external access and/or modification. I think that could be accomplished by having a variable naming convention, or some other convention, such as a collection that contains member variable names along with a notation specifying to the class how certain variables should be accessed. The above code could follow those rules, allowing access to some internal values and not others. A thought I had is you could set this up as a subclass of Object, and then just derive your own objects off of that. That way this action will apply to any classes you create, which you choose to have it apply to (otherwise, just have them derive from Object).

Once an accessor is compiled, the above code will not be executed for it again, because Smalltalk will know that the accessor exists, and will just forward the message to it. You can go in and modify the method’s code however you want in a browser as well. It’s as good as if you created the accessor yourself.

Edit 5-6-2010: Heard about this recently. Squeak 4.1 has been released. From what I’ve read on The Weekly Squeak, Squeak has been 100% open source since Version 4.0. I was talking about this earlier in this article in relation to Pharo. 4.1 features some “touch up” stuff. It sounds like this makes it nicer to use. The description says it includes some first-time user features and a nicer, cleaner visual interface.

Advertisements

3 thoughts on “A couple updates from the Smalltalk world

  1. Pharo was (rightfully) created when the Squeak core dev was stifled because of conflicting goals, and did a lot of really useful work.

    However, the Squeak core dev has been reinvigorated by Andreas Raas in the past few months, and is rapidly catching up to the Pharo development, if not surpassing it in some ways (unloadable Etoys and micro-Traits come to mind). And Squeak core is about to be blessed officially as MIT licensed with a legal body with money to protect it, unlike Pharo core which is only self-declared as license clean. Most of the commits of Pharo are also being taken rapidly into Squeak core, so the differences are getting smaller day by day.

    At this point, if you’re starting fresh, consider the Pharo core to be an interesting necessary temporary diversion, but Squeak core is where the real stuff is happening again, so base your projects there.

  2. I love DNUs. I miss Squeak. I’m spending too much time with XCode’s debugger, which loves to step me through assembler . . . there are no turtles down there.

    Thanks for the ST update.

  3. @Bob:

    I’ve thought from time to time about doing some programming on the Mac. So far I’ve heard of a few avenues for that, like AppleScript, F-Script (which I’ve heard is like Smalltalk using Cocoa), and RubyCocoa, not to mention Objective C. I’ve heard that XCode is not that great of a development environment compared to Microsoft’s tools. I have no way to judge. I used Microsoft or equivalent tools for several years, but I have not gotten into any development on the Mac yet.

    What you describe about XCode’s debugger sounds a bit like what I used to experience with Visual C++ on Windows. Every once in a while, while I was using its debugger, I’d step into a DLL which did not have accompanying source code, and had no debugging symbols included. It also wanted to step me through assembler code. I tried to get out of there as soon as possible! This was unavoidable though if I was attempting to debug an application crash on a customer’s machine. Any time an app. crashes, Windows produces what’s called a “Dr. Watson dump” that can be loaded into the VC++ debugger. If you’re familiar with Unix, this is the equivalent of a “core dump”. The debugger would only show assembler code in these dumps, showing where the fault occurred. If the app. was compiled with debug symbols included, it would do the same thing, but I would also be able to see some symbols, which were recognizable from the C++ code, and I could roughly locate where the problem was.

    Unix’s system of core dumps, and using db, or gdb, is better than Windows’s system, because it’ll actually show you the C/C++ source code where the problem occurred. Of course, I know what you mean about missing Smalltalk. There’s nothing like hitting a problem and just being able to inspect the stack, and “debug and continue”, all in Smalltalk code.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s