Neil's News

+ 2010
+ 2009
+ 2008
+ 2007
+ 2006
+ 2005
+ 2004
- 2003
 Christmas Spam
 Mission Accomplished
 Particular Sounds
 Mooving right along
 Going Native
 MUDzilla
 Sitefinder T&C
 Inverness Bridges
 Public Relations
 Old Friend
 Canada
 Larval mode
 Many Moo Menus
 Remote Reboot
 Search Highlighter
 More Chain Reaction
 Java Chain Reaction
 Updates & Upgrades
 Silly Quotes
 Summer Solstice
 No Picnic
 SlashProxy
 Wheel Shapes
 Image to HTML
 Windows Parallel Ports
 SETI@home
 Democratic Bugs
 Political Irony
 Gray Code
 ScotRail
 iPIX
 April Fools
 Signs
 Schrödinger's Cat
 Danger Pay
 Highland Life
 New Math
 Elgin
 Veeblefester
 Triana
 Post Columbia
 Work work work
 First Snow
+ 2002

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 >

 
-------------------------------------