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...

[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...

[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...

[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...

[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...

[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...

[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...

[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...

[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...

[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.

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

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...

[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

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...

[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...

[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.

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..

[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..

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: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!

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: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.

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: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.

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.

Favorite quote from the book

[pdferguson]

"AppleScript programming is often indistinguishable from guessing."

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

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/