Slashdot Mirror
AppleScript - the Definitive 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.
Apple hasn't, but other people are working on it: take a look at PyObjC.
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."
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 likeand voila.
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.
'Sensible' is a curse word.
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
Check out http://www.apple.com/applescript/ - they've got some example scripts in there.
I've been using AppleScript almost from the beginning (1994) and agree with most of your criticisms except "you shouldn't be writing scripts, you should be recording them." In my experience, the only time I've found recording to be of any use is to discover how an application expects it's events to be called and what parameters the event accepts. As you point out the dictionaries are often awful and recording is a useful trick to use when confronted with bizarre or counterintuitive syntax.
In my mind, the most useful scripts are those that use loops and branching and recorded scripts can't do that. Recorded scripts also often specify the target of a command (files, folders, or other objects) so specifically (exact file or folder names) that they are essentially useless except for processing the specific object that was selected during the record operation. It is easy to open the script and tweak it by hand to handle loops or branching etc, but they are very rarely useful as recorded.
I'm talking about actually treating the text of a document as an AppleScript object. You should be able to do things like 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.
Is this truly the only Earth I can live on?
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.
Supercard
It looks quite native for OSX and has a trial version you can download. If you miss Hypercard you may like it.
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!
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
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.
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.
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
I just run the following AppleScript:
It worked.
JPExamples of macro languages and applications which used NXJournaler:
You might also be interested in TickleServices, which was an early example of macro languages applied to a GUI. TickleServices worked via the Services menu in all NeXTSTEP applications (and now all MacOS X apps). I believe someone has more or less reinvented TickleServices in an Applescript guise now. Don't remember the name.
From the stuff above, it appears the most likely explanation is that you don't know how to Google.
NeXT was an early pioneer in a lot of stuff. My experience is that when the OS-9'ers say "Feature Foo was thrown out by the NeXT people who didn't get it", usually about 90% of the time NeXTSTEP had that feature as well, and the NeXTers are mad about it getting tossed out as well.
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/
--
A little nonsense now and then is cherished by the wisest men. -Willy Wonka
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.