Neil's News

Larval mode

26 August 2003

This weekend I've been writing a program that generates last wills and testaments for a new client. After a bit of research, I chose to use Microsoft Word's VBA. It turned out to be perfect for the job. Furthermore, I've found VBA to be the easiest programming environment I've ever seen. Don't get me wrong, it's horribly buggy, the VB language is unbelievably weak, there's no security, it crashes regularly, and generally behaves like what we've grown to expect from Microsoft. But there are two features of VBA which outweigh the Microsoftyness of it:

The first is that VBA is grafted onto the side of Word (and the Office suite, and the Corel suite and lord knows what else). With the ability to manipulate these applications, even a toy language like VB suddenly becomes monstrously powerful. This isn't news; everyone knows the advantage of using an environment which has large libraries or capable interfaces.

What's really caught my attention is the second feature, the macro recorder. Normally programmers who are new to an environment have to 'go larval'^[?] until they've acquired an understanding of the basics. VBA has found a way to drop this step. To code an action in VBA one doesn't have to remember Microsoft's Byzantine API, one just starts a macro recording, performs the action manually inside the application using the normal human UI, then stops the recording. The code that was generated for the macro can be examined, imported into your program, then tweaked to make it dynamic (replacing fixed strings with variable names, adding loops and other control statements, etc).

So for example, if you want to find all instances of "oldText" and replace them with "newText" in red, just do so using the normal Edit|Replace menu option, then inspect the resulting macro code. There's nothing magic about that code; it is just a bunch of calls to Word's complex API. You could have gone larval, inhaled the docs, then written it without the macro recorder. The point is you didn't have to. Everyone has already learned the API designed for humans (menus and buttons), why force them to learn a new API?

Mozilla

The Mozilla suite is another extremely powerful collection of applications which is scriptable (with JavaScript instead of a lobotomised version of Visual Basic). One can use it to build lots of useful tools (MOOzilla springs to mind). But it would be infinitely easier to use if it had a macro recorder similar to Microsoft's. Let's say you wanted to be notified the next time Slashdot runs a story about SCO. Start recording a macro, open a new tab, load slashdot.org (or better yet the RDF file), find the string 'SCO' in the page, compose an email to yourself, press send, close the tab and stop the macro. The resulting JavaScript commands do 90% of the work. All you'd need to do is add one 'if' statement around the mail composition so that it will only send mail if the find was successful. Hook the script onto some sort of event timer (or while(1) with a sleep) and you're all set. Far easier than combing through Mozilla's API docs researching how to make each call. Currently only a Mozilla guru would think about using Mozilla for quick automation scripts like that. With a macro recorder to do the bulk of the human UI to CPU API translation, anyone could do it.

Moo

Players on the Moo learn simple commands to get around. Builders extend this vocabulary of commands. Programmers throw away everything they've learned so far, and start from scratch. For example, a builder uses
  @lock here with me || ^$key
whereas a programmer uses
  this.location.key = {"||", player, {"^", $key}}
The second API is a barrier to entry that we could do without. I don't know if the Moo is capable of bridging this gap. Could a command-to-code translator be built? (some commands are complex) Could use of force_input() be extended? (some commands are state sensitive)

Microsoft's approach to VBA wipes out the larval stage. Mozilla and the Moo are both infinitely more solid environments than Office. How can we get the best of both worlds? Food for thought.

< Previous | Next >