This sentence is false

  • 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!
Continue reading “This sentence is false”

Visual Assist

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.

RSS in Smalltalk

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.