Saturday, July 09, 2005

Source code in files - how quaint

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.

3 comments:

Reinout Heeck said...

But VisualWorks Smalltalk still remembers a method's source as an ascii string. Seeing your appetite for other's ideas I think you'll appreciate the following transcripts from the Forth community cumulating to putting a Forth compiler plus sources plus OS in 9 Kwords:
Aha Talk
Enth & Flux

Anonymous said...

Lispers think that how you store source depends on the development environment and not on the language. Common Lisp does not say that you need to store source in files. You can eval and compile from Lisp datastructures. (ed 'foo) will bring the source for the function foo into an editor.

But the usual Common Lisp environment will remember the source location. M-. is the usual Emacs operation to find the source for a symbol. Several IDEs have extensive capabilities to locate the source. Browsers for functions, classes, etc. usually don't use the source, but the in-core data-structures.

Then there was also InterLisp-D from Xerox, which stored source as data - similar with what you would do in Smalltalk. But it went one step further. The usual program editor was directly editing the in-core source data-structure (which thus was not text).

So, there is no reason to look down on Lisp. It's IDEs have similar capabilities: source locators (even programmable), browsers and graphers working on rich, in-core datastructures, who-calls facilities, change tracking in the editor (compile changed), debuggers which can locate source code for blocks (and can resume/retry after changes) and much more...

Blaine said...

I stand corrected on the Lisp front. I've tried learning Emacs several times. I like the idea, but I get frustrated with the ease of use. So, I look at Emacs as an extensible text editor. I know the IDEs for LISP are just as good as the ones in Smalltalk and I meant no disrespect to the Lisp community. Contrary, I love Lisp and would love to work on a Lisp project. I find the Lisp way interesting and invigorating. In fact, Lisp has affecte the way I write code and in Smalltalk.

Amazon