Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Businesses Software Book Reviews Apple IT Technology

AppleScript - the Definitive Guide 140

Posted by timothy from the scriptly-goodness dept.
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.
This discussion has been archived. No new comments can be posted.

AppleScript - the Definitive Guide More

AppleScript - the Definitive Guide

Comments Filter:

  • AppleScript could rock, if only... (Score:5, Insightful)

    by corebreech ( 469871 ) on Friday January 30, 2004 @03:32PM (#8137769) Journal
    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... (Score:5, Informative)

      by ArsCheshire ( 700358 ) on Friday January 30, 2004 @03:39PM (#8137850)
      Apple hasn't, but other people are working on it: take a look at PyObjC [sourceforge.net].
    • 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.

    • 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
      • 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... (Score:4, Informative)

          by WatertonMan ( 550706 ) on Friday January 30, 2004 @05:17PM (#8138670)
          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 [supercard.us]

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


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

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

          • 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 fa
            • 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

    • why not use Python or Perl? much more powerful and easy to use.
      • 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.
    • 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 fi

      • 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,
    • 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 sc
      • 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."

      • 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 w
        • 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... (Score:1, Informative)

      by 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 m
    • "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.
    • Spot on critique of Applescript. I'd mod you up, but your already at 5!

      Winton
    • 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... (Score:4, Interesting)

      by RevAaron ( 125240 ) <revaaron AT hotmail DOT com> on Friday January 30, 2004 @05:40PM (#8138931) Homepage
      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. :)
      • 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 sc

        • Re:AppleScript could rock, if only... (Score:4, Interesting)

          by RevAaron ( 125240 ) <revaaron AT hotmail DOT com> on Friday January 30, 2004 @07:10PM (#8139766) Homepage
          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.
          • 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 bei
            • 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
              • 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, y
    • Yes, recording is great. There is no doubt. But try to record loop. Click and do, click and do...
    • 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.

  • Great.... (Score:3, Funny)

    by Savatte ( 111615 ) on Friday January 30, 2004 @03:33PM (#8137794) Homepage Journal
    Great. Now I have to throw out my Indefinitive Guide to AppleScript book.

    • Re:Great.... (Score:3, Funny)

      by 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... (Score:5, Interesting)

    by MountainMan101 ( 714389 ) on Friday January 30, 2004 @03:38PM (#8137842)
    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.

    • In fact.. (Score:5, Informative)

      by MountainMan101 ( 714389 ) on Friday January 30, 2004 @03:45PM (#8137905)
      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.. (Score:3, Informative)

        by p4ul13 ( 560810 )
        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 t

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

      • Re:In fact.. (Score:4, Interesting)

        by SandSpider ( 60727 ) on Friday January 30, 2004 @04:18PM (#8138177) Homepage Journal
        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 [apple.com]. 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
      • "... 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.. (Score:2, Informative)

        by Suffering Bastard ( 194752 ) *
        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 wit

    • As far as I know, AppleScript does offer something that Perl and Python do not: GUI scripting [apple.com] -- 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... (Score:4, Insightful)

      by ThaenRT ( 542127 ) on Friday January 30, 2004 @04:55PM (#8138502)
      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
    • 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 dr

    • 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 do

    • 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 MacO

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

    • Re:Even as a Linux weenie... (Score:5, Informative)

      by Daniel_Staal ( 609844 ) <DStaal@usa.net> on Friday January 30, 2004 @04:09PM (#8138101)
      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... (Score:1, Interesting)

      by 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 languag
      • 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

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

      • 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 [c2.com], the inner scripting language of HyperCard. (With minor changes, such as "it" now being called "(the) result"). [apple.com]

        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 HyperCa [wired.com]

      • There isn't a syntactic similarity between Tcl and Applescript, but there are some deeper similarities. In Tcl and the Tk Toolkit [aw-bc.com] 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

      • 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... (Score:5, Informative)

      by jason.hall ( 640247 ) on Friday January 30, 2004 @04:17PM (#8138168)
      Check out http://www.apple.com/applescript/ [apple.com] - they've got some example scripts in there.
    • 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

    • 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 a
    • > 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/stde

  • Neuberg (Score:3, Interesting)

    by zvoid ( 706873 ) on Friday January 30, 2004 @03:51PM (#8137960)
    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..
    • 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.

      • 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
        • 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 ;-)

  • Not just for scripts anymore (Score:5, Informative)

    by MouseR ( 3264 ) on Friday January 30, 2004 @04:02PM (#8138055) Homepage
    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.

    • 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 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, demons

  • Agonistic programming (Score:5, Informative)

    by philge ( 731233 ) on Friday January 30, 2004 @04:14PM (#8138144)
    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
  • 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 p

    • Re:Applescript Problems (Score:5, Interesting)

      by KurtP ( 64223 ) on Friday January 30, 2004 @05:02PM (#8138554)
      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 (Score:3, Interesting)

    by fsmunoz ( 267297 ) <fsmunoz@m[ ]er.fsf.org ['emb' in gap]> on Friday January 30, 2004 @05:27PM (#8138789) Homepage
    This is a tad offtopic, but I think some people will find this useful.

    StepTalk [agentfarms.net] 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
  • 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!

  • Matt Neuberg (Score:4, Informative)

    by nate nice ( 672391 ) on Friday January 30, 2004 @06:10PM (#8139255) Journal
    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.

  • "AppleScript programming is often indistinguishable from guessing."
  • 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/ [simondorfman.com]
  • 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/
  • 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.
  • 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 implementa

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close