Andrew Birkett's blog

From LtU, A brief introduction to Naked Objects. This sprung up in response to a question on squeak-dev along the lines of “if squeak if so OO, why do we use so much ascii text?”. This is closely related to work done on the Self language, which I looked at a few weeks ago. Self is a runtime-typed OO language, but without the notion of classes. Objects aren’t instanstances of a class. They just are. Self also has a morphic-esque direct manipulation GUI whereby you can leap in an manipulate any object directly. The big idea behind Self is one of a consistenly present world of manipulatable objects, much like the real world. Unfortunately, the Self runtime is only available on Mac and Sparc, of which I have neither, so I can’t play with it. But, the ideas are interesting. C++ certainly doesn’t present a “consistent” view of the world – using a std::map from the “source world” and using it in the “executable world” with the debugger are as different as night and day. Or at least they will be until someone writes a nice debugger plugin API for displaying custom types.

The other gem I’ve recently discovered is the ever-popular Big Ball of Mud programming pattern.

• I write programs to solve problems.
• I spend a lot of time writing these programs.
• During this time, problems relating to programming pop up.
• I want to solve these problems too!

If you want to start writing tools which manipulate programs, you require a vocabulary which includes nouns like “type” and “function” and “literal”. Most sane people think of, say, mozilla as a program which you execute, but today I’m thinking of it as a dataset. I’m not going to run mozilla – I’m going to process it!

Although I play with lots of different languages, work is a C++ shop. Until recently, I’ve used a combination of DevStudio (for code writing and debugging) and emacs (for oo-browser, pcvs and ediff). A few days ago I downloaded the eval of Visual Assist and I’m amazed that I’ve been without it for so long. Actually, I think I tried a very early version once and wasn’t impressed.

It basically does auto-completion and tool-tip API hints reliably, which is more than can be said for DevStudio. This means you spend more time editing code, and less time flicking through API documentation – a very good thing. They have a decent parsing engine in there too, so they can do “find next/prev usage of symbol” too. I’ve now written my own DevStudio addin which uses this feature to provide a “rename local variable” refactoring.

It would be very sweet if they were to expose an API to their symbol database. I could do so much with it …

Incredibuild was my other find recently. It’s a distcc for DevStudio, and again it works well. Anthony has already blogged about how we use it.

Squeak 3.5 has been released, so I’ll be looking at the improvements sometime soon.

I read a quote somewhere along the lines of “once you’ve tasted Smalltalk, nothing tastes the same”. Okay, that’s a parody of a beer advert – I can’t find the actual quote now. But I’ve tasted smalltalk and I’ve tasted lisp, and now writing in C++ gives me the shivers. Edit-compile-test cycle? No thank you! And here’s why …

Yesterday, douglasp blogged about his Smalltalk RSS reader. What is particularly neat is the way he appears to handle XML (more details forthcoming, I’m filling in the blanks here). Usually an XML parser will slurp in your document and then allow you to do calls like document->GetField(“title”). Now here’s where Smalltalk kicks in to solve two problems.

Problem #1 is that it’s quite clunky to have to call the “GetField” method when actually what you’re doing is accessing some data in the object. It’d be nicer if we could just call document.title.

Following from that, problem #2 is that we might make a mistake and ask for “titel” by accident. What happens then?

Smalltalk allows you to build new types at runtime and the instantiate them. This means that our XML reader can figure out the structure of the XML document (or read the DTD) and the build a new type for it. You can’t just access the data “in an object-like manner” – it really is a first class object. If there’s a “title” tag in the document, our object can have a “title” accessor so that we can just say document.title. These aren’t “fake” objects or types in any way. They are 100% pure smalltalk objects and types which your program decided to build. After all, any class which you create using the System Browser appeared in a similiar puff of smoke into the smalltalk world. Your XML reader class can build new types just as well as the System Browser can. That’s one of the great things about Smalltalk – no part of the system has “magic power”. If the debugger can do something, you can do it in your code. If the Browser can create new classes, you can do it in your code too.

This XML parsing technique only possible because Smalltalk is run-time typed. Clearly, you can’t assign a static type to XMLReader.Parse() call if it only invents the return type at runtime.

This also leads to an elegant solution for problem #2. If you mistype “titel” then you will get the standard smalltalk “don’t understand message” error and you can then drop into the debugger and sort your problem out. You don’t need to remember any special rules like “GetField() return NULL if the field doesn’t exist”. It’s all just vanilla smalltalk, and everything works like you’d expect.

Today is a “yay, dynamic languages” day.