« November 2004 | Main | January 2005 »

December 30, 2004

We're all wrong

The software industry migration away from Smalltalk to Java and .Net may be one of the greatest causes of lost developer productivity, although its impossible to quantify. I've never developed Smalltalk commercially, but I have played with it on numerous occasions, and the more I see, the more I like. It really was a language before its time.

Take for example, the hooking a GUI to a domain layer. You want a simple way to uniformly hook the UI to the domain layer, without leaking UI code into the domain objects. The Smalltalk way is this:

| aspect | 
  aspect := AspectAdaptor subject: aDomainObject.
  aspect accessWith: #getSelector assignWith: #putSelector 

The above code says: create an instance of the AspectAdapter class, assign it to a variable called aspect, and wrap it around the object referred to by the aDomainObject variable. Whenever you receive a request for data, call the 'getSelector' method of aDomainObject. Whenever the UI value is updated by the user, pass the new value to the 'putSelector' method of aDomainObject. As getters and setters in Smalltalk generally follow a convention, there's an even shorter way of writing the same thing:

| aspect |
  aspect := AspectAdaptor subject: aDomainObject.
  aspect forAspect: #iFieldName

Smalltalk is chock full of things like this, things that we threw out when we moved in favour of strongly typed, C-based languages.

December 29, 2004

Smalltalk in OS X

Maybe I'm just slow, but I only noticed yesterday that VisualWorks Smalltalk also runs on OS X.

There's also Ambrai Smalltalk, which, while still in beta, has a more native look-n-feel, plus Cocoa integration.

December 24, 2004

Christmas in Sydney

Christmas lights on palm trees. Wierd.

December 14, 2004

Script Cocoa in Smalltalk

F-Script

Fusion of Cocoa with the power and syntax of Smalltalk. Sweet.

December 13, 2004

Lake effect snow?

...You can keep it.

December 08, 2004

Spaces on a shoestring

What if an application used an irc channel as a (Java)Spaces implementation mechanism? That would be cool. Persistence could be manged by an IRC bot running on the server (or, indeed, any node) that logged all the messages.

Encryption? Any standard mechanism (RSA, blowfish etc) plus base64 encoding should take care of that.

Wonder if anyone's implemented this idea yet?