DrunkenBlog

Uncanny Valley of AppleScript

I had to deal with AppleScript on Friday, and it left me as annoyed and weirded out as it always does. If you aren't aware, AppleScript is a scripting language based on an english-like syntax, and is one of the technologies that saved Apple's ass in the prepress world in the late 90s. If you're a windows user, think in terms of VBScript.

Eons ago, the mac UI wasn't riding atop a POSIX-style environment... there was no shell, and what multi-user functionality was eventually added was pretty much a hack. The lack of a shell, or command line interface was a bit of a problem. While graphical user interfaces are fantastic for some things, they are a drag and a half for anything remotely repetitive.

There are generally two areas where a CLI interface pulls ahead of a GUI interface in terms of speed and efficiency:

• Batch-processing
• Automation

...or a combination of the two. I.E., as a basic example of batch processing, lets assume you have a directory containing a massive amount of files, 50% of which are JPGs (let's say 5,000) named myFile_001.jpg, myFile_002.jpg, myFile_003.jpg, etc. Unfortunately there are possible duplicates of each file, I.E., for every myFile_001.jpg, there is a myFile_001.jpg.1. Lets assume you might want to do one of two things:

1. Copy all the .1 files to a separate directory so you can go through them
2. Remove all of the possible duplicate files

Both of those things would be dead simple from the command line in a variety of ways with a small amount of training. The commands for each could look something like:

1. Copy to new directory
   $ cp myFile*.jpg.* DIRECTORY_TO_COPY_TO
2. Removal of possible duplicates
   $ rm -rf myFile*.jpg.*

You know what you want, which is all files that end with a .1 to be either removed or moved to a new location. You're basically looking at 20-30 key-presses in total to get the desired result. The wild-carding means much of the automation is taken care of for you.

With the GUI, such things become pretty limiting. You could sort by name, which might leave you multiple-selecting individual files for about 5,000+ key-presses as the duplicates would be intermingled with the files you want to keep. Sorting by kind prolly won't help you either, as chances are the images will have been tagged as .JPGs. Viewing by size can be of use when looking for duplicates, but still involves a ton of hunting and pecking.

As far as automation, or combining automation and batch-processing, chances are you've used a form of them within a GUI to have an understanding of their value. If you are going to find yourself doing the same task over a period of time, spending a few minutes upfront can save you a lot of time later. If you've ever used Photoshop, you should be familiar with Actions, which allow you to save a bunch of different commands to a file, which you can then apply to any image at will, or point to a folder of images.

The problem for Apple was that there was no shell environment, or "native" scripting language. Windows eventually got VBScript, which, if you've ever used Basic, is about as dead-easy to use as a scripting language can be, even if more modern variants have deprecated referencing actual line numbers in code. Incidentally, Apple has their own history with Basic, in that much of the original charm of the original Apple II came from the fact that Steve Wozniak not only embraced it, he wanted an easy-to-use programming language for people to be able to use to hack their own stuff together.

Apple didn't have a shell to build upon, and just about every app for their platform was GUI-based, so they had to roll their own. There are two things that needed to happen to use AppleScript:

• The creation of the AppleScript backend
• Getting developers to build AppleScript support into their apps

The latter has had various degrees of success, but on the whole the larger apps out there spend a lot of time building in AppleScript support into their apps. "Apple Events" were created, which are the messages passed back and forth between apps that are scriptable.

Building in support can be a seriously non-trivial task, requiring you to expose your apps commands, build dictionaries people can reference to see what is available for your app, and many apps commands don't lend themselves well to this at all... especially recording movements to a script. IE, apps don't become scriptable by default in the MacOS.

Apple actually had a bit more of a problem than some other OSs: they kind of considered their users to be retarded when it came to technical things, which made for an interesting dichotomy: actually using the system, compared to other OSs at the time (DOS, Unix, etc) was amazingly easy, but developing for it was pretty non-trivial. But the focus, by and large, was on making things simple for the end user, even if they were harder for the developer.

At the time AppleScript was created, Apple was coming off of HyperCard, a ground-breaking and simple to use programming environment that depended upon a "stacked" interface. It used an english-like language called HyperTalk. HyperCard was pretty amazing stuff at the time, but unfortunately it inspired HTTP, Javascript, etc, and relegated itself to the history books. But the idea behind HyperTalk was to have an entry-level scripting language oriented towards GUIs so normal users could pick it up pretty quickly, using statements like this:

tell application "Finder"
    if the name of the front window is "Fred" then
        close front window
    end if
end tell

And it did so, and as I mentioned it was very much one of the things that saved Apple's arse in the prepress world during the mid to late 90s when everyone and their mother was looking at switching to WindowsNT. Designers who knew nothing of scripting paradigms were able to augment their workflow in big and pervasive ways. You gotta respect that.

But the same thing that helped a lot of users derive value from AppleScript is exactly the same thing that I and many hate about it: the syntax. People can often just find it maddening, and personally go out of my way to avoid touching it whenever possible.

People who have a background in a C-ish syntax probably find it maddening much faster. Some of this is due to how individual applications implement it, and some of it is due to ambiguities which come about from trying to attempt an english-like programming language. As a language designed to expose a way of automating tasks for non-programmers, it's pretty sweet.

But when you are used to a certain granularity (and, um, grammer[sic]) it can be very, very frustrating. I about pulled my hair out over debugging when I tried to get deep into it. The insanely strong typing was... interesting. The ambiguity can be mind-boggling... think of it as trying to build a motor out of legos. Theoretically the ramp-up period is fast because of the ease of snapping them together, but you eventually hit a wall that is maddening to overcome due to their simplistic and bolted-together nature.

There's something else at play here too, at least for me, from a psychological standpoint... and that is uncanny valley syndrome (sorry, wikipedia is down). There's a mild but real psychological aversion there.

If you aren't familiar, the term uncanny valley comes from a japanese roboticist who spent time testing the emotional responses people feel towards a wide variety of types of robots, from big boxes on wheels to life-like and humanoid. It was found that humans tend to empathize more with robots or machines as they start to look more and more life-like. I.E., every feature that makes the robot more like a person increases peoples comfort towards it.

But at an arbitrary point when the robot looks very life-like, but not quite a human, all empathy ceases and people become repulsed. All those features and characteristics that went into making it appear more humanoid and were incrementally welcomed are eschewed and people only focus on the differences.

This is generally why zombies are so f'ing creepy, and why studios like Dreamworks or Pixar are very careful with how they portray people as their rendering capabilities increase, and in some cases intentionally making them less human...

...which is one of my main problems with Applescript and why I find it mentally disturbing. It's english-like, but as you really get into it, while there is a sense that you are "writing out" your scripts in plain english commands (I.E., 'tell application textedit to...'), you're not at the point where you're able to just tell the computer "Please move every file in this directory that ends with .1 to this other directory". But it's close enough that the brokeness just wigs me the hell out when I have to spend enough time with it. Speaking in pig latin is fun for awhile, but why the hell would you choose to do it after the kids have gone to bed?

Even just calling it AppleScript is something of a misnomer, as while AppleScript has become synonymous with the english-like syntax it's really more of framework, or system.

Something a lot aren't aware of is that AppleScript wasn't really designed to just have it's current english-like syntax. They supposedly (from an ex applescript developer) even had a C-ish syntax working but not really tested, and even a japanese dialect in a proof-of-concept phase. These were apparently dropped because the guys were taken off of Applescript and pushed into the opendoc thing after the first release... and for awhile AppleScript was kind of up in the air during the whole OpenDoc fiasco as it wasn't even clear that it would be ported to that platform.

In other words, the current english-language-ish syntax was supposed to be easy to pick up & use by hypercard users, but it wasn't supposed to be the only syntax. That's just how it's worked out. There were some cool things planned: IE, you could take a script with an english-language-ish syntax and tell it you wanted to work in the c-ish language and it'd convert it on the fly.

I've heard you can theoretically tap into these hooks via the open scripting arch with other languages, but haven't really seen it except for javascript version. I've also heard inklings of Python bindings but it hasn't been something I've tracked down too hard.

Apple has done some work on the AppleScript environment for Mac OSX, most notably AppleScript Studio which allows someone to whip up a GUI and attach AppleScripts to the buttons and what not. But there's still a pretty big disconnect between scripting and there hasn't really been a unification of the *nix underpinnings with the eye-candy apps running on top of it. If you want to, say, tell the finder to do something via the CLI, you have to call AppleScripts from your shell script.

Apple could go further than just adding in a C-ish syntax for AppleScript, which would still have to be called separately from the CLI as things stand, and really start to unify the CLI with the eye candy. Since AppleScript is really just targeting & collecting apple events which is passed onto the apps, so even going beyond a C-like syntax for AppleScripts, something like a straight shell-accessible bridge would allow things like:

$ iTunes --help

Would give me the list of commands accessible via the shell, as well as standard menu items. So your command to hide would be:

$ iTunes --menu-hide

...or, say I have a list of files I want to convert to MP3s or something. You could simply:

$ iTunes --convert --<options> <list of files> <output>

Hell, you could even envision someone doing a find & replace using TextEdit instead of the usual *nix tools, via something like:

$ cat <myfile.doc> > TextEdit --find="Dumbass" --replace="Asshat" >> <newfile.doc>

This is just an idea, but the power of merging the eye candy with what's running below it would be a big, big deal... and why turn your back on such a resource now that the mac has it?

 Posted by drunkenbatman
    June 06, 2004, at 11:06 PM