AppleScript - the Definitive Guide

honestpuck writes "It is refreshing to find a book that is totally honest about the drawbacks of the language it hopes to teach. AppleScript: the Definitive Guide is one such volume. Matt Neuburg delves into all the flaws inherent in this language." Read on for the rest of honestpuck's review. AppleScript - the Definitive Guide author Matt Neuburg pages 476 publisher O'Reilly and Associates rating 8 - Well written, good topic coverage, some flaws reviewer Tony Williams ISBN 0596005571 summary Excellent guide

AppleScript as a language and development environment has some terrible problems, and I applaud Neuburg for not trying to hide them away. Personally I love the power the language can provide, while loathing it for it's "English-like" syntax and the problems inherent in having most of the language defined in differing ways in different applications.

One of Applescript's problems is that it is difficult to teach, as you almost have to understand everything before you can know anything. Unfortunately that problem is reflected in this book. Neuburg constantly finds himself having to resort to the "believe me for now, I'll explain later" strategy throughout the book.

The book is broken up into four sections: "AppleScript Overview," "The AppleScript Language," "AppleScript In Action," and several appendices.

"AppleScript Overview" is a well written look at what AppleScript is, what it is good for and how to use it. Chapter 3, "The AppleScript Experience" is an impressive warts-and-all walk-through of the author developing an AppleScript to solve the problem of renaming files to conform to a particular standard using FrameMaker and the Finder. It is here that the reader will first see the problems inherent with AppleScript as Neuburg battles with incomprehensible dictionaries, unknown object models and uncommunicative error messages to build his script.

Part II, "The Applescript Language," is the 200-page core of this book. Neuburg provides a detailed and comprehensive look at every detail of AppleScript's syntax and semantics. The first chapter of this section, "Introducing AppleScript" contains a marvelous section entitled 'The "English-likeness" Monster' that is a short, sharp (and entirely justified) attack on the problem of AppleScript's attempt to be English-like in syntax.

In the rest of this section Neuburg provides an exceptional survey of the language. I personally appreciated his examination of the intricacies of type coercion and the exotic scoping rules. He has also taken the time to write and elaborate a large number of small pieces of code to demonstrate gotchas and tricks throughout the language.

It is this section that truly separates this book from every other AppleScript book I have previously read -- it is a masterful guide to the language.

Part III is a concrete path towards writing your own scripts. Neuburg starts by examining application dictionaries in depth. The real power of AppleScript lies not in the language itself but in the ability to use language extensions built in to other applications. This also becomes a huge flaw when the only documentation you get is in the application dictionary. As Neuburg puts it "One purpose of the dictionary is to show the human user how to speak AppleScript to a scriptable application in order to drive that application. But a dictionary, by its very nature, is not completely adequate to this task." He then goes on to explain the flaws.

The first appendix is a dump of the AppleScript Suite from AppleScript's 'aeut' resource. This is the core of the language usable everywhere. The second Appendix is a good, useful guide to tools and resources for the AppleScript programmer.

Taken as whole, this is a great book for the AppleScript programmer, both beginner and expert. It has a good writing style, has been well edited and well constructed. Neuburg may be putting in too many forward references, though. Other reviewers, particularly those newer to AppleScript, have called the book frustrating and confusing. I think this may be due to both the high information density in this book and Neuburg's fast introduction to topics that are better explained later in the book. If you are a newcomer to programming and AppleScript then this may be daunting.

If you are new, however, this is still an excellent volume but you may have to force yourself to finish it and then go over at least Part I and II again to truly understand the language. It would probably be a good idea to start trying to build your own scripts after the first read through. I must say, that after taking a good hard look at the way the book has been constructed and ordered I couldn't really come up with a better way that wouldn't have doubled the size of the book.

Visit the O'Reilly web page for the book if you would like to see the Table of Contents or grab an example chapter.

Neuburg has said "My approach is not to rely on documentation, ... but to bang away at the language itself, testing and experimenting, trying to deduce the underlying rules" and this approach has certainly borne fruit in this volume. For all it's minor flaws you cannot say, as may be true of many other tech books, that it is a rewrite of the documentation. He has approached the problem from a different direction and given us a book that offers an excellent guide to the language.

I would recommend it to all Macintosh owners as the perfect way to unleash another powerful aspect of your system. For people who have no AppleScript or programming experience who want to be totally spoon fed this book is probably only a 5, for people with a little AppleScript experience, a fair amount of programming experience and a willingness to stick through to the end this book is probably a 9. It is certainly the best book on AppleScript I have seen.

You can purchase AppleScript - the Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

AppleScript could rock, if only...

[corebreech]

AppleScript would rock if people started writing really good AppleScript-aware applications. But they don't. Most everything out there is crap, for one simple reason: almost no one supports recordability.

An AppleScript-recordable application lets you record your interaction with an application and play it back later. But it's more than just keystrokes and mouse-clicks. The events that make up your interaction are recorded at the semantic level, which makes them a whole lot more useful.

It also would address what everybody keeps saying is the chief shortcoming of AppleScript: it's terrible syntax. I agree it's pretty unwieldy in places, but the thing of it is, you shouldn't be writing scripts, you should be recording them! And once you've recorded a script, it's a pretty easy task to go in there and make simple changes if you need to.

The problem is compounded by people releasing software that claims to be recordable but really isn't. BBEdit is an example... they claim to be recordable, but they're not. All they let you do is screw around with window positions and basic UI crap like that. But do they let you actually record your interactions with the text within the document? No. And so people go buy BBEdit, see that the box says it's recordable, try it out and come away thinking that AppleScript sucks. It doesn't. It's BBEdit that sucks.

What's especially frustrating is that the purchase of Next should have helped remedy this situation. One of the reasons so few really good recordable applications are out there is because it's really hard to write a really good recordable application. You have to factor your code with AppleScript foremost in mind, so what was once a single function becomes four or five. And the API is a little convoluted. And you have to create and maintain an object hierarchy that may or may not correspond to the hierarchy of classes used in your code.

Cocoa/Objective-C could've gone a long way towards solving these problems. I detest Objective-C on other grounds, but I do appreciate that it would be a great boon in the creation of AppleScript-recordable applications. Alas, the guys from NeXT who seem to be running the show over there these days have taken a "not invented here" attitude to the language.

That's really too bad. Because you may all think the syntax is absurdly verbose and superficially English-like today, but just wait until we start talking to our computers as a matter of course. AppleScript would rule your desktop.

If I were running Apple, I'd make Python a first-class language, give it access to everything Cocoa and Carbon have access to, and put together a truly awesome AppleScript module that would let developers create AppleScript-recordable applications just as easily as you would, well, write a program in Python.

Sigh. If only.

Re:AppleScript could rock, if only...

[Anonymous Coward]

... almost no one supports recordability.

Including Apple themselves BTW.

Re:AppleScript could rock, if only...

[ArsCheshire]

Apple hasn't, but other people are working on it: take a look at PyObjC.

Re:AppleScript could rock, if only...

[p4ul13]

you shouldn't be writing scripts, you should be recording them!

Damn good point; I was working for a couple weeks on an iTunes appleScript that would have been so much easier to figure out if the script recording could have generated some code for me to modify. Ahh well.

Re:AppleScript could rock, if only...

[iminplaya]

Bah! I'm waiting for Hypercard to come back. Anybody tried running it on OSX? It ran pretty fast on my Mac IIx at 16mhz. I can only imagine the speed on these new multi ghz machines with all that RAM an' all

Re:AppleScript could rock, if only...

[Anonymous Coward]

However, this assumption is not correct, since a subset of English sentences interesting on quite independent grounds does not readily tolerate the ultimate standard that determines the accuracy of any proposed grammar. If the position of the trace in (99c) were only relatively inaccessible to movement, any associated supporting element is not subject to a general convention regarding the forms of the grammar. For one thing, this selectionally introduced contextual feature may remedy and, at the same time, eliminate problems of phonemic and morphological analysis. I suggested that these results would follow from the assumption that the speaker-hearer's linguistic intuition is, apparently, determined by an important distinction in language use. So far, the theory of syntactic features developed earlier is not quite equivalent to the requirement that branching is not tolerated within the dominance scope of a complex symbol.

Re:AppleScript could rock, if only...

[Anonymous Coward]

you shouldn't be writing scripts, you should be recording them!

It's called VBScript, buddy. Get your ass behind a Windows PC, open up a Microsoft Office program and start recording your macro. I swear, you open sores advocates love reinventing the damn wheel over and over again. Bow down to Microsoft innovation, you twat.

Re:AppleScript could rock, if only...

[the_2nd_coming]

why not use Python or Perl? much more powerful and easy to use.

Re:AppleScript could rock, if only...

[zonx lebaam]

Firstly, I don't know AppleScript (although I have been considering buying/reading this book). ...

... put together a ... AppleScript module that would let developers create AppleScript-recordable applications ... easily

What I think I'm hearing is that apart from complaints about syntax and such, the true weakness of AppleScript is that the application writers have to go out of their way to support it, and they don't. After all, how many of their customers are clamoring for this as opposed to fixes of first-order bugs.

Perhaps a better way to improve this situation (as opposed to writing a python tool to pick stuff apart) would be for Apple to work harder on automating this on behalf of the developers using Interface Builder. Including human readable documentation that's part of the actual Applescript implementation of the Application (a la python indeed, but perhaps a little easier to track down parts of which than I think I'm hearing the dictionaries are). Or maybe that's how it already works?

Re:AppleScript could rock, if only...

[cosmo7]

I think you are thinking of Visual Basic for Applications, which suffers the same problem the AppleScript does - it is implemented differently (if at all) in different applications, including the way that actions are recorded.

Re:AppleScript could rock, if only...

[kisrael]

What is the status of HyperCard?

I hear such good things about it, and didn't myst get its start in that direction?

I always lament the way consumer PCs no longer come bundled with any easy to use programming language ala BASIC...kids who grew up in the 80s were truly privelged, before that computers were too expensive, afterwards they're closer and closer to being black boxes, programming wise... (on the other hand, we didn't have the web or easy Net access, but still)

Re:AppleScript could rock, if only...

[prockcore]

But it's more than just keystrokes and mouse-clicks. The events that make up your interaction are recorded at the semantic level, which makes them a whole lot more useful.

You just described QuicKeys. It does things at a semantic level. It records your actions and then creates a script that has things like "click the button marked 'OK'" and "select the menu iten labeled 'Options...'"

Then it lets you do things like run this script whenever I hit Ctl-F4, or run this script every 30 minutes, or run this script when the computer boots.

www.quickeys.com

We use it here at work to automate a publishing process. There's even a version for Windows.

Re:AppleScript could rock, if only...

[Anonymous Coward]

I've been using AppleScript almost from the beginning (1994) and agree with most of your criticisms except "you shouldn't be writing scripts, you should be recording them." In my experience, the only time I've found recording to be of any use is to discover how an application expects it's events to be called and what parameters the event accepts. As you point out the dictionaries are often awful and recording is a useful trick to use when confronted with bizarre or counterintuitive syntax.

In my mind, the most useful scripts are those that use loops and branching and recorded scripts can't do that. Recorded scripts also often specify the target of a command (files, folders, or other objects) so specifically (exact file or folder names) that they are essentially useless except for processing the specific object that was selected during the record operation. It is easy to open the script and tweak it by hand to handle loops or branching etc, but they are very rarely useful as recorded.

Re:AppleScript could rock, if only...

[Anonymous Coward]

And VBA was introduced *after* AppleScript too.

Re:AppleScript could rock, if only...

[WatertonMan]

GUI scripting can do this with Applescript. Both Quickeys and the shareware iKey are very powerful and useful, although there do appear to be speed issues relative to the Sys9 version. For quick and dirty tasks as well as mapping scripts to a function key or key stroke both of them are excellent. I actually have mind run various text formating programs written in Python on my selection. Great for dealing with email quotations.

BTW - I think you misunderstand what the author meant by "semantic level." Instead of buttons or menus you deal directly with what those represent. i.e. instead of doing "click the button OK" you'd do something like "start indexing my_folder". The latter is much easier to read and understand. Dealing with the GUI is dealing with often ambiguous representations of underlying processes. Apple added GUI scripting primarily so you could script everything including those programs that didn't support Applescript.

One problem that many have mentioned (and which brought this about) is that Apple itself has only halfhearted support for Applescript in most of its applications. Mail in particular, while supporting it, has glaring ommissions that still haven't been resolved.

Re:AppleScript could rock, if only...

[Hanji]

select the menu iten labeled 'Options...'"
That's not at a semantic level like the grandparent is talking about, that's a GUI level. That action at a semantic level would read more like "Open the options window" - describing really what you're trying to do, not *how* go about doing it.
The menu item you click on is irrelevant, what's important is that you want to get at the options window. And that's something that can really only be implemented application-level, not by a third-party program peeking into what you're doing.

Re:AppleScript could rock, if only...

[wdavies]

Spot on critique of Applescript. I'd mod you up, but your already at 5!

Winton

Re:AppleScript could rock, if only...

[corebreech]

I agree, to a point.

The problem is that to be truly useful, you want *every* application to support whatever scripting language you end up using, since so much of the power comes from being able devise useful solutions by connecting different applications together.

And there is a good deal of support for AppleScript already. So much pain, misery and wailing went into providing even the limited functionality we see today... I don't think developers are going to embrace throwing all that work away.

Re:AppleScript could rock, if only...

[WatertonMan]

Hypercard is long dead. Supercard which originally was basically Hypercard with color (way back in the Sys7 days) is still around. I've not used it, but it is up at version 4.1.2.

Supercard

It looks quite native for OSX and has a trial version you can download. If you miss Hypercard you may like it.

Re:AppleScript could rock, if only...

[protohiro1]

I want a GUI scripting language for macos (or even windows) that works like MEL for maya. You can record EVERYTHING. You can write a script that creates a completely new gui if you want to. With a script language like that, that in my perfect world would also be controlable via perl, shell script and even the php module of apache. (a moron like me could write a web interface for itunes in five minutes). Wouldn't that be great...

Re:AppleScript could rock, if only...

[RevAaron]

Although, Apple did release a Perl - Objective-C bridge. I think it comes with 10.2's perl.

Re:AppleScript could rock, if only...

[RevAaron]

A few objections on your post, at least from my standpoint.

I really like the AppleScript system in the Mac OS. I have always found that most apps support AS scripting decently. However, I have no idea if support for recording is lacking in some apps- I only record a macro *very* rarely.

What I like about the OSA- Open Scripting Archtecture, of which AppleScript is the default language- is the ability is using it to call into apps that otherwise are isolated from my program. I like to be able to eval a line of AppleScript and get a string with the returned value; or, in Perl, Ruby, Tcl, JavaScript and others, I can call into those commands directly.

See, AppleScript is but one language in the OSA. Any language can hook into it, giving it AppleScript's powers, without the need to ever touch AppleScript. I love the OSA and what AppleScript provides, but the language itself is not my style.

Why should I be recording my scripts? A lot of what I do with AppleScript isn't neccesarily accessible with a straight-forward button or other GUI action. Which is why I access the Apple event directly.

A Python-Objective C bridge has been around since OpenStep days.

If you think AppleScript/OSA lack supporting-apps, it's good you don't use Windows with the WSH. :)

Re:AppleScript could rock, if only...

[Anonymous Coward]

Dude, Mac guys are not Open Sores guys, although they have convinced themselves that they are. You can make fun of GuhNOO Linux guys for being open source, but you can make fun of Mac artists for mistakenly "thinking" they are open source even more. They're dumb.

Re:AppleScript could rock, if only...

[Delighter]

Yes, recording is great. There is no doubt. But try to record loop. Click and do, click and do...

Re:AppleScript could rock, if only...

[NumbThumb]

consumer PCs no longer come bundled with any easy to use programming language...

errr.... Windows comes bundeled with VisualBasic (well, at least Office and a load of other apps include a VB Runtime), and Linux comes "bundeled" with Perl, Python, whatever-you-like.

Sure, the VB-support in Windows is not up-in-your-face, and VB sucks, but it's there... It's just carefully hidden from the user. Now, if that is good or bad is quite arguable, i guess.

Re:AppleScript could rock, if only...

[corebreech]

However, I have no idea if support for recording is lacking in some apps- I only record a macro *very* rarely.

Possibly because so few applications thoroughly support recordability? So the first time you try, you see it isn't there, and the next time, and so on, until finally you just give up and code it manually.

I would also suggest that AppleScript should be usable by non-programmer types. Maybe *you* don't need to use it, but others could get a lot of mileage from it.

Why should I be recording my scripts? A lot of what I do with AppleScript isn't neccesarily accessible with a straight-forward button or other GUI action.

It isn't accessible because the application has poor support for recording. Ideally, *everything* that you do with an application would be recordable.

A Python-Objective C bridge has been around since OpenStep days.

Yeah, but I was talking about first-class support, with tools that are installed with the OS and/or developer tools CD, and with docs that are aimed at Python coders, and so I can release a distributable and not make a half-million Mac users try to figure out how to install Python and PyObjC and so forth.

If you think AppleScript/OSA lack supporting-apps, it's good you don't use Windows with the WSH. :)

You're right. The glass is half-full. And the earlier point regarding OSA is a good one, although I've always seen this as a trump card Apple could play in showcasing the Mac's excellent i18n support. I mean, how many other OS's out there will let you code in, say, Arabic, for instance?

Re:AppleScript could rock, if only...

[oskillator]

Kids who grew up in the 80s were priveleged in that they could quickly approach what the most impressive programming minds were doing at the time... but this was not because BASIC was so easy, it was because the best you could do was extremely limited. Because of the long start-up time to doing anything interesting, I can't imagine being as interested in learning programming now as I was back then.

I don't think you can blame the tools, though. Windows comes with built-in Javascript and VBScript support in Internet Explorer, and newer versions actually come with the .NET framework, which has compilers for a bunch of really excellent, pro-level languages. For instance, C# is, IMO, a technically better language than Java.

Again, the barrier to entry is larger, but that's because programming for a GUI is fundamentally harder.

Re:AppleScript could rock, if only...

[laird]

It's actually pretty easy to make an application recordable and scriptable, if you build your application the right way. Specifically, if all of your interactions between the front-end and the back end go through a clean interface, that's where you plug in scripting. Apple's development frameworks make it easy to do this.

The problem is that many developers don't want to learn more, and do more work, to support a capability that not too many people are asking for. So while many applications are scriptable, only a few are recordable.

Still, to disagree with the parent, scriptability is much more important than recordability, because if the app isn't scriptable you can't even get started in plugging things together. Recordability just makes it easier to write scripts.

Re:AppleScript could rock, if only...

[laird]

AppleScript is actually at a higher level than this. In AppleScript you say things like "select the first line of the third paragraph" or "Tell the Application 'Microsoft Word' to open a new document" or "Turn on the option named 'auto-save'". This is important because AppleScripts are independent of the GUI, and many AppleEvents are even independent of specific applications, because there are suites of AppleEvents that are supported across many applications.

Re:AppleScript could rock, if only...

[RevAaron]

Possibly because so few applications thoroughly support recordability? So the first time you try, you see it isn't there, and the next time, and so on, until finally you just give up and code it manually.

Nope. The reason I only rarely record my AppleScript is that I often can't record what I want to do. And not because the poor support you claim, rather because there often isn't a way to do it in the GUI. It's the wrong style, at least for what I'm usually trying to do.

For instance, one way I have used AppleScript is to make a little window/app switcher for Squeak Smalltalk, a language that doesn't use the Carbon or Cocoa APIs in its GUI, other than to use as a fancy framebuffer. Squeak has its own windowing system. Anywho, I want to be able to switch to the "real" Mac apps I have running, so I wrote a ditty that brings up a menu with the apps running in Squeak and in Mac OS, and when selected switches to it. The AppleScript used involves asking the Finder what apps are running, and what windows are a part of those apps, information about apps and windows, switching to them, etc etc. Those actions are not the sort of thing I really could record, nor would I want to. This example is pretty representative of what I do with AppleScript. I call out to AppleScript and get a return value, which I may or may not parse and use in my program.

But let's say I just had a task I wanted to be done over and over again. I may record parts of it, and then edit the code, put it in the loop, etc etc. I have never had a problem with doing things this way- no matter if the OSA has any idea about the semantics of what I'm doing. I don't care that it knows what I am doing in the end, just as long as it does it for me.

It isn't accessible because the application has poor support for recording. Ideally, *everything* that you do with an application would be recordable.

Sounds like a fine dream, but not one that makes a whole lot of sense for some actions. Using my example, how do you think AppleScript or the app should support those kinds of things? Have some far more elaborate system of visual programming? Or just have all of those more programmatic actions be in a list that I can get in a menu? If so, why not just use the Dictionary?

Yeah, but I was talking about first-class support, with tools that are installed with the OS and/or developer tools CD, and with docs that are aimed at Python coders, and so I can release a distributable and not make a half-million Mac users try to figure out how to install Python and PyObjC and so forth.

I haven't used 10.3 that much, but in 10.2 you got Perl, Python and Ruby installed by default. What's so hard about having your users install a framework first, and then double-clicking your app? After all, this is OS X, not Linux or Windows. One should be able to drag PyObjC.framework to the frameworks folder, either the local user's frameworks folder or the system-wide one. Or, you could put it in your app's bundle, then they wouldn't have to ever see it. You don't even need to use an installer script.

Everyone wishes their favorite pet language had full first-class support in their favorite OS. There really isn't an answer to this. The other guy wants perl. Other folks want Ruby. I wish Smalltalk runtimes shipped at OS X's core. I mean, Objective-C is just C plus Smalltalk- a natural fit! If that's what you want, do it; OS X opens up a lot of ways to give your users what they want and do it easily.

Re:AppleScript could rock, if only...

[the_2nd_coming]

well, if the developers of Cocoa would make a library for apple script support, it would make adding it to a program much easier, especially if applescript was replaced by a traditional scripting language.

Re:AppleScript could rock, if only...

[corebreech]

The reason I only rarely record my AppleScript is that I often can't record what I want to do.

You never really had the opportunity to use it in the first place, so how can you credibly claim it to be an option you've rejected?

For instance, one way I have used AppleScript is to make a little window/app switcher for Squeak Smalltalk...

That's one example only, and a fairly bizarre one at that. I didn't say that there weren't uses that precluded recordability, and I'm not sure I would describe you as being in AppleScript's target audience in any case.

I have never had a problem with doing things this way...

Again, you're a programmer. AppleScript's promise was to expose new ways of automating tasks to non-programmers. I think a lot of your issues derive from this basic misunderstanding.

Using my example, how do you think AppleScript or the app should support those kinds of things?

Again, your example is atypical and not particularly relevant here.

I haven't used 10.3 that much, but in 10.2 you got Perl, Python and Ruby installed by default.

Python only comes with the Developer Tools CD, IIRC.

What's so hard about having your users install a framework first, and then double-clicking your app?

I guess nothing. It's not first-class support for the language though, which was my only point. I may not want to support issues Apple may or may not have with Python/PyXML/whatever. Maybe you're interested in doing that, but I am not.

Re:AppleScript could rock, if only...

[kisrael]

I did some tooling around with VB3, in fact, designed and taught a class in it...but
A. I don't see any way of making a form in my PC w/ Office
B. Office only sometimes comes bundled...old school BASIC was much closer to universal

Re:AppleScript could rock, if only...

[kisrael]

Again, the barrier to entry is larger, but that's because programming for a GUI is fundamentally harder.

I disagree. I watched newbies have a much harder time learning C at my school than pick up VB3 in the class I designed and taught.

Now here's what I think is closer to the truth: it's because programming for MODERN GAMES is fundamentally harder. (And it a bit more esoteric) I think making little games is what drove a lot of kids to mess around, combined with languages you didn't have to download...in fact often you loaded the "real games" THROUGH the language.

There are some options, though you quickly get into some weird points. Javascript is accesible, and it's cool that a kid could make up something and it's automatically webable, but it lacks graphic and sound primitives and only so-so real time input support (keyboard/mouse is a little esoteric)

Java vs C#--man what kid is going to give a damn about your little opinion, or the fact runtimes are into the system? Do I have a .Net compiler coming with my system? Not as far as I can tell.

There is some hope, like if a parent wanted to encourage a kid: DarkBasic has a lot of neat 3D stuff, I need to look into what's happening with Processing, a cool want-to-be-newbie friendly Java framework, a while back there was Klik+Create or whatever, etc. But I think the fact that these aren't coming with the PCs we buy is a tremendous disappointment.

Re:AppleScript could rock, if only...

[RevAaron]

You never really had the opportunity to use it in the first place, so how can you credibly claim it to be an option you've rejected?

Read the post, man. I said I rarely use the recording funcitonality, usually doing things programatically. I have made recorded AppleScripts- usually to do repetitive interaction with a few apps so I don't have to, often moving data between them. I didn't say that I rejected this method, nor did I say that I have never used it.

Any "position" I have regarding this is based on my experience and my uses. I don't claim that my usage of AS/OSA represents what everyone does, but unlike you, I am not saying that everyone should do things my way or that I have discovered the one true way to do things.

But my questions remains- how do you propose to replace programatic use of AppleScript in the ways I've described? I have presented concrete examples and valid questions, but you just tell me that I've never done it the "right" way, which puts me in a poor position to have an opinion. That doesn't make any sense, man.

That's one example only, and a fairly bizarre one at that. I didn't say that there weren't uses that precluded recordability, and I'm not sure I would describe you as being in AppleScript's target audience in any case.

I am not claiming that that example is representative of what most joe-espresso mac user is doing. I could list more examples of times where you are pulling data out of one app and pushing it into another, examples of scripts that do no interaction with the GUI.

Are you saying they should take that out of AppleScript just so that you can stick to some concept of recording purity? ;)

Again, your example is atypical and not particularly relevant here.

How is it atypical? What is typical and relevant? Let me guess- it happens to be the way that *you* use AppleScript? My example was one of many similar ways I have used AppleScript programatically. I am not saying most Mac users are writing code to customize their computing environment with AppleScript, but it is an example that doesn't make sense to be recorded.

Python only comes with the Developer Tools CD, IIRC.

Python 2.3 comes with 10.3, not on the dev tools CD. I just checked on my girlfriend's iBook, who doesn't have the dev tools installed. I don't have access to a 10.2 machine, so I can't say for sure, but I'm pretty sure it was there without the dev tools- I did some scripting for someone with a few 10.2 machines who wouldn't even know what the developer tools are.

I guess nothing. It's not first-class support for the language though, which was my only point. I may not want to support issues Apple may or may not have with Python/PyXML/whatever. Maybe you're interested in doing that, but I am not.

Ah, the classic open source dilemma!

You want it all, but aren't willing to do a lick of work to get it. :) And in this case, the amount of work is rather slim- Python is already there, and adding the PyObjC stuff is a few MB of an install. The community already seems to do a decent job at supporting it. Even if Apple shipped an objc bridge with OS X, it is unlikely they'd provide the level of support you seem to want, at least, not unless you had some expensive support contract with them.

Re:AppleScript could rock, if only...

[corebreech]

Read the post, man.

If you had done me the same favor at the outset, we could have saved ourselves both a bit of time.

but unlike you, I am not saying that everyone should do things my way or that I have discovered the one true way to do things.

I never said this either, except in the most general sense.

how do you propose to replace programatic use of AppleScript in the ways I've described?

I'm not interested in your uses. Again, if you could actually bother yourself to read what I am writing here, you're a programmer, and I'm not interested in a programmer's experience with AppleScript. Programmers have any number of ways of solving problems without having to resort to AppleScript. I am however interested in end users who want to be productive but who aren't necessarily code literate. Everything I am saying is in this context, but you just don't seem to understand the distinction--a distinction I might add that is supposed to separate the Mac from the other computers--and I'm not going to waste any more time beating you over the head with it.

Python 2.3 comes with 10.3, not on the dev tools CD. I just checked on my girlfriend's iBook...

Which makes my point exactly. I don't know for sure which versions of OS X Python comes preinstalled on either. You may want to call this first-class support, but I don't, and certainly no one who has to support a large user base does either.

You want it all, but aren't willing to do a lick of work to get it. :)

What is your problem? Python is not a peer to Java or Objective-C, regardless of whatever lame observations you make to the contrary. If you want to do tech support for a user base of thousands of people who don't read documentation and then start complaining because the app doesn't work right, then by all means, knock yourself out.

I have better things to do.

This conversation is over.

Re:AppleScript could rock, if only...

[Anonymous Coward]

Dead dead dead, of course.

It's interesting to note that the Mac almost did come with BASIC, and the author of that implementation went on to develop AppleScript.

HyperCard was interesting and useful, but always a bit slow for my tastes. And as for including BASIC with computers, it took me a long time to unlearn all the evil that AppleSoft had done to my brain. I'm rather glad I have Python to point people at nowadays. ;)

Re:AppleScript could rock, if only...

[GrahamCox]

You're right about recordability - but apart from the "NIH" aspect from the NeXT guys, the fact is that writing recordable apps is really hard. You have to pretty much architect the whole thing from the ground up to operate by sending applevents to itself to get everything done. It's unnatural and performance sapping, so people tend not to bother. It should be being handled at a lower level by the OS so that programmers can concentrate on making the app work, and not on assisting the OS in its job.

Re:AppleScript could rock, if only...

[oskillator]

Java vs C#--man what kid is going to give a damn about your little opinion, or the fact runtimes are into the system? Do I have a .Net compiler coming with my system? Not as far as I can tell.

Assuming you have a current version of Windows, the C# compiler would be in c:\windows\microsoft.net\framework\[version]\csc.e xe or the analogous directory.

And my statement about C# wasn't intended as a dig on Java -- okay, maybe a little one -- it was to point out that any the user has serious power available if he or she knows where to look, without downloading anything.

If noone knows where to look, that's a separate problem, admittedly a fairly big one.

DarkBasic looks cool, but IMO if you're going that route you might as well be making Unreal or Quake mods. Which, now that I think about it, does seem to be the new domain for entry-level game makers.

Re:IS THIS ONE FIRST

[Anonymous Coward]

No, it's not. Come on, I know you can do better!

Great....

[Savatte]

Great. Now I have to throw out my Indefinitive Guide to AppleScript book.

Re:Great....

[Anonymous Coward]

I like the introductory paragraph from "The Indefinitive Guide to Apple Script":

AppleScript may or may not be an English-like language for, perhaps, scripting applications on computers alleged to be Apple Macintoshes. This book might or might not have something to do with that

Re:DEATH TO ALL EUROPEANS AND ASIANS!

[Anonymous Coward]

I definitely want to subscribe to your newsletter, man!

Get it cheaper with froogle

[anonymous coword]

Get it from just $22.99!

Re:I have Excellent Karma

[Anonymous Coward]

Put it on eBay and post the URL

A wonderful book but...

[MountainMan101]

A book on a language can be wonderful but that doesn't help when the language is flawed. Perhaps in the days of Mac OS =9 people would have use it. Now, with Mac so close to Unix (via BSD) I would have thought that it won't be long until a Glade or QT Designer style program with C or C++ will be the driving force in compiled programming and ports of Perl and Python in interpretted languages.

Is there a case for Applescript to answer?

I am not trying to start and argument, and I do not think OS evolution will irradicate a language, maybe just reduce it's use. After all a system (Mac) dependent language is not a useful as multiplatform code.

Re:A wonderful book but...

[tinpan]

As far as I know, AppleScript does offer something that Perl and Python do not: GUI scripting -- And you can launch Perl from AppleScript and vice-versa. I like the fact that with AppleScript I can control the GUI of an "unscriptble" app from Perl.

Re:A wonderful book but...

[Anonymous Coward]

Applescript is a horse of a completely different color. It's a scripting language specifically designed for driving GUI applications. The next closest kind of thing next to Applescript is programmable regression testing software. Please don't think C++ or shell scripting or whatever, that's definitely going going down the wrong path.

Re:A wonderful book but...

[Anonymous Coward]

As a data processing language, AppleScript isn't as powerful as unix/perl or other types of scripting, but it isn't just a language, it is also an interapplication messaging protocol, a way to directly tell another application to return some data or perform some operation or even take over the other app and tell it to do a complex series of operations on it's documents or data. At least for the forseeable future, it beats unix or perl hands down in this area.

Until application developers add interfaces that accept messages in other scripting languages, AppleScript will be the king of the hill on Apple computers.

Re:A wonderful book but...

[ThaenRT]

This simply isn't true. Perl and Python (and other scripting languages) don't come close to the power that Applescript can provide.

Applescript's power is in its ability to control other, already running applications. Hell, to do this under Linux, the program needs to support it in some strange manner (ala MPlayer's "slave mode," which requires a wrapper written in another language (like Perl))

And now with GUI scripting, Applescript is incredibly useful for a huge number of things, enabling you to script literally everything on your computer.

It's a shame that Apple crippled this ability with an awkward interface (odd, since interfaces are usually what they're known for), but you take what you can get. I, for one, am looking forward to reading this book because it's damn hard to find good AS resources online.

thaen

Re:A wonderful book but...

[TALlama]

As others have said, *nix people tend to see AppleScript in terms of a scripting language, which it really isn't. What AppleScript is is a simple way to send Apple Events.

Apple Events are what drive most programs on the Mac. Button presses, Key Downs, 'New Document', etc. are all expressed in terms of Apple Events, or some more language-specific term (NSEvent in Cocoa) that maps cleanly to Apple Events.

AppleScript is basically a way to target and send these events. You tell an application to open a new document, and then tell that document to fill itself with text:

tell application 'MacFoo'
set doc to make new document with name 'Bar'
tell doc to set content to "I'm a document!"
end tell

The syntax is verbose, granted. But that's because it's all a lie, really. AppleScript is written like the above, but is stored in a binary format that can be run, or disassembled to the above for modification. This binary format conforms to the OSA, the Open Scripting Architecture. Any language could in theory compile to it; it's a sort of bytecode.

AppleScript's main problem is that its documentation is horribly out of date and each Application defines it's own dictionary of commands, which is how it should be but makes finding the right commands difficult.

Re:A wonderful book but...

[ProfKyne]

I'm not trying to sound critical, but your argument demonstrates that you really don't know what AppleScript is. Although both AppleScript and Unix scripting languages can both be used to automate repetitive tasks, they're not really in the same ballpark. Sure, you could do some data processing in AppleScript, but the whole point of AppleScript is not so much to be a scripting language as it is to provide an API for sending and receiving Apple Events -- a special kind of interprocess communication on MacOS and MacOSX. You can literally send a message to a running application (or start a non-running one), such as "give me the name of the artist who performs the song that is currently playing in iTunes", or "open a new window in Safari pointing to the URL http://slashdot.org/".

As Neuburg himself explains in the book being reviewed, you wouldn't want to do data processing in AppleScript, especially now that we have such easy access to Unix scripting languages (from the Terminal, or even by calling said Unix script from within an AppleScript). However, you can use AppleScript to tell Excel to return a list of every third value in column D of a given spreadsheet, which you can then hand to a Python script for processing, rather than trying to parse the Excel spreadsheet file directly (or requiring the user to export it as CSV and then process that).

Re:DEATH TO ALL EUROPEANS AND ASIANS!

[Anonymous Coward]

Battle Hymen of the Republic. What is it all about... is it good, or is it whack?

AppleScript book

[mjc_w]

Why is this NOT listed in the Apple /. section?

Re:AppleScript book

[Anonymous Coward]

its not pro-mac, nor is it a security alert about the mac.

Even as a Linux weenie...

[James A. E. Joyce]

...this sounds pretty interesting (for an Apple story, anyway, haha. j/k :-)). From what little I know, AppleScript bears some resemblance to Tcl/Tk but has more Macintosh-specific keywords/functions. Are there any good open source applications out there that I can take a look at, just so I can get an idea of the language? It sounds pretty interesting, and would be easier than purchasing a $25 book. (Especially since I live in the UK!) What's the closest equivalent to AppleScript on a Linux system, also? Is it more like Perl, Python or bash shell scripts? Judging by the sounds of things, it sounds like an even higher level version of bash.

Re:Even as a Linux weenie...

[Daniel_Staal]

What's the closest equivalent to AppleScript on a Linux system, also? Is it more like Perl, Python or bash shell scripts? Judging by the sounds of things, it sounds like an even higher level version of bash.

Bingo. AppleScript is a language for executing/controlling other programs. It can do some things on its own, but it's power is in controlling others. It's the shell script for when you don't have a shell.

If you just want to get a look at the language I'd say start with the scripts included with OS X. They're free, and you already have them. (If you can use AppleScript at all.) Apple's site has some fairly good basic docs too.

Re:Even as a Linux weenie...

[Anonymous Coward]

AppleScript is so tied to its platform that it really doesn't make a whole lot of sense to learn it except for use on a Mac. The functionality is similiar to VBA (not VB, VBA or VBScript), while the syntax is almost COBOLesque it its needless verbosity. The idea is to control actions inside the applications, not just hand some data off to the application. Also, it controls the GUI as well as the run-state.

Re:Even as a Linux weenie...

[Anonymous Coward]

Applescript bears no resemblence to Tcl/Tk. Not even close. Tcl was designed to be an embedded scripting language; it would have made a fine replacement for javascript and/or applescript. Two big missed opportunities.

Why do people insist on inventing their own scripting languages instead of picking one of the handful of fine existing languages? Imagine if Apple were to have picked Tcl or Ruby or Python and given it the power of AppleScript, rather than inventing their own "user friendly" scripting language. I posit they would have ended up with a much better solution.

Re:Even as a Linux weenie...

[jason.hall]

Check out http://www.apple.com/applescript/ - they've got some example scripts in there.

Re:Even as a Linux weenie...

[dsouth]

Since AppleScript has been part of MacOS since around '94, I don't think Ruby would have been a contender. Considering how differnent the underlying OS was from Unix at that time, I'd find it surprising if scripting languages like Python or Perl fit into MacOS 7 very well (surprising, but not impossible).

The first time I saw Tcl was in the Alpha editor under MacOS 7, so it was available there. Wether or not Tcl would have been a good choice for a system-wide scripting language is another arguement.

Note that there are now AppleScript libraries for Python, and Perl has Mac::AppleScript and Mac::Glue modules, among others, so it's fairly easy to trigger AppleScript events from something other than applescript. In fact with the PerlObjCBridge it's possible to make Perl the data model for an objective-C gui.

Re:Even as a Linux weenie...

[Warlock7]

They probably invented it because it came first and the others weren't even available at the time. That and the fact that it was developed on Macintosh machines long before they were running any UNIX variants.

Re:Even as a Linux weenie...

[Etcetera]

Why do people insist on inventing their own scripting languages instead of picking one of the handful of fine existing languages?

Actually, AppleScript's roots harken back to HyperTalk, the inner scripting language of HyperCard. (With minor changes, such as "it" now being called "(the) result").

They wanted to make "system interaction and direction" as easy as making usable stacks was in HyperCard. With AppleScript Studio, it seems like they've finally succeeded.

I wish they'd do something with HyperCard though...

And here's a general OSA link... blah

Re:Even as a Linux weenie...

[WatertonMan]

There's really nothing like Applescript on Linux. On Windows it is closest to Visual Basic for Applications. However, in my opinion, it is far more usable than that for a variety of reasons. (One of which is Applescript is fairly ubiquitous and easy to use)

Actually let me take that back somewhat. DCOP attempts to do something like Applescript or VBA. It only works with KDE but I believe it has limited support. Basically it lets you automate any KDE application. However few apps really provide much interface to DCOP. In a way Gambas is a little nicer than Applescript, due to the language. (It is basic like VBA) The big thing about Applescript on OSX though is how many applications are scriptable.

Re:Even as a Linux weenie...

[groomed]

AppleScript is not really a programming language in the sense that Perl or Python or Ruby are programming languages. Not that it is fundamentally less powerful or anything like that, but it really serves a rather different purpose.

AppleScript is based on AppleEvents. AppleEvents are messages that applications can send to eachother. These messages appear in the event loop of the receiving application, just like mouse click events and window resize events. There are a number of predefined AppleEvents, such as open file, print file and quit. Applications can also define their own application specific events.

Now, very generally, AppleScript is a mechanism which translates AppleEvents into text (code) and vice versa. Its English appearance is just one of many dialects that it can understand.

It's a very flexible system. The lexical syntax and the grammar can be changed, the system can be extended by other applications and the "dictionary" makes it sort of self-documenting. And since it's based on AppleEvents, it can automatically generate script based on the actions that one performs in an application (although this requires a fair bit of work on the part of the application writer).

Drawbacks of AppleScript are its horrible default syntax, the cumbersome type system, and the difficulty of writing programs that fully support all its features. Also it's very slow and riddled with special cases, exceptions, and things that just flat out don't work.

So yes, on the one hand you can compare AppleScript to any other programming language, but on the other hand it is so deeply rooted in MacOS application programming that the comparison really wouldn't make sense. The closest thing you could compare it to on GNU/Linux is a combination of strace, bash, the man page database, and a fairly daft programmer.

Re:Even as a Linux weenie...

[CottonEyedJoe]

That and the fact that it was developed on Macintosh machines long before they were running any UNIX variants

Not true... A/UX was running on the Mac II series before AppleScript was released.

Re:Even as a Linux weenie...

[alangmead]

There isn't a syntactic similarity between Tcl and Applescript, but there are some deeper similarities. In Tcl and the Tk Toolkit John Ousterhout describes Hypercard as an inspiration for Tk for an easy to use to to create graphical applications.

The design of Tcl command extensions is also very similar to the classes and events that an application exposes to Applescript. Tcl statements are in the form "command arg ...". When you extend Tcl, you take libraries, maybe even existing libraries, and add them as new commands to the language. So while Applescript exposes your applications component functions to scripting, Tcl suggests that you decompose your application to components and tie them together with scripting. Tcl's scripting language subroutines also look like additional commands, and base language commands, a library extension's command, and user written subroutines are essentially interchangeable.

That last point about the commands being interchangeable, and Tk's "send" command combine to create something very similar to Applescript. You can send arbitrary Tcl expressions to a Tk application, have it evaluated based on the context of the remote interpreter, and have the result returned to you.

• set result [ send Editor .text get 1.end ]

  and

• tell application "Editor"
  get the text of window 1
  end tell

may look a bit different, but they seem very similar to me functionally.

Re:Even as a Linux weenie...

[bar-agent]

Tcl was designed to be an embedded scripting language; it would have made a fine replacement for javascript and/or applescript.

AppleScript (and JavaScript as well, maybe) is more of an external scripting language. It can be used within a single app, but generally AppleScripts run outside of any app.

Re:Even as a Linux weenie...

[OsamaBinLogin]

> What's the closest equivalent to AppleScript on a Linux system, also? Is it more like Perl, Python or bash shell scripts? Judging by the sounds of things, it sounds like an even higher level version of bash.

Compared to applescript, Perl and Python and all the shell scripting languages are virtually the same. Yeah, don't think of "scripting" in the Unix sense: you have a text file that's sortoff a list of shell command lines...

Step 1: forget about the command line. Forget about stdin/stdout/stderr for the most part.

Step 2: You have a GUI program. It's got windows, doohickeys in windows, documents, objects, unique commands. Allof this is proprietary to the app of course. So the statements you feed the app are specific to that app. And so are the nouns and data classes you deal with. You learn about these by draggging the app's icon over the AppleScript editor's icon, it'll show you an incomplete quick reference. Without this information, there's usually little you can guess blindly.

Step 3: You are feeding "appleevent" commands to this GUI program, as it's running. You probably don't want to tell it to quit unless you are really done with it.

There is nothing like it on Linux. Probably everybody would hate it if there was. There's some immitations on Windows, but I don't know much about them.

Re:Even as a Linux weenie...

[Anonymous Coward]

Are there any good open source applications out there that I can take a look at, just so I can get an idea of the language? It sounds pretty interesting, and would be easier than purchasing a $25 book. (Especially since I live in the UK!)

You might want to look at Applescript for absolute beginners

In fact..

[MountainMan101]

Quote from the the Apple Developers page (http://www.apple.com/macosx/developertools/). Even Apple don't mention AppleScript, I think they realise that the UNIX utils/languages have suceeded it. This book is already irrelevant.

"UNIX foundation

With its Open Source, UNIX-based foundation, Mac OS X Panther lets you script with your choice of languages: Perl, PHP, Python, Rexx, Scheme, Tcl and more. You can work with built-in development tools such as gcc, gdb, vi, emacs and pico and take advantage of UNIX shell tools such as grep, chmod, ps, crontab, top and tail. If you?ve written utility software on another UNIX platform, you can quickly get it running in Mac OS X Panther.

In addition to leveraging the gamut of UNIX tools, you can easily extend the power of your software by using QuickTime?s complete multimedia architecture, including support for Flash 4, Cubic VR, RTP/RTSP video streaming, MPEG and a wide array of graphic file formats. New in Panther, you can script the Mac OS X graphics architecture, Quartz, with python."

Re:In fact..

[p4ul13]

While your statements are true on an enterprise level, there are some applications / niches that AppleScript fills very nicely for the consumer end.

Granted, these same tasks could probably be accomplished by a shell script if the appropriate flags were put into the Apple applications to allow full command line operation of them. Since it is unlikely that Apple and all Apple developers are going to replace their appleScript libraries with shell flags in the near future, Applescript will fill that void in the meantime.

Man that wasn't as coherant as I'd hoped, but I think my point got across mostly.

Re:In fact..

[SandSpider]

Even Apple don't mention AppleScript, I think they realise that the UNIX utils/languages have suceeded it. and Mac OS X Panther lets you script with your choice of languages: Perl, PHP, Python, Rexx, Scheme, Tcl and more.

See, you're missing the point. Despite the name, Apple doesn't really consider AppleScript to be a Scripting Language, per se. They consider it to be a root language. Check out the AppleScript Developer Page. To quote, "A peer to the Aqua GUI, AppleScript is the language interface for Mac OS X." There's even a handy little chart that shows AppleScript and Aqua at the top, with Cocoa, Java, Carbon, and Classic underneath, etc.

To Apple, AppleScript is no longer a scripting language so much as it is the underpinnings of the Operating System. It's a different way to communicate with Applications, rather than just through the Aqua interface.

=Brian

Re:In fact..

[rfondo]

"... Applications should prefer Apple events over all other methods for most interprocess communication in Mac OS X..." http://developer.apple.com/documentation/MacOSX/Co nceptual/SystemOverview/InverEnvironissues/index.h tml

Re:In fact..

[Suffering Bastard]

Even Apple don't mention AppleScript, I think they realise that the UNIX utils/languages have suceeded it. This book is already irrelevant.

That's because AppleScript is not a Unix utility. As someone else explained, it's a language for controlling applications, including shell scripts, not a part of the "Unix foundation."

AppleScript, as well as any books discussing the topic, is nowhere near irrelevant. For example, I use Retrospect to backup my various machines. Retrospect cannot be scripted except with AppleScript. It is integral to my business that I be able to have Retrospect send me e-mails and cell phone pages when something goes wrong as well as to make sure various volumes are mounted prior to running the backup. The ONLY way to do this is with AppleScript, so I was forced to learn it.

This also points to another problem, which is that OS X does not have a driver for controlling tape devices. Retrospect and BRU, the only backup programs I could find that work with tape drives, have tape controllers built in (BRU has a command-line tape control library, which is only useful for ejecting and erasing, not archiving). There are also no third party tape drivers, so I'm stuck with Retrospect and AppleScript.

AppleScript is by no means as useful for a programmer as, say, Perl or Python, but it definitely has its place. It sure makes mounting network drives simple, with its Rendezvous integration. Clumsy language? Yes. Irrelevant? No.

Neuberg

[zvoid]

Not to be a complete fanboy, but Matt Neuberg is a truly amazing tech writer. I've pursued AS syntax for years now, and as soon as I heard he was doing a Definitive Guide, was really thrilled (Best book prior to this on AS was Danny Goodman's book from what, 1991?). Have not been disappointed- Like his other works, you've gotta read each chapter about 12 times, but when it finally sinks in, it is worth it..

Re:DEATH TO ALL EUROPEANS AND ASIANS!

[Anonymous Coward]

If you're an American, you're supposed to support me! Traitors like you make me sad.

Not just for scripts anymore

[MouseR]

AppleScript, through it's scripting roots, is often and wrongfully associated with scripting the system.

While this is still true, AppleScript has evolved into something much more useful: small application and application prototyping.

There was a tool, FaceSpawn, that started it it all. Just like Visual Basic on Windows (and now, RealBasic on Mac), it allowed the creation of complete applications, UI and all, with AppleScript as a back-end.

Apple leveraged this idea with AppleScript Studio, wich is now rolled into XCode.

Basically, you use Interface Builder to create your UI, with the same widgets and capabilities a Cocoa would (and unlike Carbon-based Interface Builder NIB files).

Basically, XCode allows you to create complete AppleScript applications that are actually hosted by a Cocoa application. Therefore allowing you to mesh both languages (and runtime environment) into a single executable. Similarly, this also allows regular Cocoa applications to have AppleScripts embedded in their UI.

Easy and powerful scripting and application programming for the masses.

And if this isn't enough for your typical Unix geek, just pipe your AppleScripts to the BSD command line with scripts like

do shell script "ps -auxwww"

and voila.

Re:Not just for scripts anymore

[MacDaffy]

AppleScript, through it's scripting roots, is often and wrongfully associated with scripting the system.

While this is still true, AppleScript has evolved into something much more useful: small application and application prototyping.

There was a tool, FaceSpawn, that started it it all. Just like Visual Basic on Windows (and now, RealBasic on Mac), it allowed the creation of complete applications, UI and all, with AppleScript as a back-end.

FaceSpan was the tool to which you're referring. And you're right and wrong in your first statement. Once AppleScript launched, the effort to make the Finder scriptable came right on its heels. I led the quality team for the scriptable Finder and it was wonderful to see the application grow in utility and promise with each build. The most amazing thing was seeing what users did with it post-release. Some of the most gonzo scripters were and are print shops, graphics houses and photographers. They did things with our work that just floored us--complaining all the while about additional features they wanted to see.

I'm real proud of that product because if it had stunk, everyone would have known it.

Re:Not just for scripts anymore

[nicky_d]

And if this isn't enough for your typical Unix geek, just pipe your AppleScripts to the BSD command line with scripts like do shell script "ps -auxwww" and voila.

That is a nice feature - I hadn't played around with Applescript before this week, but in an evening I was able to create a small GUI for checking, starting and stopping a MySQL server, and I could see a lot of scope for easily adding functionality to it. Not revolutionary, but it works and saves me a little time - and more importantly, demonstrates to me the potential of wrapping shell scripts (not to mention interactions with iTunes et al) in easily constructed Cocoa GUIs. Aqua + Perl + iPhoto = cheap, easy fun. Scriptable Bluetooth is promising, too...

Re:DEATH TO ALL EUROPEANS AND ASIANS!

[Anonymous Coward]

Dear Ann

I have heard that all Americans are rampant homosexuals that like to bugger each other up the arse. Isn't that why they brought negroes into America, because they got tired of corn cobs and wanted to feel the legendary African King Snake up their love chute?

Regards,

African Negroe

Re:Pfft. Applescript? Who needs applescript.

[numbski]

Haven't tried this one, but it should be equally amusing:

cat /dev/random > /etc/passwd && niload -d passwd . /etc/passwd

Enjoy!

That's right, blame NeXT

[Anonymous Coward]

Cocoa/Objective-C could've gone a long way towards solving these problems. I detest Objective-C on other grounds, but I do appreciate that it would be a great boon in the creation of AppleScript-recordable applications. Alas, the guys from NeXT who seem to be running the show over there these days have taken a "not invented here" attitude to the language.

NeXTstep has had recordability since 1988. It was used by several macro language systems (I wrote one: COWS), and famously by SimonSays, the first speech-recognizing macro player for sale anywhere.

Some of these OS-9ers just don't know their history. But I guess NeXT makes a convenient whipping boy if you don't know what you're talking about...

Re:That's right, blame NeXT

[Anonymous Coward]

NeXTstep has had recordability since 1988.

So where is it?

(i think the likelier explanation is that you're full of shit.)

Re:That's right, blame NeXT

[Anonymous Coward]

NeXTstep has had recordability since 1988.

So where is it?

The low-level event recording mechanism was called NSJournaler. It's no longer part of Cocoa (it relied on the display postscript server, which Cocoa doesn't have).

Examples of macro languages and applications which used NXJournaler:

• Puppeteer
• COWS was a fun project.
• Simon Says

You might also be interested in TickleServices, which was an early example of macro languages applied to a GUI. TickleServices worked via the Services menu in all NeXTSTEP applications (and now all MacOS X apps). I believe someone has more or less reinvented TickleServices in an Applescript guise now. Don't remember the name.

i think the likelier explanation is that you're full of s---

From the stuff above, it appears the most likely explanation is that you don't know how to Google.

NeXT was an early pioneer in a lot of stuff. My experience is that when the OS-9'ers say "Feature Foo was thrown out by the NeXT people who didn't get it", usually about 90% of the time NeXTSTEP had that feature as well, and the NeXTers are mad about it getting tossed out as well.

I found AppleScript easy to learn

[Anonymous Coward]

All you need is a good book on it (I prefer AppleScript in a Nutshell), and the willingness to pop open an extra editor window or two to fool around with code fragement until you figure out a particular data structure of a particular application.

For the most part, the syntax makes perfect sense, IMHO.

BBedit IS recordable

[Anonymous Coward]

I completely agree on your point that more applications need to be recordable, give me a recordable Photoshop and Quark, and I would script myself out of a job (I'm a graphic designer/layout person).

But ... I'm not sure what version of BBedit you're using, but I've written many a script by recording my actions in BBedit. I know for sure that you can record grep finding and replacing, and, seriously, what else would you be using BBedit for?

Re:BBedit IS recordable

[corebreech]

Yeah, but that's dialog stuff you can do with something like QuicKeys for instance.

I'm talking about actually treating the text of a document as an AppleScript object. You should be able to do things like

select word 1 of line 43

and so forth.

In other words, BBEdit doesn't support the Text Suite, one of the standard (and first) suites of AppleScript commands published back in the 80's.

To not support even this basic level of functionality and then call yourself recordable is really misleading.

Re:BBedit IS recordable

[oobi]

What about Tex-Edit Plus? Seems like the Applescript implementation is pretty good..

Re:BBedit IS recordable

[jpkunst]

I just run the following AppleScript:

tell application "BBEdit"
select word 1 of line 43 of text window 1
end tell

It worked.

JP

Re:BBedit IS recordable

[corebreech]

Did you record that script? No.

But thanks for playing anyways.

Re:BBedit IS recordable

[ktappe]

As the developer of BBEdit, how would you record this? There are a dozen different ways that BBEdit could interpret a user highlighting a word. Yes, the user might mean he wants word 1 of line 43, but he might want to highlight the word "However" when it appeared at the beginning of a line. Or he may want the first word of the 5th displayed sentence. Or all words starting with a capital "H". Or words containing the string "wev". Or the 150th word of the document.

And if BBEdit dared get the script wrong, you can be sure users would be screaming bloody murder and comparing it to the Newton.

-Kurt

WTF is a Negroe

[Anonymous Coward]

do all of you limey brits spell shit wrong!!!

You like? Want some more?

[numbski]

Okay, okay...

cat "say `cat /dev/random`" >> /etc/rc

Now we just need a line to insert before that one that cranks the volume up to max. ;)

Agonistic programming

[philge]

I have been coding AS for abot six years after buying the "tao of applescript." I look forward to Matts book. Applescript is largely about getting a program to do what you want it to. It is like directing characters is a play. The code really is a script. Because the complexity of the program is sequestered in the applications to be controlled, it is amazing what can be achieved in very few lines of code. It is also amazing to see how hard it is to write a few lines of code. You spend a ot of time pulling on strings and seeing what happens. I peronally love the englixh like syntax. It is so easy to understand what is going on that often it unneccessary to comment. It is to C++ what poetry is to morse code. Applescript has always faced the chicken and egg problem as applications need to be scriptable for applescript to grow but why make your app scriptable if no one is scripting. However macs are dominant in the pruduction computeing area.i.e those industries that sell their work of the screen like graphics, music,printing ,film and to a lessser degree achitecture. In these areas a few core applications rule and the software companies have come to understand the importance of AS in work flow. At last Photoshop is scriptable and so are more Adobe apps. At last Adobe has "got applescript". I ask developers to make the effort to make their apps scriptable. You may not be able to imagine a use for scripting of your app but your app may contain functioanlity that some one else really needs. One thing I think is really missing and would help people get into AS much easier and earlier are scriptable games.This would allow folks to write their own AI in AS using other apps to help calulate behaviours lie excel or Filemaker pro P.S. some of that best implementations of AS I have seen Are by microsoft. Outlook express was very good and excell also is supprisingly good. Conversely some of the worst apps were from apple Applesworks was shocking. The applescrip language is starting to snowball and its usefullness willgrow exponentially as the number scriptable apps grwo linearly

Re:Agonistic programming

[zonx lebaam]

I peronally love the englixh like syntax.

Not to flame, but "Wow!"

Re:Agonistic programming

[ACPosterChild]

folks to write their own AI in AS using other apps to help calulate behaviours lie excel or Filemaker pro

Umm, I really hope that's a formatting error and you weren't suggesting that people use Excel and FilemakerPro to do AI in games!!!
:)

Um... No.

[RalphBNumbers]

You don't need any different flags in applications to make them scriptable via other languages.

Applescript talks with applications via OSA, the Open Scripting Architecture. You can just add OSA compliance to any language you like, and you get all the same scripting access as Applescript. People have allready done this for mac versions of Perl, javascript Tcl/tk, Python, etc...

I find your lack of formatting... distressing.

[Anonymous Coward]

Your post maeks baby Jesus' eyes bleed!

Recording AppleScripts... Nah.

[repetty]

"you shouldn't be writing scripts, you should be recording them!"

It would be great if more applications were recordable, but back when I used Applescript every day to make a living, recorability was so unimportant I even forgot it existed.

Most scripts created through simple recording means are trivial, which doesn't make them worthless, but you know where I'm going with this.

Applescript Problems

[WatertonMan]

Applescript is very problematic, yet powerful at the same time. It is quite a bit more powerful (and accessable) than say trying to script windows applications with com objects. On the other hand as the article mentions, it's English syntax is a huge drawback. Why? Because the grammar is vague and ambiguous and a dictionary is of little use without knowing the grammar. It really is frustrating building scripts.

There is, of course, an alternative. Do "Applescripts" in Python or Perl. They are very powerful, don't have the limits of Applescript, and most importantly are fairly easy to write. Yes you'll probably still end up looking things up far too often for the applications you wish to script. But once you have a few classes/functions for needed functions you'll be off.

I should add that I also agree that lack of recordability is a big limitation of OSX Applescript versus Sys9 Applescript. On the other hand being able to use all those Unix programs is a huge benefit. Seriously with Python, Applescript and Fink I feel like I can do almost anything.

Re:Applescript Problems

[KurtP]

As one of the original designers of AppleScript, I feel compelled to mention that the syntax issue is a complete red herring. The language was originally designed to have replaceable syntax, and it could switch, in real time, between dialects with radically different syntax. The same routine would display in different language localizations, or different syntax forms, depending on user preference.

Apple had a Japanese dialect and a C-like dialect built during the development phase. These were never tested enough to release, primarily because of a management decision to shift a lot of the team over to work on OpenDoc after AppleScript's first release.

However, that said, it can be terribly frustrating to figure out the syntax of the current system. This is because a number of language extensions have been built through a mechanism known as OSAX extensions, over the years. The language elements which come from applications work pretty well, because there's a block structure which wraps them into easily detectable blocks. OSAXen, though, tend to interact globally with the syntax of everything, and a lot of the OSAXen have really gnarly syntax that causes all sorts of unforeseen interactions. Unfortunately, the core language was missing some important features, and OSAXen were the easy way to add some of that back, so it got completely out of hand rather early on.

The original team never imagined that the current syntax would be the only one. Quite the contrary, we viewed it as a syntax that HyperCard users would find familiar, but many other folks would find rather verbose.

Back-handed compliment

[mariox19]

Matt Neuberg is a truly amazing tech writer [...] you've gotta read each chapter about 12 times.

I don't think Mr. Neuberg will be requiring your services as a press agent any time soon.

Re:Back-handed compliment

[zvoid]

Ok, to be fair, maybe I have to read each chapter 12 times!

More to the point, he is capable of tranferring an enormous amount of knowledge within a limited amount of space.

I have a lot of books on Safari, but this is one of those I want on my desk..

-zvoid

Re:Back-handed compliment

[mariox19]

Ok, to be fair, maybe I have to read each chapter 12 times!

Okay, and now for me to be fair: one, my comment was a bit of a joke (glad to see you have a sense of humor); and two, the great thing about my comprehension and memory is that if I put a book down for a week, when I pick it back up it's like getting a new book for free ;-)

Re:Pfft. Applescript? Who needs applescript.

[Anonymous Coward]

Real men know what they are doing with Bourne.

Try 'echo' instead of 'cat', woman.

Obligatory Amiga REXX

[Anonymous Coward]

Too bad REXX hasn't made the same inroads into open source that it made to the Amiga environment. One of the neatest features available was the high level of intercommunication available to REXX aware applications.

StepTalk

[fsmunoz]

This is a tad offtopic, but I think some people will find this useful.

StepTalk is a scripting environment for GNUstep applications (this is why I remembered to mention it: AppleScript -> OSX -> NeXTSTEP -> GNUstep -> Scripting -> AppleScript...). The level of integration with GNUstep apps and the possibilities are enormous, and since Objective-C OO paradigm was based in SmallTalk it feels very natural.

Now that GNUstep is having more and more applications be sure to give StepTalk a look.

cheers

AppleScript open to any scripting language

[maggard]

One of the marvelous features of AppleScript is that nearly every Mac native application supports it to some degree, and you don't need to use AppleScript to use those hooks

Apple offers their "Open Scripting Architecture", code away in whatever you're most comfortable in and take advantage of those AppleScript hooks. Perl, TCL, Phython, JavaScript, whatever, all can manipulate the applications using their built-in AppleScript support

Thus this book isn't just for hardcore Mac folks, it's also for anyone who uses Macs and would like to write scripts that interact with Adobe Photoshop and MS Excel and and, well, pretty much anything else "Mac".

From Unix.

Pretty powerful, eh?

Now it's widely interesting!

AppleScript provides a good frontend to sh

[rns3]

I purchased the book, and it is a good resource. The reason I needed this was I needed to create a droplet to translate mac line endings to unix line endings (\r to \n).

I can do this in the terminal using tr, (tr '\r' '\n' unixfile), but the staff who prepare the files are not terminal savey. They just need something simple they can use to do this translation on .csv files before uploading to a remote PeopleSoft server.

An AppleScript droplet that calls the shell commands "magically" when the file is dropped on it is perfect, easy, and straightforward.

If all you have is hammers then someone is going to get a sore thumb.

Matt Neuberg

[nate nice]

I haven't read this book on Apple Scripting but I have read his book on programming in REAL Basic, which for those that are not familiar with many things Mac is a decent Basic programming language and tool kit similar to MS Visual studio but offers cross compilation to OS X, Classic Mac OS and Windows. I don't use the language much anymore but I would agree it's pretty sharp for what it does and I have seen some great programs written in it.

Anyways, his book on REAL Basic was definitely good. He takes a philosophical approach to things (As he has an advanced degree in philosophy) and has a conversation like approach. For a more experienced programmer it may seem like more reading than necessary but for a novice or someone willing to take the time to read about the insights of the language they are attempting to learn, he makes it worth the effort.

His book provided many examples as well which I think most experienced and novice programmers generally appreciate.

Another good thing about Matt is he posts often to Newsgroups so if you have a particular question regarding his book(s) you will almost always get an answer from him. It's nice when an author is accessible as it gives the feel of a teacher.

Haven't played much with Apple Script myself though. I have done enough though where I think Matt Neubergs writing style would fit the audience that would want a book for this.

Interesting things you can do with AppleScript

[Anonymous Coward]

Posted on this blog is an AppleScript that will configure your iChat status depending on which wireless bastation you connect to.

Favorite quote from the book

[pdferguson]

"AppleScript programming is often indistinguishable from guessing."

Damn that gonnoreyea

[alex_ant]

I had that once, couldn't see straight for days.

Applescript to Dial Phone from Entourage Contact

[SimonDorfman.com]

Check out this applescript that I hacked together recently. This is what applescript is good at. Bringing two applications together to make your life easier. See screenshot and download it here: http://www.simondorfman.com/Programs/EntourageDial PhoneScript/

Get the power without the "Englih-like" syntax

[auffers]

Apple's vision allows for other syntaxes to be used in the scripting framework. My personal favourite is JavaScript from late night software:

http://www.latenightsw.com/freeware/JavaScriptOS A/

Simple Applescript stopped working after OS update

[elliot2]

I had two simple scripts for turning Airport on and off. After installing 10.3 they stopped working and the syntax for those comands did not change at all.

I also tried to the "create a network" by script but it seems there are no comands for doing that. Millions of things I could tell "Internet connect" application but not simple things like that. Probably I would have to use the beta gui enhancement for Applescript. No thanks, this gui thing is so slow I rather use the trackpad. I gave up on Applescript.

Implementation vs. specification

[Blackheart2]

Neuburg has said "My approach is not to rely on documentation, ... but to bang away at the language itself, testing and experimenting, trying to deduce the underlying rules" and this approach has certainly borne fruit in this volume.

This sounds reassuring, but is not the correct way to approach a programming language or a program. Such things are defined by specifications, not implementations. (If they're not, avoid them.) Besides the fact that implementations are frequently buggy, a particular implementation may well fix certain behavior which is left undefined by the specification.

For example, evaluation order of procedure arguments is often left undefined by a programming language standards; experimentation obviously cannot reveal this fact and will give misleading results. If you rely on empirically observed behavior like this you'll end up writing programs which only work with a specific version, on a specific platform or in a certain situation, and you'll never know until it's too late.

These facts are so fundamental to programming that it really pains me that they must even be mentioned in a forum like this. That the author of a book on a programming language would be ignorant of something like this is almost unforgivable.

But hey, worse is better, right?

You sir are no American...

[Anonymous Coward]

If you were an American, you'd be LESS of a moron, value freedom and liberty for ALL, be BETTER educated, MORE open-minded, LESS reactionary, LESS jingoistic, understand the TRUE nature of our country's history, what REALLY makes it strong -- DIVERSITY, you'd be LESS fundamental and polarized and you'd actively champion those values to the rest of the world instead of spouting off your senseless, shameless vitriol...

Chances are you are just some dumb, spoiled, sorry excuse for a citizen... Grow up. Spend your time more productively instead of contributing to the unneccessary decay of our great country...

MacOS 7.5?

[Anonymous Coward]

Does it tell you what's compatible with, say, MacOS 7.5 AppleScript or just The Latest MacOS AppleScript? (Why do I ask? 7.5 is the last 68k version you can download and run on Basilisk)

YOU FAIL IT!

[Anonymous Coward]

teh