Applescript, the most unnatural natural language

Coming from a computer science background, Applescript is one of the most difficult languages to learn and use. Scripting languages should encapsulate different ways of expressing the same functionality. For example, most languages support conditional statements such as if-then/else, iteration (i.e., for, while, until), and some mechanism for sub-routines. In most popular scripting languages, operators are straightforward: plus and equal signs, brackets or braces, etc.

However Apple has created a language which throws off the chains of cryptic language conventions. Apple created Applescript, a programming language (of sorts) which is based on natural language. Sounds great, right? It will be just like writing a letter to mom. Let’s get started.

Dear Applescript interpreter,

Will you please start at the number 1 and count up to 1000 and do [something useful] each time you count up to the next number?

–your loyal user.

Applescripts response:

Dear Applescript user,

57974, error.

–signed Applescript.

(Read: ha! good luck with that. Your lucky I even gave you this stupid error message, you stupid loser. Learn a real programming language.)

The real problem here is that we as humans are really really good at expressing one idea in a nearly infinite number of ways, Applescript only captures and recognizes about 3 of those. So much for natural.

Next, in contrast to the premise of the language, Applescript documentation is horrible. For example, in the official online Applescript Language Guide, under “The Language At a Glance” we find this unintuitive explanation of the syntax for using handlers:

Handler Syntax
Subroutine definition
(labeled parameters)
( on | to ) subroutineName¬
[ of | in directParameterVariable
[ subroutineParamLabel
paramVariable] … ¬
[ given label:paramVariable[, label:paramVariable
[ global variable[, variable]…]
[ local variable[, variable]…]
[ statement]…
end [ subroutineName]

For a language whose motivation is doing it the intuitive and natural language way, it’s ironic that the official Applescript documentation is more difficult to understand than that of most other programming languages. It is far behind Java’s simple yet effective API, even Perl’s online documentation is better.

Also, finding answers to Applescript questions online is more difficult and less fruitful than analogous searches for help with many other languages. For my future reference and others, here are a few snippets that I found useful along the way.

Handling errors:

Use a try/end try block, and add an “on error” block to the end (no closing tag). Something like

    –code goes here
on error errorStr number errorNum
    display dialog errorStr & “: ” & errorNum
end try

Sub routines:

Here is a template for using a sub routine. Don’t forget the “my in the function call.

tell application “Finder”
    my mySub()
end tell

on mySub
    display dialog “in mySub”
end mySub

If you’d like, leave a comment to share your own tips.

14 thoughts on “Applescript, the most unnatural natural language

  1. I totally agree. I think AppleScript aptly demonstrated that any sort of “natural” language for programming proves it’s not only useless but it’s harmful; it’s unhelpful for neophytes, and it’s terrible for programmers. One of the sad things about it is the facilities that AppleScript has in terms of inter-process communication is actually really useful. How much time would be saved if you could just exercise some useful functionality in a GUI application and script it, or plug together a couple GUI applications instead of having to find some libraries and write your own program to automate stuff you don’t want to do by hand? Fortunately, there are some languages, like python, that have developed bindings to interact with these AppleScript-able applications.

  2. Shane,

    You’re right. I almost commented on that point while I was ranting. I love the model that Apple has set up here, they provide application developers a standard framework with which to expose their applications functionality. And more and more robust applescript dictionaries are being released with each new version of major applications .e.g. ms office controversially announced that they will not be supporting VBA in the next version Office for the mac – only applescript. And I personally can’t wait until my clients upgrade to InDesign CS3 since adobe has enabled “grep style” regular expressions for search and replace.

    The mac platform unquestionably provides the most advanced inter-process communications framework of any operating system when it comes to practical time saving scripting, but why do they have to do it with such a sucky language. I will definitely look into using a python applescript-like solution. I don’t have much experience with Python, but i have been playing around in Ruby (on Rails) lately, maybe somebody is working on a Ruby bindings for applescript functionality too?

  3. “Coming from a computer science background, applescript is one of the most difficult languages to learn and use.”

    For making sense of AppleScript, I’d recommend getting a copy of Matt Neuburg’s ‘AppleScript: The Definitive Guide’. Also, read the following paper by one of the original AppleScript designers for some useful insights:

    For Python, Ruby and ObjC bindings, see my sig. While you still have to cope with the many vagaries of individual applications’ scripting interfaces (including bugs, quirks and almost endemic lack of adequate documentation), at least you can avoid the hassle of dealing with the AppleScript language on top of that.

    BTW, note that Apple event IPC is actually based on RPC+queries, not OOP as it’s often mistaken for – more like XPath over XML-RPC than COM/DOM/CORBA. The OO-like syntax used by AppleScript and others can cause some initial confusion here, but once you understand how it actually works it makes reasonable sense.



  4. HTH,

    I opened that paper just take a look and got sucked in. I could have guessed that applescript would have such a convoluted history.

    Thanks for linking me to the alternatives to a language I don’t know extremely well yet but have already developed a love-hate relationship with.

    I have checked out a few library books on applescript in the past, including that O’Reilly guide by Neuburg. I especially appreciated the large library of small scripts that comes on the CD with that book. I still dig through the folder of them when I am stuck on a language feature I’m first encountering or when I’m bored and just playing.

  5. How is this natural if you must add ” end try”? That sounds like parser satisfaction…

    make a human readable SHORT language.

    Ruby comes pretty close (different to python you can omit the () if you want, that is a huge plus) but certain DSL languages come even closer without adding annoyances like “end try” which is NOT human readable.

  6. The AppleScript language itself, while annoying and verbose, would be worth learning if it was more useful, as in “Does what it claims to.”

    My biggest problems were incomplete and/or buggy applications, and no good way to know why things don’t work. Apple’s own Finder (haven’t tried lately, maybe they fixed it?) was famous for providing 6 ways to accomplish any given operation: 3 failed with meaningless errors; two appeared to succeed but did nothing or did something else; one might actually work, given the patience to find it.

    Granted, supporting AppleScript is extremely painful: PowerPlant tried, but even simple scriptability was still a nasty chore, far and away the worst part of a GUI program. Third party extensions/improvements to AppleScript never took off because the internals are so incredibly poorly documented that only a few ex-Apple guys know enough to do it.

    As an enabler for non-programmers, AppleScript fails just as abjectly as everything else because the problem is not the language. For anyone who can envision a solution to a problem well enough to code it, AppleScript is a very, very poor tool; for those who can’t, it really doesn’t matter what they use.

  7. Applescript is overly verbose, slow, and out of date, but it was innovative, and it is easy to use. You just ran across bad documentation. I can give examples of bad documentation for every language on the planet. Like someone mentioned, an applescript book is much more helpful.

    Look at hypertalk and supertalk (used in hypercard and supercard in the 90s). Tons of people created a lot of apps in those environments, and hypertalk is very very similar to applescript. So I wouldn’t blame the language.

    The problem with applescript is that it was primarily used as a glue language between existing apps, not a language for developing apps from scratch (like hypertalk/supertalk). In Windows the glue language was VB, and in unix/linux, the glue language was typically shell scripts and perl. The people who need to write glue scripts are typically administrators or people working with business apps. Nobody in the business world hardly ever used macs. And their glue language (VB) could just as easily be used for developing apps from scratch (visual studio), unlike applescript.

  8. I agree AppleScript is verbose. I agree it’s an attempt at a natural language. But I agree with Doug, it was a easy to use language for Apple users. Remember the target audience for Apple computers. Also remember that in the 90′s IT didn’t support apple users so they had to ‘fend for themself’. This is why you have so many Apple domain experts that are in psychology (Ted Landau : or social sciences (Matt Neuburg ) because Mac computers were toys to engineers and computer programmers. So the language was directed at these type of people, not people were were trained to adjust their thinking to the way a computer is typically programmed.

    Now, with that said, I do have a hard time with AppleScript because I too have an Computer Engineering background, however I would say a good programmer should be able to adjust the to syntax and be able to translate their logic thinking into the language. I ask – is it really just you don’t know the language and are not as comfortable with it as C, Java, or VB? Do you think someone who thinks in AppleScript would have that same frustration level going from AS to C, Python, or VB?

  9. Sellers,

    I think you have a valid point. When I wrote the article I was near the beginning of a new Applescript project. As I said, I am somewhat new to Applescript, and I was frustrated. That doesn’t mean that Applescript is a bad language, it rather means exactly what you said that I was doing more than learning a new language this time, I am learning a new paradigm. Ish. It really has been a while since I moved into a language that is so different.

    If you look an any of the Applescript that I have posted here you’ll understand that I am just hitting the steep spot in Applescript’s learning curve. Before this current I hadn’t used Applescript’s subroutines or error handling, to name a few of the its functionalities that I was unfamiliar with.

    With a little more understanding about Applescript’s significant history, things like the apparent contradiction between the language’s goal of being natural and the documentation’s complete absence of intuitiveness make more sense.

    So in response to your question about where my frustration is centered, I’d say you’re probably right that when discussing the language alone, I am just complaining like any CS-101 student does about Java’s command line I/O or C’s pointers. But hey sometimes it is those very naive insights that eventually motivate significant changes in the computer science world.

    As far as Dictionaries go, I have spent countless hours trying to understand the barely readable documentation Adobe has written for Applescript in InDesign. The beginning of their lengthy PDF spends a lot of time introducing you to Applescript (or Javascript, or VB) in general, then they jump directly into tables of commands and methods. It took me forever to trial-and-error my way to changing the color of text that I was searching for in InDesign.

    I’ll post this most recent script to prove some of my progress as learn this language.

  10. Sellers: “I agree AppleScript is verbose. I agree it’s an attempt at a natural language. But I agree with Doug, it was a easy to use language for Apple users.”

    I disagree that AppleScript is/was an easy-to-use language for [any] users. What it is is an *approachable* language: the word-based syntax has a very strong appeal to the sorts of folks put off by the cryptic appearance of more symbol-heavy syntaxes found in “traditional” languages. However, it’s a bit of a bait-n-switch: while it’s [relatively] easy for a non-programmer to grok an AppleScript’s general purpose just by reading it, it’s much harder to identify the exact mechanics by which it does it.

    In order to make AppleScript look “English-like”, its designers stripped out a lot of the syntactic cues that describe the language’s actual semantics. While all those traditional brackets and braces may look confusing and unfriendly to a non-programmer, they do actually serve a purpose. However, the real mistake wasn’t in removing these syntactic cues, as this did indeed provide the benefit it was meant to, it was the failure to replace them with anything else. e.g. See MIT’s Scratch, which uses visual rather than textual cues to describe language semantics.

    This results in the first problem with AppleScript’s syntax: things with different meanings often look the same.

    In their ongoing quest to make AppleScript syntax as “English-like” as possible, the designers opted for some deep compiler-level trickery: allowing applications to inject their own arbitrary multi-word tokens into the language.

    This obviously compounds the above-mentioned problem: a word or phrase that has one meaning in one part of a program may have a completely different meaning in another. Of course, there’s little in traditional languages to prevent a user from inflicting this situation upon themselves. The difference with AppleScript is that it’s inflicted upon them by language and applications completely outside of their control and with little or no warning that it’s happening.

    However, this particular bit of fibbery has further repercussions: while applications and scripting additions get to pull this trick with the language’s syntax, user-defined code does not.

    Application-defined tokens (property, element and command names) may include whitespace and other non-alphanumeric characters; user defined tokens – i.e. variable names – may not (unless you mess about with pipes and stuff, but that way lies even greater madness).

    Application-defined commands use only keywords to represent command and parameter names; user-defined commands use traditional identifier+parentheses syntax (unless you mess about with AS’s dreadful attempt at supporting keyword parameters; again, road to madness).

    The compiler even uses different colours to represent application-defined versus user-defined tokens – e.g. application-defined command name = blue, user-defined command name = green.

    Thus, the second problem with AppleScript’s syntax: things with the same meaning often look different.

    These two faults combined make it dreadfully difficult for anyone – non-programmer or CS graduate – to join all the dots together quickly or correctly when teaching themselves the language. The difference is that the non-programmer, lacking any frame of reference, has no way of telling if learning AppleScript is a difficult process or not, whereas the CS grad has a ton of prior experience shouting at them: “This is not right!” Thus the non-programmers plough on, simply assuming that this is just the way things are, thinking to themselves that if AS is a “simple” language, it’s fortunate they didn’t try a “hard” one like Logo or Python first(!), whereas the experienced programmer knows they’re being had and isn’t afraid to vent their feelings about it.

    I do believe both faults could be corrected by moving to a semi-visual language syntax and a structure editor a-la Scratch or Alice. This’d retain the descriptive power of text for naming things while freeing it from the traditional textual clutter needed to tell you what they are; thus things which are different will look different. At the same time, it’ll allow users to indulge in the same syntactic niceties (whitespace, non-ASCII characters, etc.) as the other parties (the language, applications, osaxen); this things which are the same can look the same.

    Obviously I’m not waiting for Apple to get around to this any time soon, if at all, but they are at least poking a fresh toe in the visual/end-user programming world these days (Automator, Quartz Composer), so you never know.

    “I would say a good programmer should be able to adjust the to syntax and be able to translate their logic thinking into the language.”

    Indeed. The problem, as I say, is adjusting to that syntax in the first place. The AppleScript language itself is easy enough to use once you understand exactly how it works; it’s forming that understanding in the first place that’s so damn tricky.

    “Do you think someone who thinks in AppleScript would have that same frustration level going from AS to C, Python, or VB?”

    FWIW, I went from AppleScript to Python, and while there was some initial culture shock and information overload, it was a much less painful process than I’d originally feared and a real breath of fresh air to find myself dealing with a language that didn’t delight in redefining the game rules while I was using it.

    I still have a soft spot for the old horror, mind you – it is what enticed me into programming in the first place, after all – but I’m no longer quite so innocent as to believe it’s the One True Language for non-programmers (or anyone else) as I once did. Ah well, y’live and learn. :)



  11. Andy: “As far as Dictionaries go, I have spent countless hours trying to understand the barely readable documentation Adobe has written for Applescript in InDesign.”

    Chronically inadequate documentation for application APIs isn’t an AppleScript problem per-se, although the AppleScript community certainly has the most experience in dealing with the problems it causes. Reading Matt’s book should help you get going, though for specific advice you’re best subscribing to the AppleScript-users mailing list ( and asking there. Or, if you get around to trying appscript, you can always ask on the PythonMac-SIG/rb-appscript-discuss/appscript-objc-discuss list as I hang on all three and can usually answer most questions if nobody else does.

  12. I will give you credit has, approachable may be a more fitting word than easy. I still feel it hit on a target audience and maybe still has one. With Automator, I think you end up with AppleScript that you can start with and then tweak to finish the job? (something I wish MS would let me do with Windows – let me finish that last 10% that they seem to have forgot) I’ve never used Automator so I’m not sure if their workflows are AppleScript based.

    Good luck! If anything – it helps you appreciate C++ more.

  13. Pingback: AppleScript in practice: Updating thousands of ISBN numbers in a catalog at The Joy of Scripting

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>