When someone describes someone else as "long in the tooth" you know what they mean: That the target of the soubriquet is getting on in years.

OK, but do you know where that phrase comes from? The answer is from the horse world: Horses' teeth grow throughout their lives and, despite getting worn down by chewing hay and such, horses show progressively more enamel as they age. Thus, you can roughly tell the age of a horse from how "long in the tooth" it is. Now you know.

Anyway, should you also be "long in the tooth" you'll remember a programming system called "HyperCard."

Created for Apple Computer and released in 1987, HyperCard was the first "hypermedia" system, a term coined for a hyperlinked collection of various forms of media (text, video, audio and so on) that creates a non-linear multimedia presentation; what are essentially complex, engaging rat holes of content that can suck you into their yawning limbo for hours on end. In other words, exactly what the Web has become.

HyperCard also had its own language called HyperTalk, which eventually evolved into Apple's AppleScript.

HyperTalk had an almost English-like, chatty quality described in that classic of hacker literature, the Jargon File under the heading "candygrammar."

The Jargon File explains candygrammar as "a programming-language grammar that is mostly syntactic sugar … The usual intent of such designs is that they be as English-like as possible, on the theory that they will then be easier for unskilled people to program."

The File continues: "This intention comes to grief on the reality that syntax isn't what makes programming hard; it's the mental effort and organization required to specify an algorithm precisely that costs. Thus the invariable result is that 'candygrammar' languages are just as difficult to program in as terser ones, and far more painful for the experienced hacker."

We'll revisit the candygrammar issue a little later, but for now here's an example of HyperTalk programming from the  Wikipedia entry to give you a flavor of the language:

on mouseUp
    put "100,100" into pos
    repeat with x = 1 to the number of card buttons
        set the location of card button x to pos
        add 15 to item 1 of pos
    end repeat
end mouseUp

Pretty chatty, eh? Anyway, HyperCard was a groundbreaking concept and existed as a product for sale until 2004, the year it was officially terminated (it had not been updated for some years).

The importance of HyperCard in computer and Internet history cannot be underestimated: For example, Ward Cunningham, considered to be the father of Wiki, contends that a HyperCard stack he wrote in the late 1980s was the genesis of the whole Wiki concept.

I don't have the space (or patience) to delve into the rest of the labyrinthine history of HyperCard and HyperTalk here but, suffice it to say, pretty much everything to do with both was either groundbreaking or just plain cool and, thus, was a legend born.

A derivative of HyperCard was a product called MetaCard, which has been described as "a cross-platform, commercial GUI toolkit."

Metacard was acquired by a Scottish company, Runtime Revolution, in 2003, and they re-engineered it to become the product that we'll be taking a close look at in the next column or two: Runtime Revolution.

Revolution is a complete rapid application development system that includes a graphical IDE and debugger with cross-platform support for Windows, OS X and Linux.

At the heart of Revolution is a HyperTalk-like language that is object-oriented and event driven. This means that Revolution applications are driven by events such as "key down" or "mouse over" that are associated with objects such as buttons and text fields. System events are also generated by, for example, the start of a Revolution application or a timer.

These events are captured by a hierarchy of event handlers (I'll explain the hierarchy in a subsequent piece), which contain scripts. These handler scripts can do all of the normal things programs do (such as access files and databases and write to the display), but they can also handle event data (such as the result of a key press) and can, in turn, generate their own events.

By now you are probably all kinds of excited by the idea of Revolution but you'll have to wait for next week's Gearhead for the next exciting episode as I've run out of space.

A great part 1 in a 3-part series of articles on Revolution!

Last week here in Gearhead I started to discuss a fascinating and powerful programming system called Revolution.

I explained that Revolution is event driven and every event generates a message: For example, starting a Revolution program (which is an event) generates a series of start-up messages, while clicking on an object (also an event) such as a button generates a series of mouse messages (for example, mouseOver, mouseDown, mouseDoubleDown, mouseStilldown, mouseWithin and mouseUp). There are around 200 messages generated by events and Revolution scripts can also generate their own messages.

Before I explain how these messages are handled I need to explain how a Revolution application is organized. A Revolution application is contained in a file and consists of one or more "stacks" (a main stack and optional substacks), each stack containing one or more "cards". Using Revolution's graphical, integrated development environment (IDE) you can create stacks and cards and add objects to them using drag and drop.

Now, everything in a Revolution application is an object including the stacks and cards. In addition, there are also objects users will interact with (also called "controls") such as buttons, labels fields, text fields, sliders, combo boxes and so on. These get positioned on the graphical layout of cards and can be grouped, making yet another object.

All objects have properties which you can browse and modify using the IDE's property inspector and, beyond the visual attributes (for example, the existence, size, width and color of the borders of a text field) and the control properties of objects (such as whether a text field is enabled and visible) there are scripts that are contained in objects.

Scripts consist of handlers of which there are four types. Message handlers receive messages while function handlers return values when called by scripts. The other two types are special ones that are triggered by requests to get or set object properties.

Scripts can also use functions stored in libraries that add features such as printing, Internet services and manipulate XML data.

So, here's the Revolution script for a simple pulldown menu object (Revolution considers these to be a type of button) called "mainMenu". This menu object displays three options, "Do This", "Do That", and "Status":

on menuPick pItemName
     switch pItemName
          case "Do This"
               <some code>
               break
          case "Do That"
               <some more code>
               break
          case "Status"
               <yet more code>
               break
     end switch
 end menuPick

When the user changes the menu selection a message is generated that consists of "menuPick" and the selected item's text. It is left for the reader to figure out how the switch construct works, but I doubt you'll break into a sweat.

Now, if we wanted to add a button somewhere in the user interface to also show the status we could place a button object to the card with the following script:

  on mouseUp

      send "menuPick Status" to button "mainMenu"

  end mouseUp

You can probably guess what is going on by reading the script. But what if there was no "mainMenu" button object? Well, then the message would be sent down the message path.

This path really starts with the "frontscript" where handlers can be placed to trap system or user generated messages before any other handlers further down the path, including those in the object's script, can do anything with the messages.

If there's no handler in the frontscript or the object's script and the object is a member of a group then the message is passed to the group's script. If there's still no handler the message gets passed to the script of the card the object is on, then to the "background" script (backgrounds are groups for cards), then to the stack the object is on, then to the main stack if the object is on a substack, then to the "backscript" (a catchall step on the path and the group of all stacks). If there's still no handler the message is passed to the Revolution engine, which will then execute the default action for the message and the object.

For example, if a key is pressed in a text field object, a "keyDown" message is generated, which includes the key that was pressed. Obviously a handler could be placed anywhere in the path to trap and remove or modify keyboard data as it is entered, but if there isn't one then the Revolution engine will get the message and do the default action for that object, to wit, update the text field display.

In other words, using Revolution you can handle system and user events at any level of detail providing as fine-grained control over the user interface and application behavior as you need.

Next week, into the "candygrammar" of Revolution.

A great part 2 in a 3-part series of articles on Revolution!