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.
You and Your Research is an excellent talk made by Richard Hamming (of “hamming code” fame) in 1986.
On a related note What to do with things to do is a good idea for sorting out mental clutter. What do you want to grow or restore? What things just need maintaining? What should you prune and what can you close?