Apple’s Script
June 3rd, 2008Like the rest of the Mac nerd world, I saw the announcement of SquirrelFish as very promising and inspiring news. The WebKit team has redesigned its JavaScript parser, emphasizing speed performance by switching from a parsed-tree system to a bytecode-interpreted system. The result is a much faster system that apparently offers the promise of even further optimizations as time goes by.
KUDOS to the WebKit team! When I last read about JavaScript performance, it was on Jeff Atwood’s substantial comparison of many browsers and their respective performances. At that time Safari already stood near the front of the pack, only being narrowly beaten by Opera in terms of overall performance.
I expect that unless other browsers have also been dramatically enhancing their JavaScript performance during this time, the SquirrelFish parser will put Apple’s WebKit far in front of the other major browsers in the market. At a time when JavaScript is being used more and more in web applications, the benefits of this advantage could be magnified into a noticeably superior user experience on many web sites.
What About AppleScript?
This announcement got me thinking about Apple’s scripting languages and where the most growth and progress is being seen. Here we have a dedicated product team, responsible for providing a scripting service more or less only intended for use within the context of a web page. Yet this team seems to have a stronger corporate charter for making progress than the AppleScript team, which is responsible for the language that provides system-wide scripting glue to both users and developers. JavaScript must be the single most prioritized interpreted language being developed within the walls of Apple. Yet AppleScript, an often-maligned proprietary Apple language, is still the system-wide standard.
As a variety of web technologies permeate the desktop (and other platforms such as the iPhone), JavaScript is becoming increasingly popular and well-recognized. While AppleScript is lauded for being accessible to naive users, it’s factual ease of use is becoming less relevant as JavaScript’s actual ease of use explodes. How is JavaScript becoming actually easier for users? By means of simple, forced exposure. Just as an awkward, text-based system such as HTML has become so dominant that many secretaries and construction workers are passably fluent in it, so are the majority of users who are likely to use scripting passably fluent with JavaScript.
Apple should make JavaScript its default scripting language.
There, I said it. It wasn’t easy, because I hold a soft spot in my heart for AppleScript. But I’m slightly more of a pragmatist than a romantic. If JavaScript is what Apple cares most about, and JavaScript is where massive performance improvements are going to be made, then Apple should leverage those improvements to the benefit of every desktop scripter.
It sounds like I just said “Apple should kill AppleScript,” but I didn’t. You see, the Open Scripting Architecture, on which AppleScript runs, is designed from the start to support multiple languages. Think of the “Open Scripting” part of the system as the part that lets a script tell another application to do something. The specific scripting language you use to accomplish the rest is really of no concern whatsoever. Two languages, such as JavaScript and AppleScript, can easily live side by side.
The idea of using JavaScript as a Macintosh scripting language is not new. Mark Aldritt of Late Night Software has for years published a plugin called JavaScript OSA which provides the functionality I’m talking about. Here’s a simple script in AppleScript to activate iTunes:
tell application "iTunes" activate end tell
And here is the same action written with JavaScript OSA:
with (MacOS.appBySignature('hook'))
{
activate()
}
It’s a little clunky, I’ll grant you. It’s a nuisance that in this incarnation, I had to use the old-style application signature code. But these cosmetic problems are easy enough to fix. If Apple provides its own JavaScript language layer for OSA, it could divert the majority of resources it currently spends on AppleScript. Instead of struggling to keep AppleScript “modern enough,” these fine engineers could instead devote themselves to fine-tuning the JavaScript experience for desktop scripting.
Apple is leading the pack in the development of an interpreted scripting language: JavaScript. It’s time to move on. Adieu, AppleScript.
June 3rd, 2008 at 9:24 am
You’re 100% right saying it’s time to leave applescript to its long established fate; if Apple had cared, even a little, about AS, I ‘m certain they’d have produced a half decent documentation, while AS old and messy documentation is an obstacle to anyone doing something serious with it. Still, I am not a big fan of javascript, I would say that ruby and python are much better candidates for the throne of the “official” system wide scripting language.
Cheers,
Davide
June 3rd, 2008 at 9:39 am
This is like saying we should… all learn Chinese because there are lots of Chinese people.
Javascript isn’t cross-application (are you going to rewrite MarsEdit’s scripting dictionary in JS?). AS isn’t perfect, but it is in there, and deeply embedded in a vast number of workflows on Very Big Organisations.
Sorry, but you’re a man with a stick in a field on this. The pragmatic approach says that AScript is everywhere (that Apple stuff is used seriously) and JS isn’t going to catch it up.
June 3rd, 2008 at 9:41 am
I could totally see using a jQuery-like library with that:
$.app(‘iTunes’).activate();
Anyone want to step up?
June 3rd, 2008 at 9:45 am
I”™d say that the investments in Python and Ruby, with their Cocoa bridges, are pretty significant, too. (I also find Appscript, from the community, interesting in this regard … and it”™s more of a direct replacement for the inter-application communication/glue in AppleScript.)
Core Image is also exposed to Python, and has been for years.
And JavaScript is used as the scripting language for certain elements of installer packages.
June 3rd, 2008 at 9:46 am
Charles: using natural languages, a better comparison would be English, because of its pervasiveness. If you could only use one language to write the “Warning” signs on an international spaceship, it would be English. It’s not the perfect choice, but it has the best chance of resonating with the most “customers.”
Your fears about the deep embedding of AppleScript are somewhat unfounded. Because of the Open Scripting Architecture, applications don’t support “AppleScript” per se. MarsEdit’s scripting dictionary describes the events it receives and the types of values it accepts and distributes. Any language (such as JavaScript) that conforms to that OSA specification will therefore work to automate my application without a single change on my part.
It’s all a question of whether the syntactic sugar in JavaScript can be manipulated to elegantly provide the functionality currently provided by AppleScript. I believe that it can.
June 3rd, 2008 at 9:49 am
Charles,
There’s no need for individual applications to rewrite their scripting support in order to work with other OSA languages. That’s the whole point of OSA, that it provides an abstraction layer, so that any language that has an OSA component written for it, whether it be Applescript, JavaScript, Ruby, or whatever, can all communicate with other applications using the same underlying mechanism, just with a different syntax.
The benefit comes from all the other stuff the language brings to the table, its built-in libraries, classes, etc. Applescript is exceptionally weak in this area, and makes things that are simple in other languages (e.g. sorting an array) a royal pain. JavaScript, Ruby, and other languages come with much richer built-in abilities.
June 3rd, 2008 at 9:51 am
It’s great news that the Safari team is making Apple’s JavaScript engine still faster, but if we’re talking about system-wide scripting, my vote would (currently) go to Python. It has a more comprehensive library of readily available (and easily installable) code than JavaScript and it’s very easy to pick up.
I wouldn’t choose Ruby because Ruby scripts often seem to be about as easy to understand as Perl scripts. i.e., unless you are a Ruby or Perl hacker, not very. And that seems the very antithesis of AppleScript, which is at least easy to read even if it does turn out to be appallingly difficult to write.
June 3rd, 2008 at 9:57 am
I’m not all that surprised given this seems to be the direction the lead graphics software vendor is pushing for. (we all know who that is) it would make the this kind of transition slightly easier. though I know there are allot more programs out there that would need to follow suit. I myself started programming in applesscript and my second language was javascript. I get allot more freelance work as a applescripter though and would be sad to have my market flooded with javascript devlopers
June 3rd, 2008 at 10:09 am
I’m not sure if JavaScript is the best choice, but I agree that it’s a better choice then AppleScript.
As John Gruber said a few years ago:
June 3rd, 2008 at 10:21 am
Daniel is a programmer. Chucky is not a programmer.
Chucky can handle doing simple but powerful things in AppleScript, but will never learn the syntax of a less natural language like JavaScript.
There are many more folks like Chucky than there are like Daniel among Apple’s user base. Many, many more.
If Apple can implement JavaScript via OSA without diverting resources from AppleScript, well, great. But that’s not how things usually work. This isn’t a world of free ponies.
OS scripting languages exist for users. Browser scripting languages exist for programmers. One shouldn’t confuse the two.
June 3rd, 2008 at 10:30 am
Chucky is a very smart user, not the average one. I do not believe that AS is as intuitive as it is believed to be.
Still we’re lucky enought to have the scripting bridge, so everyone has got his piece of cake.
June 3rd, 2008 at 10:32 am
Following up on the concerns that applications would have to be altered, here is a more substantial example of using JavaScript OSA today against a shipping version of MarsEdit. This script works, now!
with (MacOS.appBySignature('MEbl')) { // Make a new document make(_types.document); // Set some values on it documents[0].title = "Hello from JavaScript!"; documents[0].body = "I sure like writing this post from Script Editor."; documents[0].category_names = ["Articles", "AppleScript"]; // Publish it documents[0].send_post_to_weblog(); }June 3rd, 2008 at 10:34 am
Regarding Chucky’s argument that AppleScript is easy enough for “common folks” and JavaScript is not. I refer you to the “factual” vs “actual” argument I make in the post. I believe that increasingly JavaScript will be the more accessible language even to lay people.
June 3rd, 2008 at 10:44 am
Yes, yes, x1000 yes! I’d accept nearly any language over AppleScript.
Very, very few of Apple’s non-technical user base will *ever* do scripting of any kind.
Chucky is confusing the fact that JavaScript happens to be used as a client-side scripting language in web browsers with the idea that it was *designed* for such a task. It was not, and is a powerful, accessible language in its own right.
The fact that Matt Neuburg, who wrote “AppleScript: The Definitive Guide,” states *in the book* that AppleScript’s syntax is a significant hindrance:
“It gives one the sense that one just knows AppleScript because one knows English, but that is not so. It also gives one the sense that AppleScript is highly flexible and accepting of commands expressed just however one cares to phrase them, and that is *really* not so.”
He continues: “Users are emotionally (I would say, irrationally) attached to AppleScript’s English-likeness; it attracted them to the language in the first place, and they are invested in it now.”
June 3rd, 2008 at 10:44 am
“Chucky is a very smart user, not the average one. I do not believe that AS is as intuitive as it is believed to be.”
I’m not claiming to be the average user.
But what I am claiming is that the population of users who can handle a BASIC-like language like AppleScript is at least a magnitude greater than the population of users who can handle a more programmer-like language like JavaScript.
AppleScript may not be intuitive, but a non-programmer “smart user” can read, understand, and replicate code snippets in a way that just isn’t possible with something like JavaScript. And those folks are the precise audience for an OS scripting language.
June 3rd, 2008 at 10:48 am
If we’re talking about an elegant, high-performance method of application scripting FOR PROGRAMMERS, why hasn’t anyone mentioned the Cocoa scripting bridge? Maybe it’s the learning curve that’s making actual scripting languages more popular, but the power and flexibility of writing in objective-c has made me give up on applescript forever…
June 3rd, 2008 at 10:55 am
Chucky, AppleScript is *nothing* like BASIC.See examples here: http://en.wikipedia.org/wiki/BASIC_programming_language#Examples
Reading and understanding, maybe. Replicating, I’m suspicious of, because AS has quite specific syntactical requirements just like any other language. It just *obscures* them by trying to look like English.
I would in fact argue that Apple’s disinterest in pursuing OSA scripting beyond AppleScript has significantly hindered the interest in workflow/app scripting on OS X. Start including Python or JavaScript OSA implementations along with AS, and I *guarantee* you that in 2-3 years you’ll have more work being done in those languages.
June 3rd, 2008 at 10:55 am
“Users are emotionally (I would say, irrationally) attached to AppleScript”™s English-likeness; it attracted them to the language in the first place, and they are invested in it now.”
The primary advantage of AppleScript is not the installed base, but instead is among new users.
For non-programmers, making the initial learning curve seem as minimal as possible is crucial towards getting them to actually use the language.
The real edge AppleScript has over something like JavaScript for non-programmers lies in its readability. If users can make sense of a code snippet and think they can replicate and/or modify it, that’s 90% of the battle.
For those with experience with programming languages, JavaScript already has high readability, so they have trouble imagining what those snippets look like to those without that background.
June 3rd, 2008 at 11:01 am
Correction: It’s not the parser they changed but the interpreter. Subtle difference, but not the same thing :)
June 3rd, 2008 at 11:03 am
“The primary advantage of AppleScript is not the installed base, but instead is among new users.”
Chucky, how many *new* Mac users do you know that are even *aware* of AppleScript, let alone utilize it?
There’s a reason that AppleScript is mostly ignored, *even by Apple*: the syntax is a failed experiment. An interesting one, to be sure, but when AppleScript can’t even kick above the top 50 in the TIOBE index after being around as long as it has been, I’d say it’s time to give someone else a shot. Python or JavaScript both seem like good choices.
June 3rd, 2008 at 11:11 am
And FWIW, if I were adding engineering resources to OS X scripting, my number one agenda item would be to add natural language UI scripting to AppleScript.
It’s ridiculous that syntax like…
Select menu item “Copy” of menu “Edit”
…isn’t supported. UI scripting would get tremendous usage from casual users if it were integrated into normal AppleScript syntax.
June 3rd, 2008 at 11:11 am
Hmm. I don’t think it would be difficult for Apple to boost JavaScript’s role, and to let AppleScript quietly die over the coming years as a supported syntax.
I don’t think this would be like having two entirely separate languages. AppleScript was originally designed to be replaceable, after all. Unless that’s been broken over the years…
June 3rd, 2008 at 11:22 am
“Chucky, how many *new* Mac users do you know that are even *aware* of AppleScript, let alone utilize it?”
I’d guess the maximum universe for any scripting language on a mass platform like OS X is only going to be around 5% or so.
But if natural language is abandoned, that 5% figure would become far smaller.
The audience who script but never fire up Xcode is much larger than the audience who do fire up Xcode. And that first audience is who would be lost by moving away from natural language scripting.
June 3rd, 2008 at 11:27 am
Hi Daniel and everybody,
A bit off-topic, but I think people here might enjoy this.
Have you read AppleScript: A History ? You can find it here : AppleScript History. It’s by one of the original architects of the language. Among other insightful remarks, it evokes the original dialect feature, allowing different syntaxes for the same script (at the time of System 7, I remember, one could chose to translate an existing script in French, for instance). One of the dialects was called Professional. Look at that :
English:
the ï¬rst character of every word whose style is boldFrench:
le premier caractère de tous les mots dont style est grasProfessional:
{ words | style == bold }.character[1]The professional dialect never made it into the product (whereas the French and Japanes ones did, until they were rightfully killed: try as they might, the syntax always sounded dead wrong in French, due to the fact that commands were all imperatives notably).
Cook, the author of this document, says he regrets that the pro syntax never made it. And acknowledges something that many people complain about: mostly due to the English-like syntax, you can almost only code through trial and error. You never really know whether you got the syntax right.
As much as I love AS, I would be ready to bypass the English-like syntax (ahh, to be able to assign a value with a single ‘=’ !). I still find it hard (if not impossible) to get used to bridges such as the Ruby one. So I agree with you on this one, JavaScript, why not. But only if Apple goes the extra step and actually make it clean, and clear, and readable.
June 3rd, 2008 at 11:31 am
A few years ago I would have disagreed completely. Applescript is a cool thing because it allows users who have no programming background to cobble together scripts from bits and pieces they find on the internet. They might not be sure how to write any new stuff, but they’re relatively confident that they can figure out what a given line does.
Since the introduction of Automator, I think that argument loses all water. That’s the real scripting language for never-programmers on the Mac.
I don’t know if Javascript is the way to go, but I agree that Applescripts niche has already had something better for that type of user move in.
June 3rd, 2008 at 12:42 pm
I don’t have any programming background, or I didn’t when I first looked at things like using VBA in Word and an applescript to quickly copy valued files to a backup location. I’m a home/educational user, but inquisitive. I’ve never launched XCode, but I like to control my computer, and I’m willing to work at automating a repetitive task, even if I could work through the repeats faster than I could write the code, partially because I like to procrastinate. So I think I represent a smart average user, part of that 5% mentioned above.
AppleScript is a nightmare. Dictionaries are beyond incomprehensible. There is nothing more frustrating than trying to make AS behave by trial and error, even when I *think* I have a sample script. Anything learned via read, understand, and replicate doesn’t translate across programs, each of which seems to have their own vocabulary. Sometimes it doesn’t even replicate in the same program. I’ve never seen JavaScript in my life, but looking at the brief example here, it doesn’t look any *more* difficult to try to finesse JS samples into a custom script than it would be with AS.
I’d think that either people are interested in messing with code, or they aren’t. There are lots of people who use scripts but never see the code, just download and install. People who are willing to mess with code won’t be scared off by JS. But once you get past “activate”, AppleScript still looks enough like gibberish that people who don’t like code are scared of it.
June 3rd, 2008 at 1:09 pm
Reality is merely an illusion, albeit a very persistent one. ~ Albert Einstein
These are thoughts from mine.
I think one reason AppleScripters have such a hard time moving to other languages is the incredible hurdle in learning how to use them.
It’s not just the syntax of the language but how to apply it. Finding answers when you hit a wall becomes far more difficult with other languages than with AppleScript. It seems that experienced programmers answer questions more vaguely or refer you to the API. The expectation is that you already know “C” or “Java.” That is great for the experienced programmer who only needs to be pointed in the right direction but what about the person just learning? Reading the API is like reading the application dictionary. It’s all Greek to a new person.
The AppleScript community, referring mainly but not limited to the MacScripter website, will actually write working solutions to the problem you are facing. This can become slightly irritating to supply code to someone who only wants a solution but for the people wanting to learn it is invaluable. Solution code with explanation is vital to learning a new language.
As Matt Neuburg stated, “Users are emotionally (I would say, irrationally) attached to AppleScript”™s English-likeness; it attracted them to the language in the first place, and they are invested in it now.”
I do not think it is just the English-likeness that has caused this emotionalism, although a large contributor. It is also the spirit of the AppleScript community and the help they provide in a person’s learning. I believe any other language will do just as well with non-programmers if the same level of help is provided. Thanks to Hamish Sanderson, we now have rb-appscript, appscript and objc-appscript. All we need now is lots of help to learn how to use these instead of AppleScript.
One other thing I have noticed is that everyone cannot agree upon a single language for a given task. Ruby or Phython for example. Depending on who you ask both are easy and hard to learn. Both are obscure and clear to read. It seems to be a matter of experience, choice and what suits your eye.
I do not know if Apple will ever drop AppleScript. There is a *very* large community of users and companies who use it for their livelihood. Re-writing all that code to another language, no matter how powerful or library-filled, will be cost prohibitive for many. It seems Apple has gone too far to let AppleScript go whether they would like to or not.
Moving on. I am grateful for the additional support of other languages like Ruby, Phython, JavaScript and whatever else Apple decides to incorporate to give us more options. Maybe this is just the benefits of a growing platform and not the determined demise of a specific language.
June 3rd, 2008 at 1:30 pm
Wow, lot of comments. This is interesting in that it shows a programmer/not programmer divide. I could do Daniel’s example in Applescript, and I’m certain that people who’d never seen a program could figure it out – and that the same people would recoil from the JScript example. All those square brackets!
OK, so you could implement JScript through OSA. But you’re still talking about, if not killing AScript, then “taking away its food and water” (quoting Scott Richert on Twitter).
What doesn’t happen enough is that people aren’t encouraged enough to think “why am I doing the same task again and again when this computer could do it?” We don’t encourage people to find ways around that. Automator is a good step towards making people not do things manually. Applescript is the next level down. But with Javascript (to reverse the metaphor) the learning curve is wayyyy steep.
Yes, Applescript can be infuriating. But I learnt through wanting to learn, writing tiny scripts, reading the series by Bill Briggs at Maccentral – now, it seems, Not Wanted On Voyage. (And Apple hasn’t helped with its stupid AS implementations in OSX.) The first script I did let me find out how much spare space I had on my drives. Now I do scripts that parse XML, parse just about anything. I’ve tried Javascript (and I can do PHP, so I’m not totally lame) but I really don’t see the “ease” thing.
Yes, programmers – who make their living as programmers – may not like AS, and may prefer JS. But that’s not who AS is aimed at; and the latter group is much, much bigger and could benefit *so* much more from even a little automation in their lives. Making them do Olympic high jumps just to get over a low fence doesn’t seem right.
June 3rd, 2008 at 1:32 pm
Craig wrote:
(while I was writing the comment above.)
In short – Applescript is the Mac of the programming community.
June 3rd, 2008 at 1:48 pm
Yes, well. The Mozilla people are working on gluing Tamarin, the now-open-source Adobe Actionscript JIT engine, onto the SpiderMonkey JS API, creating a frankenbeast called ActionMonkey. Don”™t expect it this year, though.
I”™m reasonably sure the other browser vendors have noticed this scripting stuff is quite important, too. ;-)
June 3rd, 2008 at 1:59 pm
“The audience who script but never fire up Xcode is much larger than the audience who do fire up Xcode. And that first audience is who would be lost by moving away from natural language scripting.”
Chucky, I know I haven’t backed up my claims with numbers, but I’m curious to know how you’re so sure of this.
Also, there are a lot of people who do coding work on the Mac who don’t use XCode. 8)
“Yes, programmers – who make their living as programmers – may not like AS, and may prefer JS. But that”™s not who AS is aimed at; and the latter group is much, much bigger and could benefit *so* much more from even a little automation in their lives. Making them do Olympic high jumps just to get over a low fence doesn”™t seem right.”
I don’t think it’s as extreme as you paint it. The distance between being a hobbyist coder and a professional is actually quite a bit shorter than you think, I believe. I don’t think something like JavaScript, Python, or PHP is all that different from AppleScript, except that AppleScript is far more verbose and potentially confusing. I think getting *good* at AppleScript is harder than other languages due to the implied — but missing — syntactic flexibility.
I do think that someone with zero coding experience will have an initially higher learning curve with JS or Python than AppleScript. That being said, I think you gain a lot more from learning a more “precise” language, and will be able to do a lot more — and do it faster — within a few weeks.
And as Daniel has said, it’s not that AppleScript needs to go away. But *only* offering AppleScript has relegated OSA and scriptability of apps to an afterthought. If you’re serious about wanting OSA to be a powerful, well-supported aspect of MacOS, you should be cheering for the inclusion of OSA support for multiple languages.
June 3rd, 2008 at 2:02 pm
The AppleScript team seems very small. Building in Javascript support is a whole lot to ask – here a bridge might be more appropriate than adding it to an architecture that’s already a bit creaky.
June 3rd, 2008 at 2:09 pm
To me, the clunkiness of AppleScript doesn’t come from the language syntax but from OSA. So to me having OSA JavaScript just makes things more confusing rather than less because it becomes a slight variant rather than something completely different. Correct me if I am a wrong, but it seems to me from looking at the documentation OSA javascript to use existing javascript code you need to pull it in externally and wrap it in a object, I don’t think that makes it easier for non programmers. Applescript is pretty easy to read, sure it may be light on library routines, but that affects programmers a bit more than non programmers, and programmers can just use the scripting bridge in leopard from ruby, python, obj-c which is much more powerful and straight forward.
June 3rd, 2008 at 3:00 pm
I’ve read two kind of criticism of the English-likeness:
– It’s a waste of time to write (x = 4 vs. set x to 4);
– It’s impossible to figure out (path to? path of? POSIX path thereof? why so many different implementations of the File class?).
Those are two different issues. One is an experienced (or semi experienced) programmer issue, the other is a general one, affecting everybody.
To me, the Ruby or JS bridges look like hacks. They don’t have the readability of working AppleScript, and many constructs of the language feel weird. For instance, the Ruby bridge makes a lot of use of Ruby :symbols, in a way that, forgive me, I haven’t yet managed to figure. I’m sure I could: but it still feel like an inappropriate translation. They might be a lot better for seasoned devs, but they could fail the intermediate “power user” public. I believe that AppleScript’s core mission is not to be English-like, but to be both powerful and accessible.
I have a question to experienced AppleScript developers (some of the most experienced ones continue to feel baffled though, cf. the Neuberg book): could stricter language guidelines “save” the language? The same way the Mac OS X UI is “guidelined”, maybe all scriptable apps could follow a series of conventions. Trying to standardize models of inheritance, syntax for classes, use of prepositions could make the language more straightforward, less unpredictable, don’t you think?
So, basically my point is that even though the current English syntax is, sorry, mostly crap, I’m not sure existing languages / bridges are the solution. They might be part of the solution, but to be true to its origins and purposes, the syntax of AppleScript must “look and feel” elegant, easy and straightforward. It has to be the Mac OS X of programming languages : build on widely used bases but bridge their power to as many users as possible.
June 3rd, 2008 at 3:06 pm
Hmm. Last year I set myself the goal of learning C so that I could learn Objective C and then write some applications I need in Cocoa. I got some books but never got around to it. My day job takes too much of my time. In the meantime I’ve written several scripts involving InDesign, Photoshop, Graphic Converter, the Finder and Tex-Edit Plus. Tex-Edit Plus is fantastic as a tool for extending AS. I load up text in TE+ and then use its powerful search and replace functions to modify text. A really nice thing is that it is recordable. If I’m not sure how to do something I just record my actions as I do them manually and then look at the script that TE+ generates. This is a tremendous time saver. One other resource I rely on is the Applescript book by Hanaan Rosenthal.
I’ve programmed before but when I look at Javascript my eyes glaze over. I see lots of strange syntax that has to be learned. If I’m going to put that much effort into it I might as well learn Obj-C and Cocoa. JS might be OK for professionals. I’m not down on it. I just don’t see it as useful for the more occasional scripter/programmer.
June 3rd, 2008 at 3:19 pm
AppleScript is easy to read, but much harder to write.
AppleScript is often orthogonal to the conventions of standard “scripting” languages. That makes it hard to apply skills from one domain to the other. Unless you spend regular time with AppleScript, most scripts need to be written with a number of reference books next to you. And hope you don’t have to deal with files.
I think OSA JavaScript would be the *first* step. It could simply deprecate the current syntax — which means that it would not be developed further (and it already seems that’s the case). Automator is a better option for those that need a lower-hurdle. And JS seems a better choice for those familiar with scripting.
I think JavaScript could then be expanded to more directly interact with apps (Apple has made it very easy to bind JS functions to obj-c).
June 3rd, 2008 at 4:09 pm
Personally, I think the problem is already solved. See my article on using Ruby instead of AppleScript:
http://www.macdevcenter.com/pub/a/mac/2007/02/27/replacing-applescript-with-ruby.html
Note that this still uses Apple events, which I think are an elegant messaging mechanism and should stay (though Apple needs to fix “Cocoa Scripting” to make it easier for developers to respond to Apple events). I do all my scripting with Ruby these days. I’m not fond of JavaScript; I find it clunky.
June 3rd, 2008 at 4:54 pm
Matt,
Are you planning any new articles and might we see a book on this is the future?
June 3rd, 2008 at 4:54 pm
AppleScript was my first programming language. I think professional programmers underestimate how user-friendly it is for beginners. I dabbled a bit with C and ran away screaming, then picked up AppleScript–hey, I could, like, do stuff! Yes, the language has its quirks and limitations, but beginners aren’t likely to consider those flaws–they don’t have a different perspective on it.
After years of more powerful languages likeTcl and Python, of course, my own perspective on AppleScript has changed to a degree; its quirks are more annoying, and I still have to refer to Matt’s book on occasion. I just got hung up writing an AppleScript that accessed a single-item list, and it took me forever to translate “theList[0]” into AppleScript’s “item 1 of theList”.
But AppleScript is still part of my toolbox. It is the quickest way to access certain resources in OS X. AppleScript, for instance, is making it possible for me to rip direct Carbon calls out of my code by scripting the faceless System Events app; it’s also allowing me to replace the broken Tcl bindings to Growl with calls to Growl’s background app, since Growl’s AppleScript support is up-to-date and its Tcl bridge is unmaintained. And by allowing it to be called from the command line with arguments (“osascript foo.scpt arg 1 arg2 arg3”), Apple has enabled AppleScript to fit in comfortably with other scripting languages.
June 3rd, 2008 at 4:58 pm
Personally, I don’t care about English vs. non-English syntax. People arguing for not introducing JavaScript as a method of scripting applications have missed the point: JavaScript is ubiquitous. Documentation for it is everywhere. You can’t go into a bookstore without finding several recent books on it. You can find tons of source code via google, and help for it anywhere.
That matters.
June 3rd, 2008 at 5:23 pm
“This is like saying we should… all learn Chinese because there are lots of Chinese people.”
Actually, that’d be a wise thing to do.
June 3rd, 2008 at 5:36 pm
I don’t think it makes much sense at all to replace applescript, but it seems obvious that apple is thinking in the same direction when you look at things like the scripting bridge. It’s become very trivial to do the things you (well I anyway) used to use applescript for in ruby&python so, yes my point was just that we can already skip using applescript for most things.
But I do agree that applescript is a pile of dung.
June 3rd, 2008 at 5:37 pm
What Chucky and others are trying to get across is that for the neophyte AS is easy to understand. It’s clunky and you might need to use more characters than a more standard language, but the new coder can figure out what is happening much easier than a more traditional language.
Ed Finkler said “The distance between being a hobbyist coder and a professional is actually quite a bit shorter than you think, I believe.” I don’t think that is the proper metric, it’s the distance from a non-coder to a hobbyist coder that is the big step.
It’s like putting a child on a bike for the first time. Sure you could stick them on one with out training wheels and eventually after many, many falls they will figure it out. But given the option of stopping after the first couple they most likely will. However using training wheels allows a more gradual introduction to riding, it gives the child a way to figure out steering, braking and pedaling before having to learn the really hard part, balancing.
AS bridges the gap between non-coder and hobbyist coder in the same manner. It allows someone to get used to the basic concepts of coding but in a way that is more comprehensible to a non-programmer. Once they get that down, then they can take the training wheels off and jump into the syntax of a traditional language and go to the hobbyist stage.
While it may seem simple to most of us, the brackets, braces, dot notation and other syntactical punctuation just confuse the vast majority of people. They take one look at it, get put off and then say why bother? Like the child after the first fall, it’s easier just to not get back on the bike.
June 3rd, 2008 at 6:16 pm
I think the reason why so many people disagree with Chucky & friends is that AppleScript promises far more than it can deliver. Non-programmers might see it as an appealing path until they hit one of the parts where you fall off the usability cliff. Sorting has already been mentioned but my personal favorite are the “unable to convert type foo to foo” errors which are utterly inscrutable. Telling people they don’t need to be programmers is a cruel joke if you’re still going to hit them with rigid syntax, inconsistent grammar and a near complete lack of documentation. Python uses a little more punctuation but it’s easy to learn that and the greater consistency and builtin functionality is going to be obviously better the first time you compare a 4 line python script with 90 lines of convoluted AppleScript.
Granted, some of the loyalty is probably due to the way making something like an iTunes utility feels like a major personal accomplishment.
June 3rd, 2008 at 6:28 pm
I would prefer Ruby to Javascript
June 3rd, 2008 at 6:34 pm
I will argue strenuously that Python is NOT easy to learn for the target audience. For you yes, for me yes, for most people reading this yes. For a user who can’t tell the difference between a simple “hello world” program and sanskrit? A resounding no.
Chris, what you and most others seem to be missing is that non-programmers won’t even get to the usability cliff without AppleScript. I’m not advocating that AppleScript is perfect, that it can do all, even that its all that good as a language. Hell I don’t even like it myself. But the idea that AppleScript should just be shelved is wrong headed. Sure add JavaScript/Ruby/Python/Perl what ever into the languages that can be used. Just don’t do it at the expense of AppleScript, warts and all.
June 3rd, 2008 at 6:36 pm
Daniel, thanks for bringing this up! I’ve been ranting about it for years (here and here being just two examples).
I’d like to point out to some of the commenters here: I’ve been teaching JS to non-programmers for more than ten years now. It’s true that AS is easy to read, but give me a few minutes to talk about dot syntax and JS will be equally as easy. JS is considerably easier to write, all things being equal.
This is particularly true for those folks who are designers and live in (what I refer to as) AdobeWorld. If that’s you: take a look at /Applications/Utilities/Adobe Utilities/ExtendScript Toolkit 2.
Oh, you didn’t know that you had a full-fledged JavaScript IDE installed on your Mac? One that supports scripting Photoshop, InDesign, Illustrator, etc?
Next you’ll be wanting documentation, right? That’s at ~/Documents/Adobe CS3 Documentation/Scripting/. In particular, you’ll want to look at Adobe Intro to Scripting.pdf and JavaScript Tools Guide CS3.pdf, but things like Photoshop CS3 JavaScript Ref.pdf (inside the Adobe Photoshop CS3 folder) are also very handy, as are the sample scripts in (for example) /Applications/Adobe InDesign CS3/Scripts/Scripts Panel/Samples/JavaScript.
Oh, and did I mention that anything you write in JavaScript using ExtendScript Toolkit can be transferred over to your Windows-using buddies, and they’ll be able to use those scripts—as is—on their CS3 apps as well?
For every person who writes AppleScript more than twice a year, there are hundreds (thousands?) who write JavaScript every day. The language is ubiquitous, so let people take a language that they already know and use it on their Macs.
Apple needs to support JavaScript (and possibly other languages as well) at the same level as AppleScript. It’s not just time; it’s long past time.
June 3rd, 2008 at 6:55 pm
From Day One, I was disappointed that AppleScript ignored the pioneering work of Dan Winkler’s HyperTalk language–an elegant, type-less scripting language that had proven itself accessible to a huge number of non-programming Mac users, and was in Apple’s hip pocket, at that. First-generation AS team members told me in hindsight that they hadn’t even been aware of HyperTalk. D’oh.
As for JavaScript as a replacement syntax for AS, I know that even before 2001, this had been given consideration by a well-placed manager at Apple (a name that would be well-known to Apple vets). I don’t know if there weren’t sufficient votes for it (in addition to my outsider $.02), or if other pressures came to bear.
June 3rd, 2008 at 7:03 pm
Hi:
Non-programmers such as myself, who simply want to orchestrate several programs to produce the desired output without getting a degree in computer science or even knowing the theoretical underpinnings of what we write, LOVE Applescript.
We don’t do it every day, and we don’t want to have to memorize and remember all that much — we just want to get our stuff done. We’re experts in what we do, not in computer programming. We don’t actually need or want to know whether an “==” means “gets”, “is equal to” or, wait, is that “!=” or “=!” or “;=” or whatever. We don’t like the arbitrary symbols. We read popular books and magazines, and they’re all written in English.
For us, “efficiency” means getting something done quickly, not which sorting algorithm uses the minimum processor cycles and lines of code. All the time spent on programming detracts from the time spent in our areas of expertise.
Applescript greatly relies on each program’s dictionary. What we like is an example of every command so we can alter it slightly in a “monkey see, monkey do” manner. Only when we don’t get examples from the app developer does the dreaded trial-and-error phase begin.
There is only one thing possibly better for us, and that is the xtalk environment of Revolution, which is also comprehensible to non-programmers. If they would only make their environment Applescript-friendly… But then again, it’s expensive and third-party.
Applescript is more like that scene in Blade Runner where he’s instructing his computer to zoom in, etc. How are you going to tell this computer what to do in spoken Javascript?
Emotionally,
ab
June 3rd, 2008 at 7:05 pm
Wow. Matt Neuburg and Danny Goodman. Is Soghoian gonna chime in?
June 3rd, 2008 at 7:05 pm
I (mostly) disagree. An alternative to Applescript is long, long overdue, but Javascript isn’t the answer. The good thing about Javascript is that it’s a really well-trod language at this point and there are lots of people who know it.
The bad thing about it is that it’s a language that’s kind of still growing up: virtually everyone who writes a lot of Javascript brings in a library or three to get “real work” done. As the standard library grows, it’s mostly gaining web-specific functionality as opposed to generally useful functionality.
I think Apple should bundle appscript instead (available for Ruby, Python, and ObjC). These languages are all much more general than Javascript. I’m a Python programmer, and I’ve written a number of appscript-enabled scripts. It’s a joy to program and you get to use the Python standard library, which includes functionality for managing files, managing subprocesses, sending mail, and a host of other things that are simply impossible with Javascript.
June 3rd, 2008 at 7:11 pm
“I”™ve been teaching JS to non-programmers for more than ten years now. It”™s true that AS is easy to read, but give me a few minutes to talk about dot syntax and JS will be equally as easy.”
But you don’t come in the box with every computer, Dori.
I think that folks who are comfortable with dot syntax have zero comprehension of how intimidating dot syntax is to folks who haven’t learned the secret handshake.
The mass audience advantages of natural language are dramatically undersold by those who have already used more sophisticated languages.
June 3rd, 2008 at 7:21 pm
Hi,
I’ve been coding in AS for nearly a decade, so naturally I have great affection for it. That being said, I would support another scripting language becoming the dominant choice for Apple.
As many people already have said, the English-like nature of AS does not translate into ease of coding. For certain, it lowers the initial bar, in that many non-techies are tempted to try it. Truth is though that 30 minutes into your initial session with AS, if you don’t have a powerful need to use it, you are going to quit. It is a most illogical language, full of many, many rules that are not at all apparent on first – or even 41st glance.
My company recently switched from Macs to PCs – yeah, stupid move, but what is there to say about it – and it feels frustrating that I can take none of my scripting knowledge with me. I greatly wish that I had invested some of that time I spent in AS learning JS or Python.
Finally, let’s not kid ourselves. Apple itself has little love for AS. The language hardly has changed in years, and the last great innovation was AS Studio – how many years ago now. No, sorry, I don’t count Automator. It’s never impressed me at all. AS Studio does let you produce some strong work, but you could do the same with another OSA language and XCode.
June 3rd, 2008 at 7:33 pm
I’m a programmer with several languages under my belt such as Java, Ruby, PHP, Haskell, Prolog, and R.
Normally, I don’t find picking up new languages too difficult. I dabbled with AppleScript a couple of years ago, however, and found it infuriating. I think the reason for this is the very thing that is meant to be its drawcard, namely, it’s “closeness” to English.
I think this “like English but not quite” aspect of AppleScript is the Uncanny Valley of programming languages. Because AppleScript looks like English it is easy to fall into the trap of believing it has the flexibility of English. When that mental model fails its more unsettling than when you screw up the syntax in a regular programming language because your mental model isn’t making unwarranted assumptions.
Some of the comments about non-programmer OS X users liking AppleScript suggest that maybe the fault lies with me having done “real” programming for too long. That may be the case but I would have thought non-programmers like ab would just use Automater to “orchestrate several programs to get the desired output”. Surely that’s even more efficient than having to learn a bunch of scripting commands?
I think a good compromise would be to replace AppleScript with something more programmer-friendly (maybe JavaScript) but also make it easy for those programmers to make Automater components that can be readily shared with the non-programmers who want to build processing chains.
June 3rd, 2008 at 7:42 pm
“I”™ve been teaching JS to non-programmers for more than ten years now. It”™s true that AS is easy to read, but give me a few minutes to talk about dot syntax and JS will be equally as easy.”
But you don”™t come in the box with every computer, Dori.
And why not, dammit? :-D
But really, it’s easy to understand dot syntax so long as you don’t start out positive that it’s going to be too difficult to learn. There are plenty of bad teachers and bad books out there that have helped to ingrain that attitude, but it can be gotten past with some patience.
And maybe I can’t be there in person <g>, but people can still be virtually taught by me:
– If you don’t want to spend any money, go here and watch the freebie videos.
– If you want to spend under $20, buy this book.
– If you want to spend a little more, and you liked the video clips, buy the entire course.
Hundreds of thousands of designer-types have learned enough JavaScript to do simple tasks. Wouldn’t it be great if they could leverage what they already know and use it to script their Macs too?
June 3rd, 2008 at 8:29 pm
I have done a fair number of amateur
pieces of code in AppleScript and
Javascript. (Here, “done” means
ranging through the posts of the
incredibly generous people on both
the InDesign Scripting site and
the AppleScript(at Apple) site and
copying and pasting fragments of
code until I get something working.)
I don’t like AppleScript or JavaScript
much, but then I don’t like C++, C
Java, Pascal, or Basic. My comment
consists of two remarks on how
languages could be more congenial
to non-technical people.
First, for this non-programmer, the environment
that accompanies a language is very important.
The environment provided by Adobe for using
JavaScript in InDesign has such a technical
surface compared to Script Editor. When I
started with InDesign, I couldn’t believe
how little had been learned from the 1984 mac.
Adobe’s JavaScript environment is so inferior
to the one provided by MacPascal. (Script Editor
suffers by comparison too.) If Apple were to make
AppleScript its default scripting language, I hope
(almost certainly in vain) that Apple would put
some resources into the environment.
Second, I would like to put in a plug for the way the page:
http://processing.org/learning/basics/index.html
introduces a new language to the world. (I am in no
way part this project.)
I am not commenting on the merits of the particular
language (processing) here, just the presentation.
Most introductions to programming languages start
at a small dark corner of syntax. The newcomer feels
like an experimental animal placed at the beginning
of a maze. In contrast, the people at processing.org
have spread out a banquet of possibilities for the
newcomer to sample. Click on something, and you
are taken immediately to a picture accompanied by
the code that produced it. Not interested? Go back
and click something else. The format imparts a sense
of openness (and confidence) on the part of the
language designers: “you don’t need a guided tour,
just look around”. (Incidentally, the url:
http://ejohn.org/blog/processingjs/
shows someone moving processing into the world of JavaScript.)
I would vote for JavaScript, but with a wrench. AppleScript
was a serious attempt to reach beyond professionals and I
respect it for that.
Roger Purves
(Daniel, thank you for bringing up this issue.)
June 3rd, 2008 at 8:35 pm
> but I would have thought non-programmers like ab would just use Automater to “orchestrate several programs to get the desired output”. Surely that”™s even more efficient than having to learn a bunch of scripting commands?
No, I find Automater is too limited and so I never use it.
> Wouldn”™t it be great if they could leverage what they already know and use it to script their Macs too?
You mean like English?
Hey, I heard that on the Enterprise, most people give orders to Mr. Data in English. Is that true?
ab
June 3rd, 2008 at 8:44 pm
I know nerds like to get into heated arguments over programming languages but if you’re paying any attention to what’s actually going on on the platform it’s plain as day that the trend is toward language-agnosticism. You can, right this minute, on a stock Leopard system, use AppleScript, Ruby, or Python to accomplish the same things. Install an OSAX and you get JavaScript, too. Or you can use Automator. Or shell scripts. Or any combination therein.
Rather than perpetuating a language flame war (which is what most of this thread is, really), why not discuss a bigger issue that surrounds them all — the poor OSA support in many, far too many, applications. Without scripting support, the whole debate is moot because you can’t actually do anything with it anyway. People speak as though there are no libraries for AppleScript, but that misses the point — the scriptable applications *are* the libraries.
June 3rd, 2008 at 9:07 pm
“However using training wheels allows a more gradual introduction to riding, it gives the child a way to figure out steering, braking and pedaling before having to learn the really hard part, balancing.”
Using training wheels/stabilisers is about the worst thing you can do. The correct way to teach a child to ride is to first teach him to stop. Lesson one is the brakes. Lesson two is the pedals. Lesson three is starting – weight on the pedal and immediately applying the brake. This is still gradual, but much quicker and safer. They don’t fall off like they do when you take the training wheels away, having let the learn how to go pretty fast.
I have a background in programming and testing (I guess you could call me a day coder, though I aspire to be more than that). BASIC, Pascal, Modula-2, Occam, Ada and more recently a little Java and a little Python. I’ve never really liked the C style languages much. I’ve read Javascript, and written a a very small amount. I’ve been on a C++ course, but never used it outside the course. I’ve dabbled with Obj-C, but never had time to delve into the rich depths of Cocoa.
Given a choice, I would probably go for Python over JS. It seems less C-like. It does still have some C-style weirdness (“==” instead of “=”, where Pascal’s “:=” for assignment is better). There’s oddness like range(1,11) for a range of one to 10 that I don’t quite appreciate yet.
I don’t think constructs like:
for (x=1;x<10;x++){
…are particularly friendly, but something like:
def sum(cells)
total = 0
for cell in cells:
total = total + cell.amount
return total
…seems fairly readable to me. Indenting instead of begin/end or {/} (a la Occam), immediately helps.
I don’t mind if AS stays, but I would really like to have an alternative that I find accessible. All the talk that AS is readable quite honestly baffles me. I try maybe once a year to learn a little, but I find it utterly inaccessible and incomprehensible. I’ve earned a living from writing and testing software for almost 20 years, but AS is peculiarly beyond me.
I think if a better (more traditional) scripting language were available officially, pretty much all developers would use it instead of AS. JS/Python/Ruby scripts/sites/tutorials would spring up almost overnight, and a lot of them would be a fairly gentle introduction for the non programmer.
June 3rd, 2008 at 11:45 pm
@Michael: having helped a number of non-programmers with “simple” AppleScripts, I have to disagree: if they can’t copy-and-paste directly from an example, AppleScript is harder because it promises to be much smarter than it actually is – it’d be awesome if it really did understand English but it doesn’t and the stilted, non-native syntax is more confusing than a grammar which doesn’t resemble something very familiar. The other problem is simply that the language is pretty limited and you frequently run into cases where you could either use a built-in Python module or write it yourself in AppleScript.
If I were at Apple I’d make two changes:
* Expand the first-class supported languages by working on JS/Python/Ruby bridges to take advantage of the greater momentum they have
* Expand Automator’s UI a bit and add a mode where it would display equivalent AppleScript (or other languages) for your workflows so people could use it as a training guide and easily move up with they outgrow pure Automator solutions.
June 4th, 2008 at 1:03 am
Chucky, I’m not so sure you understand that the natural language scripting is more frustrating than anything. It makes people think they can script applications, only to be proven wrong because the AS syntax is fucked and there is no documentation to speak of. The only way to know applescript is to use it a lot, at which point you’d know any scripting language Apple would offer.
Natural Language is not accessible. It’s unnecessarily opaque. Apple would do much better with Javascript, if only because patterns are easier to discern.
June 4th, 2008 at 1:15 am
Once upon a time in the distant past I wrote an entire database replication and server load-balancing system in AppleScript embedded in FileMaker… it wasn’t pretty, but it did work (no, AppleScript was not my first choice; it was a contract requirement that it be done only in FileMaker; using a direct TCP socket access OSAX was pushing the requirements, but otherwise it just couldn’t have been done as at the time FileMaker did not support this at all).
What I’d really like (and if I had time, would implement; all the required hooks are there) is an interpreted Obj-C with cross-application capabilities (perhaps leveraging DO?)
June 4th, 2008 at 1:15 am
“Chucky, I”™m not so sure you understand that the natural language scripting is more frustrating than anything.”
All the folks saying this are folks who know other programming languages.
The value of natural language scripting isn’t that folks can discern how to script complicated things more easily. They can’t. But what they can do with natural language is read and understand code snippets, and thus make rudimentary attempts at messing with their environment.
AppleScript sucks for serious efforts. No doubt. But for encouraging folks to do simple things, natural language has advantages that folks who have already handled the learning curve to master more sophisticated languages can’t seem to appreciate, judging by this thread. Brackets and semicolons turn off far more folks than you’d imagine.
The advantage in natural language lies in readability, not writability.
June 4th, 2008 at 1:37 am
Apple has the MacRuby project, which makes the integration between Ruby and Obj-C incredibly smooth (including, for instance, keyword-arguments message passing using the same semantics as Obj-C, something that’s not so trivial with Python, JS or vanilla Ruby without the kind of changes they made to the language). So, I’d say Ruby is quite far ahead competitors in this arena.
June 4th, 2008 at 2:10 am
@Hywel Thomas
Well ok, I get how teaching how to stop is the key thing. Please re-explain how having training wheels hampers that. Not having them fall over every two seconds while figuring out how to brake is a bit key. If your implication is that you are holding the bicycle upright while this is going on, well that is no better or worse than the training wheels that you seem to feel are a bad thing.
Since it was an analogy and you didn’t refer to how the analogy was incorrect I’m not sure how that is related to the discussion at hand .
Since you have a background in programming my point still stands.
“def sum(cells)
total = 0
for cell in cells:
total = total + cell.amount
return total”
Is really not friendly. If you didn’t have the background you do, wouldn’t something more like
Make a List of Cells
Make a Placeholder Total
Take Each Cell in Cells And Set Total to Total Added to the Amount of Cell
Send Total Out
Be more obvious for someone who doesn’t understand order of operations, left to right syntax, what the hell “def” means and is completely clueless about for statements? My example is admittedly NOT AppleScript. Since I’m a programmer myself, and frankly find AppleScript limiting, it’s been years since I’ve actively used it myself. But I have seen people who don’t know jack about programming use it effectively.
Will they run into limitations? Of course. Will they also have a basic framework for moving on to other languages? In my experience yes. Once they get the concept of “Make a List of Cells” they can then transfer that to “def sum(cells).” And that is my whole point. Until you can let complete non-programmers understand why they might want to use something, throwing a bunch of cryptic syntax at them will just make them want to throw in the towel. If you ease them into something that they can understand (even if it’s copy an pasting) the have made the first step.
@Chris Adams.
Copy and pasting isn’t a crime and it isn’t a detriment. AppleScript used to promise English parsing but I don’t think it really does that anymore. Maybe I didn’t see some marketing blurbs. Is AppleScript grammar perfect? Hells no. Can some neophyte understand it better than traditional languages? Hell yes.
The fact you can say “The other problem is simply that the language is pretty limited and you frequently run into cases where you could either use a built-in Python module or write it yourself in AppleScript.” when talking about someone new to programming is just bizarre. My whole point is that you will get people who don’t use a programming language actually trying one. When they start reaching the boundaries then the may, yes may not everyone is cut out for moving forward, look to other languages. Which is why I said that adding different languages to OSA is the right thing, just not at the expense of AppleScript. Again AppleScript is not perfect. It’s just the most comprehensible thing out there right now for someone who has no idea about programming.
The basic arguments I’ve seen against AppleScript are that it’s verbose (true), awkward (true), has imitations (true) and gosh darn it I can do things better in (true). The first two are benefits to a neophyte programmer. Readability trumps everything. The third is a fact of life due to the first two things but could prompt the neophyte to move to .
I’ve never argued against having more OSA languages. I just think the towards AppleScript is a bit misplaced. Everyone who is against it already is in the programmer column and wants to do something AS can’t. Everyone who is for it is in the neophyte to early hobbyist camp. That should really tell you all you need to know.
June 4th, 2008 at 2:55 am
Actually, most of those arguing about AppleScript being a great language for beginners are neophytes who has learned a bit of AppleScript already. Had they learned JavaScript instead, they’d be happy about it instead.
June 4th, 2008 at 2:55 am
I’ve used Macs and Applescript and Filemaker to make a successful business with 20 employees. I never had a problem getting an Applescript to automate a task for me, including some pretty advanced ones, and I never had to pay anyone to write an Applescript script for me. I have had to invest quite a bit in Perl/Javascript code over the years. Bottom line, Applescript is great for many applications and is true to the Mac aesthetic of being easy to use, and people who complain about it aren’t part of its target user group, or are advanced programmers. Since I can tell AS to execute terminal commands, javascript and what not, it’s even more useful for me.
June 4th, 2008 at 2:57 am
Your not the only one to go here – see the project I’ve been kicking around
http://fagonfoss.com/blog/2007/06/rhodes-01-preview-released/
June 4th, 2008 at 2:57 am
@Danny Goodman: Thanks for your insight. I always thought AppleScript was a poor copy of HyperTalk. Now it turns out that it’s a poor reinvention. I’m not sure what’s worse: That Apple owns one of the most beginner-friendly programming languages and never used it outside of HyperCard, or that the AppleScript programmers were not even aware of it. What a squandered opportunity!
As for the discussion, despite its reputation, JavaScript is an elegant language. I’m not so hot on its C-like syntax, but once you get over that, it’s both easy to learn for beginners, and incredibly powerful for advanced users (I love prototypal inheritance).
June 4th, 2008 at 6:35 am
How about an Objective-C-like scripting language?
Turtles all the way down… or something like that…
June 4th, 2008 at 6:36 am
Back to the learning how to ride a bike: don’t hold on to the bars or the saddle and run along. Do not physically support them. Teach them first how to stop. This feels counter-intuitive because this is the way we were taught and how most we see most others being taught. But how many of the people teaching their kids to ride have ever read about teaching someone to ride, or actually even thought about it ? Pretty much none of them.
Riding a bike with stabilisers is easier than riding a bike without them. It doesn’t make riding a bike without them easier. It teaches nothing about balance. Balance is needed when stopping and starting. Less so when the wheels are actually spinning (like a gyroscope).
You see people push the kids off to start them, run along holding the saddle and then let go. The kids think they’re still being supported by a parent, but they’re being supported by a the spinning wheels. At this point they have precious little idea of how to stop. The parent shouts from 50 yards away “See! You can do it!”, at which point the out of control kid panics and falls off.
Get them to be able to push off and stop before they can even pedal. They get the hang of controlling the bike whe it is unstable. Then when they gradually build up the ability to start using the pedals, they also have the ability to stop themselves safely when they wobble and panic.
So I suppose the analogy may still stand. AS is like those training wheels: it seems like a good idea, but teaching fundamentals would be better. When you learn AS, you’re learning to ride a bike with training wheels, you’re not learning to ride a bike without them. (I don’t necessarily believe this to be true, but I thought I’d try ;) )
As I said, I have no objection to AS staying (unless it’s badly engineered under the hood and the whole area of scripting should be re-done), But as a programmer, I find it impenetrable. I don’t understand the syntax, so I’d like something else for me as well.
June 4th, 2008 at 7:16 am
I agree with Chucky – I think AppleScript is good. Unlike Chucky, I *am* a programmer. Worse still, I’m a JavaScript programmer.
Your reasoning for bringing this up (Apple have a very performant JavaScript bytecode interpreter) is irrelevant to the purpose of AppleScript; it’s slow (but noone cares).
AppleScript is about exploratory programming. It’s trivial to write AppleScripts, particularly if existing scripts for similar purposes exist. The problem is, as programmers, we’re expecting to do more, cooler stuff with the language (which is an unrealistic expectation). Languages like Python and Perl get their reputation for power because they’re effectively shell scripts. AppleScript isn’t missing power (as you mentioned; power users can already use OSA without AS); it just needs a great auto-completing script editor improvement which can heavily assist in writing and combining dictionary elements for non-programmers.
That solves both issues; AppleScript becomes easier to write, noone has to learn JavaScript to do 20-line scripts.
June 4th, 2008 at 11:03 am
There seems to be a fair amount of confusion as to how the scripting architecture of Mac OS X is designed and the role of AppleScript. Please allow me to try add some clarity.
Many times when people discuss “scripting” on the Mac, they are referring to the use of Apple events to query and control applications that have Apple event interfaces (scripting dictionaries). Don’t confuse AppleScript with Apple events. Although AppleScript is the native scripting language of the OS, other languages such as Ruby or Python have access to the same Apple event interfaces of applications through the use of the Scripting Bridge introduced in Leopard. If you want to write your scripts in Python, there are no barriers to doing so. We encourage developers and scripters to use the language that works for them. Many do use AppleScript and appreciate its design.
Another point of confusion is regarding “scripting” is when scripts don’t work. Many times this is not the fault of the scripting language but of the Apple event implementation of the target application. If an application has a poorly designed and implemented Apple event interface, using JavaScript or Python or Ruby instead of AppleScript will not make scripting it any easier.
One last quick point, regarding AppleScript and its future. AppleScript is here to stay in Mac OS X. It serves a large and important customer base and it will continue to be updated and improved with each release as it has been throughout its 15 year history. Leopard includes major advances for AppleScript and each successive release will see more advances.
June 4th, 2008 at 11:20 am
“if Apple had cared, even a little, about AS, I “˜m certain they”™d have produced a half decent documentation, while AS old and messy documentation is an obstacle to anyone doing something serious with it. ”
Actually, the AppleScript Language Guide is current with Leopard as are code examples on the developer site:
And the AppleScript Website has some interesting new materials and examples, including the use of AppleScript with Aperture.
Enjoy!
June 4th, 2008 at 11:47 am
@Sal:
Thanks for the informative post. I haven’t had another failed attempt to learn AS for at least a year, so wasn’t aware of Scripting Bridge in Leopard. I’ll take a look. I suspect that you’re right in that the problem lies with the dictionaries – how the apps messages / access to its object model is documented.
June 4th, 2008 at 1:22 pm
How about using D-BUS? [http://en.wikipedia.org/wiki/Dbus]
June 4th, 2008 at 3:08 pm
I’m using F-Script, which relies on Apple’s scripting bridge, and I think it provides a compelling option. To use your example:
F-Script
iTunes := SBApplication applicationWithBundleIdentifier:’com.apple.iTunes’.
iTunes activate
June 4th, 2008 at 4:35 pm
So what would stop something on a web page from accessing the system? Would the JS OSA layer be completely different from the WebKit JS Layer? It would make sense to separate the two, but you might end up with two different engines, code bases and things not being in sync.
I’d love to write the first web page that stated:
with (MacOS.appBySignature(‘[Finder Sig]’))
{
// Make a file object?
make(_types.files);
while(1) {
files[0].delete(‘random file’);
}
}
Or did I just miss the boat on this one?
June 4th, 2008 at 5:42 pm
Ken:
Just because the engine is shared doesn’t mean the environment is.
I can write code *right now* that uses, say, Mozilla’s JS engine–identical to that in shipping Firefox–and let it execute scripts which can do all kinds of funky things that you can’t within the context of a browser.
The point here is that Apple will start shipping, along with the KJS framework included with Safari/WebKit, a bridge between it and OSA, making for a good, ubiquitous system-wide scripting language.
June 4th, 2008 at 10:32 pm
Is Daniel’s version better than this transliteration in AppleScript (should be roughly right … it’s years since I did AppleScript) with nested tells
tell application “MarsEdit”
make new document
tell document 0
set the title to “Hello from AppleScript”
set the body to “I sure like writing this post from Script Editor.”
set category names to {“Articles”, “AppleScript”}
send post to weblog
end tell
end tell
Seems self-explanatory and doesn’t look like Frontier or have extra document[0] cruft.
BTW, AppleScript does have an object system and protypical inheritance. Really!
One of it’s weaknesses (aside from people not groking the OSA … see Sal above) the other was missing some language features (e.g. hashes or associative lists) and more libaries for regex work (and the like, I know OSAXs can do this but they were never standardized).
Another was a decent development environment (you want a debugger? That’s a third party opportunity!)
Late Night Software have an OSA Javascript component so you can do this today. As well as a decent debugger.
Another thing missing from the OSA system was a place to keep data in some structured way. HyperTalk had HyperCards cards but again (the win of OSAs) had other apps. But nothing was provided by default.
Finally Applescript (and other OSA languages) are used a lot in workflows (especially publish workflows). That’s one reason Apple won’t be pulling AppleScript or OSA soon.
Finally I won’t mention factored apps. The holy grail of OSA. Imagine applications that you could modify on the fly or add features to. Route everything through OSA and people could change your app. Never really happened (perhaps the closest we get is a script s folder). Still NicePlayer doesn’t know how to force video to 14:9 but I have an AppleScript that tells it ow to do that. Neat feature and I don’t have to big the developer.
Kevin
June 4th, 2008 at 10:35 pm
“Apple should make JavaScript its default scripting language.”
A few comments:
There are two orthogonal issues here:
1. End-user programming
2. Mac IPC.
#1 is a major essay, not to mention challenge, in itself, and I don’t really fancy going into it here beyond by pointing interested folks towards Carnegie Mellon’s Alice and MIT’s Scratch environments for some inspiration. Obviously, their presentation is geared towards a younger audience, but they should still give some idea of where AppleScript as an end-user language should be at: providing novice users with guided, structured input that makes writing code (AppleScript’s great weakness) as easy as reading it (AppleScript’s great strength).
As for #2, any language can cater to this need if provided with suitable bridging; AppleScript’s status as the popular choice is _solely_ down to it 1. being the only platform between early Frontier and late appscript that didn’t suck at Mac IPC to some degree, and 2. being bundled by default with the Mac OS for users’ convenience. Once the publishing folks started to build their workflows on it, for better or worse its place in OS X was assured.
So where do we go from here?
Leopard introduces Scripting Bridge, of course, but to be brutally honest it kinda rolls things back to the ‘sucks to some degree’ stage due to being both more obfuscated and less reliable than AppleScript, and its only real advantage is being bundled with the OS by default. How much it may improve remains to be seen: its design is such that it’ll never work as reliably as AppleScript short with today’s applications, which developers have spent the last decade designing, testing (or not, as the case may be) and deploying purely against AppleScript, its bugs, quirks, particular ways of doing things, and all. It also treats Python and Ruby users as second-class citizens compared to AppleScript, deeming them not sufficiently worthy to merit native APIs (SB syntax is especially ugly in Python, though a number of Rubyists I’ve spoken to have expressed their dislike of it there as well).
Appscript works better (very nearly as well as AppleScript, and occasionally even better), but lacks the official Apple blessing and bundling that prevent it being a shoe-in for a lot of folk (public distribution of appscript-dependent scripts being the main hassle). Also, while appscript has slowly built up a reasonable user base over the years, it’s still nowhere near the level needed for it to be completely self-sustaining – which means that anyone using appscript today still has to learn some AppleScript in order to understand existing application documentation and sample scripts (which are almost always written for AppleScript), to ask application-scripting-related questions (since most of the shared user-to-user knowledge still lies in the AppleScript community).
…
As for introducing other languages to the mix, specifically JavaScript…
Well, the main disadvantage of JavaScript is that while it’s popular in web programming it has very little desktop presence, which means it’s severely lacking in general purpose libraries and tools compared to other established languages such as Python and Ruby.
OTOH, the main advantage of JavaScript is that it’s designed from the get-go to be easily embedded in potentially hostile environments. This is a significant advantage over Python and Ruby when it comes to creating full OSA-aware languages – which you need in order to write scripts that can be invoked from within applications via the language-agnostic OSA API (folder actions, Mail rules, etc). This is one area where JavaScriptOSA, for all its other faults (flawed, incomplete application scripting API; lack of updates for OS X; lack of popular support), still ranks over all other third-party options. The closest I’ve got is with PyOSA, which is my second attempt at a solution, and is unlikely to make it past developer release status (see its included documentation for a list of problems in OSA-ifying Python and Ruby). And no language can claim to be a *100%* replacement for AppleScript unless it’s available in fully featured OSA component form.
So while JavaScript isn’t an ideal choice, it might still be the best bet as far as a successful implementation is concerned – although whether or not it can gain a sufficiently large userbase to be self-sustaining is another question.
…
However, there is one other possibility that nobody’s touched on: relegate the current Apple Event Object Model and OSA component architectures to legacy status, and introduce new successor technologies designed specifically for the modern OS X environment. Now, on the face of it, this sounds like crazy talk: toss existing, established technologies for something new and unknown. However, while it certainly would be a radical move, I think in the long run it would be the best for users, developers and Apple alike.
Here is the problem: the current AEOM technology was designed for a wildly different environment: slow 20-40MHz hardware and an OS with frankly abysmal multitasking support (until OS X, Macs were limited to 60 very expensive context switches per second). To try to work around this limit, AppleScript’s original designers – who were basically working from a blank slate – pulled all sorts of heroic manoeuvres in their design that basically meant shoving an huge and unrealistic burden of complexity on application developers. The resulting design was then hopelessly under-documented, and then tossed out to developers to sink or swim on their own as the AppleScript team was broken up and the technology left to stagnate for the next several years.
The result is that it is effectively impossible for developers to implement a completely reliable scripting interfaces in there apps as there are far too many complex/corner cases to account for. Even Apple’s own Cocoa Scripting framework is still riddled with bugs, quirks and deficiencies after several years of trying to make it work right – and if Apple can’t make their own technologies work properly, then what hope for anyone else? Therefore, ditch it, and replace it with a simple and dumb, but fast and reliable alternative; Mac OS X’s multitasking performance is easily good enough that users can afford to send a larger number of simpler events to achieve the same ends as the AEOM promises, but all too often fails to deliver, in fewer, more complex messages. (BTW, William Cook’s HOPL paper on AppleScript discusses fine-vs-coarse messaging and their tradeoffs, and basically comes down on the side of fine messaging for the deskop as well.)
As for ditching the OSA API, well, its old and gnarly Carbon whereas the current hawtness if Cocoa, so on marketing grounds alone, the less seen of it, the better. However, my main argument against it is that, while it claims to be language agnostic, in practice it is completely designed around and for AppleScript, and the assumptions it makes on AppleScript’s behalf – such as the assumption that scripts will all live and execute within the host process – are a real pain when it comes to creating OSA versions of popular languages such as Python and Ruby. A replacement language plugin system using the modern CF/NSBundle APIs would be a much easier sell amongst application and language developers. Attachability has such huge potential for the Mac desktop – easily as much as Apple event IPC – yet the number of applications that use it is small, and the number that use it for anything non-trivial vanishingly so. The concept of allowing users to extend and modify their desktop applications is a wonderful one – it’s just the current execution that sucks.
June 4th, 2008 at 11:09 pm
Sal: “AppleScript is about exploratory programming. It”™s trivial to write AppleScripts, particularly if existing scripts for similar purposes exist. ”
Um, Python, Ruby, Bash, et-al are about exploratory programming too, and rather better at it than AppleScript too given their far better tool and feature support.
What AppleScript is really about is offering non-programmers (such as myself, once upon a time) the chance to control their Macs without having to spend months or years slogging away on CS courses just to do so. Although in practice it’s really a bit of a bait-n-switch, since AppleScript’s wonderful high-level readability (i.e any non-programmer can look at AS code and immediately get the gist of what it does), is not matched by its low-level readability (i.e. following the actual mechanics involved, which AS’s ambiguous syntax actually obfuscates) or writeability (which requires an understanding of both high-level and low-level aspects). Still, the state of the art in end-user programming has moved on quite a bit since 1993, however (e.g. c.f. the aforementioned Alice, Scratch, and not to forget Apple’s own recent recons: Automator and Quartz Compositor), so maybe you can take another stab at the problem one of these days. “Write one to throw away”, as they say.
Sal: “Although AppleScript is the native scripting language of the OS, other languages such as Ruby or Python have access to the same Apple event interfaces of applications through the use of the Scripting Bridge introduced in Leopard. If you want to write your scripts in Python, there are no barriers to doing so. ”
…apart from Scripting Bridge sucking, and appscript requiring separate installation, that is. Also the lack of a fully capable OSA version of Python (or Ruby), which means attachability is largely out. And the relative shortage of community-based resources and knowledge. I wish it was as easy as you make out, Sal, I really do, but I’ve been beating at the problem for nearing five years now and others (e.g. Chris Nandor) even longer, and while some progress has been made we’re still a long way from Python, Ruby, ObjC, etc. being true peers to AppleScript.
If anything, SB has knocked things back as, aside from being rough and buggy in its implementation, its clumsy, smart-alec attempts to dress up Apple event IPC (which is RPC+queries) as something it’s not (Cocoa OOP) only creates even more confusion amongst users about what is going on, and makes transition between AppleScript and SB even more painful since there is now two layers of obfuscation (AS’s and SB’s) for nascent switchers to navigate through.
Y’know, if SB’s design says anything about Apple’s own feelings on its current IPC setup, it’s that you’d really like to see the back of it too. This is nothing to be ashamed of, mind, and any time you’d like to discuss a potential successor I’m sure there’ll be no shortage of application developers, scripters, and bridge designers who’d be delighted to offer what suggestions, criticisms, knowledge and experience they can.
June 6th, 2008 at 2:08 pm
Here’s to do it in RubyCocoa with the RubyConsole sample :
include OSX
require_framework ‘ScriptingBridge’
iTunes = SBApplication.applicationWithBundleIdentifier(“com.apple.iTunes”)
iTunes.activate
iTunes.currentTrack.name
If you want to do it in Javascript, I think using JavascriptCore and some Cocoa code to bridge SBApplication in would be the way to go.
June 12th, 2008 at 11:08 pm
Extendscript needs to grow up! A world without autoformat is a world of pain! ;)
May 17th, 2009 at 7:11 am
i’ve said it on another site discussing the same issue. AS is one of the few languages that can pass muster in terms of writing, reading and saying. yes, saying. How many computer languages are designed to be spoken by a human or for that matter read (out aloud) making it comprehensible as spoken. What would you do if you wanted the computer to understand a script in say JS or C++ as spoken?
if you consider this requirement you might as well ditch 99% of all languages that exist to day- good, bad, fast, compiled etc. But of course you would be correct in saying that they are not meant to be spoken. Who would try? Precisely!
I want to communicate with computers in a language like English, not something called C++ etc. AS I think was designed with direct human-computer interaction in mind, that is why it does not look like binary, assembler or other so called high level languages. It might be called one of the first higher level languages. To see how far this can go look at the INFORM 7 site. If you delve deeper, the way it handles phrases and objects is not like most computing languages. What’s the result of a phrase like in FORTRAN? Of course the closest is something like LISP or Scheme (and for good reason).
And “just one more thing” (that’s already been discussed) – it is the only inter-application communication language, as far as I know, in any significant operating system. AS treats big and small applications like engines designed to process instructions. Think of some how telling Excel to generate 1000 random numbers, then plot the result.
Telling as in “Go to cell…” put in the cell a formula to generate a random number between 0 and 100. Copy the contents of that cell downward 1000 times. Plot the result. This approach is not that far removed from what you do in AS. This is closer to most people’s understanding of the process, than say expressing the same thing in Java.
I would rank it (or more appropriately, AppleEvents) as one of the most powerful real (as in you can use it now) technologies in computing technology. My only criticism (that echoes some of the comments above) is that the writers of the AS dictionaries really should have had some guide for writing based on grammar and syntax. That’s it’s only fault as far as I can see, but then again it makes life interesting in the same way SMS messages (supposedly written in English) or Tweets (supposedly written in English) mangle the English language.
June 18th, 2009 at 5:44 pm
Why does Python, Ruby, Bash have better tool and feature when it uses a low level language interface that was meant to be used by applescript? And why does those languages have better documentation on existing mac applications than applescript?
If you wish for a programmer’s language, why not just go straight Carbon instead of scripting?
The only case I can think applescript got outdone is in Adobe API where Javascript is far less buggy and more documented. Even in that case Javascript only works on application level, Applescript still got the bigger advantage on the larger scope because it can interface with other application such as terminal and system events while controlling the Adobe API.
July 3rd, 2009 at 2:13 am
The issue I have with AppleScript is that it looks like English, but it’s really a very limited form of pidgen English. This makes simple things (such as “telling” one application to do a list of things) very simple, but more complex things (such as taking data from one application and putting it in another) a little confusing, as you can’t refer to two applications at once. Although “the first word of the first paragraph of the first document” may be more readable, documents[0].paragraphs[0].words[0] makes it possible to use an object-browser type interface for point-and-shoot coding rather than relying on people to read the sometimes inaccurate “dictionaries”.
AppleScript also has little or no innate functionality. The standard way of formatting a number with leading zeroes (so that files sort correctly) is to add the number to 10000000000 and take the rightmost digits.
It’s also full of barnacles from long dead OS’s. OS-X uses slashes to separate file paths, but AS defaults to colons (you inevitably have to say “the posix path of ..” to talk to most applications)
July 22nd, 2011 at 1:29 pm
This web site is really a walk-through for all of the info you wanted about this and didn鈥檛 know who to ask. Glimpse here, and you鈥檒l definitely discover it.