AppleScript - a story worth telling

"... I believe that the development of AppleScript is a story worth telling, and I have been encouraged to attempt it despite the inherent difficulty of the task. I can only offer my own subjective views on the project, as someone who was intimately involved with all its aspects. ..."

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Not Much to Add

But FWIW, I was the MacDTS engineer tasked with supporting AppleEvents and AppleScript in the 1989-1991 timeframe. Good times. If anyone has any questions about my impressions of this material, I'd be happy to address them as best I'm able.

Except he omits the original Mac scripting solution

He gets MacroMaker, and QuicKeys - but these were direct copies of Tempo, the first of the keystroke macro recorders and the first to support plugins and control structures (it could even branch on whether a bitmap matched a screen region).

FWIW, I was manager of tech support at Affinity when Tempo's plugin architecture and first set of plugins was released. I can recall some amazingly complex macros being built - some that ran for hours.

Related Systems

The Amiga accomplished something similiar by equiping applications with "ARexx Ports" which allowed them to be externally scripted with the ARexx language. This was very popular on the Amiga and most applications provided ARexx ports. ARexx predates AppletScript.

Sun also had something similiar called ToolTalk but it never became popular:

Thanks for the article. I found it very interesting.

Thanks for the comments

I'm in the process of revising and finishing the final draft. If anybody has any other comments, I'm happy to get them. I'm sorry about the omissions... I have to admit that I don't remember ever hearing of Tempo. But there are lots of cool things that have been done... I am sure I don't know nearly the full story.


Nice Job!

William, I think you did a very good, thorough job (perhaps apart from overlooking MacDTS' role ;-) ).

I regret that I can't recall the name of Tempo's developer offhand: he was an acquaintance whom I met at my first Mac trade show, in Chicago—this was very early, before MacWorld was even being published. But regardless, Tempo was an amazing piece of work, especially at the time.

Claris could've helped

I've never understood why Claris products weren't used as test beds for new Apple APIs. I think Microsoft APIs are so successful because they are first consumed internally.

I'll Field This One...

...there was intense political aversion at Apple to being seen as treating Claris with any kind of favortism with respect to supporting their adoption of new OS features. What we (at Apple in general, and MacDTS in particular) did do in the System 7.0 timeframe was to (quietly) select 13 (un)lucky(?) developers to bring on campus and assign a pet MacDTS engineer to, supporting them in their efforts to make their products System 7.0-savvy. I can't recall if Claris was one of the 13 or not, but probably not. The developer I was assigned to was Ragtime GmbH. They were considered important because they had the best integrated productivity package for the Mac (IMHO, they still do); I was assigned to them because I was one of two German-speaking MacDTS engineers at the time.

In any case, my recollection of this experiment is that it didn't go very well: the results seemed to inspire neither users nor other developers. What I think would have made a bigger difference would have been Apple committing to a) making MacApp the way to develop Mac software the way Microsoft did with MFC, and b) staffing MacApp appropriately to ensure that it provided OS feature support rapidly, i.e. so that MacApp developers were System __ savvy as automatically as possible. But Apple of this generation didn't really have object religion the way that Steve Jobs' Apple does. Unfortunately, they didn't have a replacement religion, either.

An interesting read

Have any other languages ever gone through the kind of usability testing that Apple applied to AppleScript?

Programmer's Dialect

The evaluation remarks that the English-like syntax was perhaps not such a great design after all, and

In hindsight, we believe that AppleScript should have adopted the Programmer's Dialect that was developed but never shipped.

Perhaps I have misunderstood AppleScript's structure, but is it too late to do anything about this? If scripts are stored as some kind of linearised ASTs anyway, then wouldn't a new "conventional" notation be easy to add? In contrast to the Japanese and French localisations, there would be no need for applications to change as the new dialect could re-use the English names for entities and actions.

Programmer's Dialect

Perhaps I have misunderstood AppleScript's structure, but is it too late to do anything about this?

Apple dropped dialect support around OS 8.5, and I doubt they'd have the spare manpower or inclination to resurrect it now. If it's any consolation though, some of the OSS scripting languages are finally starting to get decent application scripting support (I wrote the Python bridge, btw), so at least traditional programmers who don't much care for AS should have some alternatives for doing that.

FWIW, I do think it's a pity they didn't ship AS with both English and Programmer dialects. The English syntax is ideal for inferring the intent of a script, even without knowing the language, while the Programmer syntax's explicit, unambiguous semantics would have been better for understanding the actual mechanics. Users could then switch between the two on the fly to provide whichever view they find most appropriate at the time. Still not an ideal solution, mind you - an intelligent structure editor a-la Alice would have been much more appropriate for the job than a dumb character buffer, - but it would've at least gone some way to compensating for the English syntax's inherent weaknesses.