Blaine Buxton: Positronic Vibrations From Alto Dorado

One aspect of Smalltalk that I love is the way source code is presented. I'm not shown a huge file, but a short concise method. It's source code in bite-size chunks. Contrast this with other environments and you have quite the opposite. Now, Eclipse does allow you to see source code at the method level, but it is not the normal mode of operation for java developers (in fact, most hate it or don't know you can do it).

It amazes me that so many developers still embrace editing huge text files. They find what they need with such generic, clunky tools as grep and vi. Smalltalk stores my code in objects, thus allowing me a richer set of search and edit capabilities. I have a meta-model that I can use to walk my code objects. It allows me a freedom of expression that files can not simply even compare. Files are a generic medium to which I can store anything, but do I want to directly manipulate my code with it? If you really think about it, Smalltalk's code objects are nothing more than a DSL for development. And while non-smalltalk developers are finally seeing the benefit of DSLs in business software, why not take their own medicine? Why wouldn't you want to deal with your source code on a higher level? Is it familiarity with their old ways and unwillinglyness to change?

With that being said, I love to research different languages and the thoughts that go into the design of them. It's rare (ok, almost NEVER) for a language to come with an interactive development environment that allows me to search and manipulate the source as objects. The scripting languages give me an interactive environment, but getting hold of the source of a running system is only available via files. YUCK. I learned this the hard way when trying to add unit test comments to Ruby. I thought all I had to do was to walk the classes of my objects and ask the methods for their source. Nope, I had to invoke a parser to get that information. Well, that's fine and dandy, but Ruby is dynamic and methods can change at run-time. The code in the file could be different than what is actually running. Contrast this to Smalltalk where I can even ask an arbitrary block what its source is! Of course, I hear the Lispers snickering in the back because their data is the source. But, emacs is still the status quo in lisp circles. Please.

Why all of this talk about source code in Smalltalk? Well, not having source in files, allows one to play around with how to display the source. If you have an object model around your code, you can choose alternatives of display. Squeak has a plethora of browsers (OmniBrowser, StarBrowser, and Whisker just to name a few) and VisualAge has the excellent TrailBlazer. Each one is different and shows the code in different ways, but none of them had to have a parser to do them because they are simply walking an object model! This makes common operations such as saving, refactoring, creation, and inspection to be handled uniformly. Now, you can do the same types of things from a file-based system, but it's much harder. All of the cutting-edge code browsers, that I have seen, have come from the Smalltalk community (I haven't played with Self yet). I think the reason is because of the ease of playing with a DSL for code than the generic low-level. It also allows us to write extensions more quickly if our tools do not support what we want. And the greatest benefit is to present the code in different ways. Powerful.

So, the next time you hear a Smalltalker fussing about source code in files, now you know why. By the way, the quote in the title above is from Kent Beck and is quite famous in Smalltalk circles. OK, I'll jump off my Smalltalk bandwagon today.

posted by Blaine at 10:37 AM |  3 comments |  Post a Comment