Another highlight of my trip to Amsterdam this week was meeting Avi Bryant, of Seaside fame. We talked about Smalltalk, web programming, and his latest project, Dabble. In the past, I've had trouble knowing where to begin with Smalltalk, so he sat down with me and walked me through building a simple program. It was enough to give me a flavor of the language, and to get me started if I want to experiment with it at some point (no time these days!). It's an absolutely breathtaking language. I am still skeptical about excessive reflection. It's clearly extremely powerful, and attractive in its conceptual simplicity. But I generally favor a careful balance between expressive power and local reasoning, and Smalltalk seems to tip awfully far towards the former. Nevertheless, I'd need to learn more and build real systems in Smalltalk before making judgments.
The way Avi designed Seaside leads to a beautiful style of web programming. Of course, there's the fact that the control flow is both compatible with the back button and window cloning and written in a natural style, thanks to continuations under the hood--but that's no surprise. It's in fact roughly the same approach as send/suspend/dispatch (though with the rather more friendly method name renderContentOn). But what I really enjoyed was the object-oriented approach to modeling the components of a web page.
In Squeak, essentially every component in the entire VM--numbers, blocks (closures), windows, stack frames, metaclasses, you name it--is represented as a Smalltalk object, with some particular set of supported methods and various ways to view it. The "system browser" provides a useful view: it introspects the object for its properties and their values, its methods and their source code, and any associated documentation, and displays them in an informative GUI window.
In Seaside, web pages can be seen as simply a different view on objects (that have special methods for rendering on the web, of course). When you change properties of a web component, its web view changes accordingly. Usually, these changes in state are triggered by user actions via the web: clicking links or submitting forms. If you change the property through the Squeak UI, then you can just reload the web page to see the changes. Most impressively, if you change the source code of a method on the object--say, the code that responds to a user action--there's no need to reload whatsoever! The next action simply invokes the method, which now happens to have a new implementation.
Subscribe to:
Post Comments (Atom)
1 comment:
Welcome to Smalltalk! You will find as you get into it that you really get both expressive power and local reasoning. After a while you begin to think globally and when a problem comes up and you want to add something everywhere. The power comes to your rescue.
We had an application where we wanted to add "F1" to every screen to allow it to bring up context specific help. Yes we should have written it up front but we didn't. I took a look at the problem and in 2 lines of code we had what we needed. After that all that was necessary was building context and that was done from the application by the documentation team.
Yes the power can have unexpected effects to the whole system, which is the reason that some argue that OOP is non-provable, but in my experience that power once fully understood includes local reasoning.
Isolating code for local context is very easy to do. There are a lot of tools available to you, like subclassing, and polymorphism that help you to make your intentions clear.
This is where the myth of self documenting code comes in. Good class and method names, class comments and method comments can really help keep others from stumbling into your local code. Also contact programming documentation can really help but smalltalk does not have contracts as a formal concept.
Anyway welcome to the wonderful world of Smalltalk!
Post a Comment