How xTalk Syntax should be

When I talked to Doug Simons at the WWDC Apple Campus Bash, one thing he said that I hadn't even realised myself yet was that he had the impression I had a very clear picture of how a modern HyperCard and HyperTalk had to be. Thinking about it a little, I realised that he was right, and I also realised that I hadn't written about it yet. So, I'm going to do that now, as far as I have managed to put it in words so far:

One of my main sources of inspiration on how HyperTalk should look, incidentally, comes from AppleScript. AppleScript allows for multi-word commands and methods, so it really should be every xTalker's wet dream. Instead, it constantly complains about data types, and it lets you write sentences that simply aren't English (and I'm not talking about the French AppleScript dialect here...), and because it's a modular language into which every application plugs its own set of commands and syntax, it can be horribly inconsistent. Which is something none of the AppleScript developers can be blamed for.

So, here's a few rules I've come up with for creating "good" HyperTalk syntax:

1. Make your commands, functions and identifiers correct grammatical English, or at least some sort of telegram-style English. This mainly boils down to making commands imperative sentences and making your parameter labels read like parts of a sentence and not just like lists of ... stuff. The most egregious violator of this rule in HyperTalk itself is probably the answer command, or more precisely, its variants answer file and answer program. That's also where the clones picked up some ugliness for commands like alert.
   Why? Because people need to memorise the syntax, and we already have cryptic languages that have arbitrarily restricted syntax. The point of xTalks should be to try to get rid of as many restrictions as we can, so users just have to remember the vague sentence content and the language skills they've been honing all through elementary school will take care of the rest.
2. Another rule that I'm still trying to work out the full repercussions of is that HyperTalk has no data types. Some people phrased this as everything is a string, which is probably a rule that works most of the time. The thing is, in the real world things actually do have types, it's just that they don't have just one type, they have several at once. (I'm talking about the image presented to the user - it's fine if you store values as typed data internally to make things go faster.)
   Why? Think of text: When you write text on a sheet of paper, not only is it made up of a string of characters, it may also contain numbers, tables and even graphics. Furthermore, it's a physical object, a piece of paper, which can have a colour, texture, shape... lots of additional cues that may or may not be relevant to your use right now. However, - and that's the sticking point - our use of real-world objects changes over time. One moment a newspaper can be a source of information, the next it is a makeshift fly-swatter, the next it's used for wrapping gifts.
   So really, that some clones show associative arrays as empty when used as a string may be wrong. Maybe we should really show a string representation instead, maybe XML or old-style Plist format or whatever. Maybe all the user should see would be good old delimited item lists with specialised syntax that takes care for you to escape commas and stuff?
   I don't have absolute answers, but the point is that real life really deals in multiple selective views on the same data, which is why so many programmers fall in love with the Model-View-Controller paradigm. Maybe we should now take this abstract model that seems to represent the world so well and bring it back into the real world and offer an easily understood analogy?
3. Give everything a strict, logical syntax. The problem with Point #1 above is that a computer really doesn't understand natural language. So, everything we're doing to make stuff more realistic beyond a certain point ends up making the experience more frustrating. In robotics this is called the uncanny valley, and what Drunkenbatman applied to AppleScript.
   Basically, if you make a script sound too English, people will not be able to discern the rules it works by anymore, and will just throw real, complex English at it, and constantly be disappointed by the wrong answers and error messages they get.
   Take, for example, Inform 7. It has a beautiful, English language that lets you describe rooms and complex actors and objects in a text adventure, but sometimes it will just tell you it can't understand a perfectly valid English sentence and leave you to figure out what you did wrong.
   Due to this problem, it can be really helpful to try and stick to a clearly-defined subset of real English that is coherent and lets your users discover additional features of one command just through their knowledge of another. So, consistency helps, but where it doesn't, you'd better have a syntax table somewhere so people can look up the rules if they feel they need to.

Update: Clarified the bit about data types a little.

Reader Comments: (RSS Feed)

Craig S. Cottingham writes: "One moment a newspaper can be a source of information, the next it is a makeshift fly-swatter, the next it's used for wrapping gifts." You wrap gifts with paper you just used to swat flies? :-)

Comment on this article: Name: E-Mail: (not shown, hashed for Gravatar) Web Site URL: (optional) Comment: (plain text only) Please Enter the following word:

Or E-Mail Uli privately.