The English-Likeness Monster

I'm not a remarkable programmer by Hacker News standards, but I have experience in what I think is a decent variety of languages. I've done C and assembly; I've done a stack-based language; I've done the popular dynamic imperative languages (Perl, Python, JavaScript, a little Ruby); I've done Lisp and Haskell. Heck, I've even programmed in Visual Basic.

And in all my programming adventures, AppleScript has to be the weirdest, most backward, hardest to figure out language I've ever had the misfortune of using. I think Gruber nails it here -- English and other natural languages are not nearly precise enough to express program text, and the problem is exacerbated when you try to support multiple natural languages simultaneously. Visual Basic may not be a terrific programming language, but at least it's internally consistent.

To quote Einstein, "Everything must be made as simple as possible, and not simpler." AppleScript's designers tried to simplify away the essence of programming, and wound up making scripting much, much harder than it should be.

To anyone out there who needs to script OS X, save yourself a great deal of pain and avoid the temptation of using AppleScript just because it's OS X's "native" scripting language (this is was my mistake). Access OSA through a sane language like Ruby or Python instead.

“Scripts are stored in a language-independent internal representation. A dialect defines a presentation for the internal language. Dialects contain lexing and parsing tables, and printing routines. A script can be presented using any dialect – so a script written using the English dialect can be viewed in Japanese. For complete localization, the application terminologies must also include entries for multiple languages. Apple developed dialects for Japanese and French. A “professional” dialect which resembled Java was created but not released.”

— http://userweb.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf . The example it gives for the “professional” dialect is “{ words | style == bold }.character[1]”, which as far as I know would have made it one of the first non-research languages to use pseudo–set-builder notation like that.

An interesting read in light of the lively discussion around HyperCard. HyperCard used HyperTalk, which also used an English-like language, although I recall it is being dramatically easier than AppleScript yet more difficult than JavaScript.

OS X has `sdef` and `sdp` commands that can translate any application's applescript dictionary into .h files for ScriptingBridge API:

    sdef /Applications/iTunes.app | sdp -fh -o -

This was a life-saver for me, as I find AppleScript absolutely impossible to use.

For another take on an English-like computer language, try out Inform 7 [1]. It also suffers from being too English-like, but it's a somewhat more successful experiment. Also, writing obfuscated code is fun. [2]

[1] http://inform7.com/ [2] http://slesinsky.org/brian/code/i7_poetry.html

This may not address all the issues, but it certainly allows a more concise syntax. rb-appscript allows you to utilize apple scripting / apple events from Ruby.

The instructions on this page for building and testing worked fine for me.

http://oreilly.com/pub/a/mac/2007/02/27/replacing-applescrip...

Certainly Gruber gets a lot of flak here for his love of Apple (the products and the company) so it may seem shocking, though it is not, to see him write something like:

"It was a grand and noble idea to create an English-like programming language, one that would seem approachable and unintimidating to the common user. But in this regard, AppleScript has proven to be a miserable and utter failure."

[2005]