Slashdot is powered by your submissions, so send in your scoop

 


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

Teach Yourself AppleScript in 24 Hours 202

Posted by timothy from the next-week-how-to-cure-all-known-diseases dept.
honestpuck contributes this review of Sams Publishing's Teach Yourself AppleScript in 24 Hours, writing "The market for books on AppleScript cannot be a large one, since there never seem to be many volumes in it; usually only one at a time is up to date and worth the money. Now that O'Reilly's AppleScript In A Nutshell is showing its age (and wasn't that great in the first place), and Danny Goodman's book is even older, I was pleased to hear that this volume had come along." Read on for honestpucks' mixed impressions of the book.
Teach Yourself AppleScript in 24 Hours
author Jesse Feiler
pages 432
publisher Sams Publishing
rating 7
reviewer Tony Williams
ISBN 0672325187
summary Not a bad introduction to AppleScript but leaves off far too early.

Teach Yourself Applescript in 24 Hours (TYA) from Sams Publishing is certainly up to date: it covers Applescript under OS 10.2 and the use of AppleScript Studio to build GUI applications using the language. That's its strength. The book's first weakness, though, is that it starts too far down the learning curve in my opinion. The first few chapters of TYA could be read by someone almost totally new to the Macintosh -- they cover such basics as running the scripts installed with the OS and getting new scripts from Apple and installing them. At the same time, they introduce basic AppleScript programming terminology not really required for these sorts of tasks such as suites, classes and commands. This material would have best waited a few chapters. It is not really until 'Hour 6', most of the way through the first part of the book, that it really sorts itself out and gets down to really teaching you AppleScript.

The Basics

The book is divided into four parts: 'Getting Started With AppleScript,' which covers using scripts and basic programming concepts; 'Writing Scripts With Script Editor,' which takes you through using the Script Editor, details AppleScript syntax and how to script the Finder and various applications and using AppleScript Dictionaries; 'Working With AppleScript Studio,' which covers building AppleScript-based GUI applications using Project Builder and Interface Builder all the way through to complex applications that can store and retrieve documents; and a final section 'Advanced Scripting,' which covers Script Objects, scripting across a network (including SOAP and XML-RPC), and integrating scripts with the terminal and cron.

Each section is then divided up into chapters designed to be worked through in less than an hour ,with a small number of short exercises at the end. I found that most chapters took me about half an hour before I reached the exercises, which then took ten to fifteen minutes.

As you can see, almost everything you could ask for is touched on in this book. Once over the introductory chapters, I found the book to be well laid out, well structured and well written. I particularly liked Part III on AppleScript Studio; it started easily and worked up to quite an advanced little application explaining everything well along the way.

The Bad

There are some things missing, however. Debugging is hardly mentioned (3/4 of one lesson), and debugging is not exactly trivial in AppleScript. I also found no mention of my pet demon with AppleScript; its incredibly strong typing and problems with having data in the wrong type; this is a classic problem with files and file names. In reality, this book teaches you the language without really getting down to teach you how to program in the language. A fine distinction, I know, but after just reading Learning Perl Objects, References & Modules, I found TYA to be light on real examples and real world code. Even the best section, the one on AppleScript Studio, didn't touch on many things you will need to know.

Sams have a page devoted to the book at the Sams web site, but frankly the URL is so long and cumbersome I don't dare risk putting it in a post. Go to the site and type 'AppleScript' in the search box. It has the table of contents and a sample chapter and some of the code from the book. The sample chapter is the third chapter 'Running The Scripts You Already Have' and really doesn't give you a good feel for how the book teaches you AppleScript programming. The page to download the code examples says "All the code developed for the book in one convenient download," but in fact all you get are the AppleScript Studio projects and source from four of the chapters. Oh, and the introduction says "There are even a few goodies on the web site that aren't in the book" -- they sure must be good as I couldn't find them.

In conclusion, I think this book starts too far down the learning curve and leaves off too early, with not enough detail. It seems a shame, what we have here is well laid out and well written, I wanted it to be better after I had finished. This book might suit someone absolutely new to the Mac who wanted to learn enough AppleScript to perform a few basic operations, for everyone else it'll be better to wait till October when AppleScript 1-2-3 will be out from Peachpit and AppleScript: The Definitive Guide will be out from O'Reilly, and we might have a better option. If you absolutely need to get some help with AppleScript Studio then borrow someone else's copy or find one second hand.

You can purchase Teach Yourself AppleScript in 24 Hours 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.

Teach Yourself AppleScript in 24 Hours More

Teach Yourself AppleScript in 24 Hours

Comments Filter:

  • I've got a better book for you. (Score:5, Funny)

    by SpanishInquisition ( 127269 ) on Wednesday August 27, 2003 @12:30PM (#6806410) Homepage Journal
    Forget VBscript in 5 minutes.

  • Is it Mac Day?? (Score:5, Insightful)

    by jimson ( 516491 ) on Wednesday August 27, 2003 @12:32PM (#6806430) Homepage
    Along with Mars day or what?

  • Resources (Score:5, Informative)

    by daeley ( 126313 ) * on Wednesday August 27, 2003 @12:33PM (#6806434) Homepage
    For those with AppleScript Studio [apple.com] and the Developers Tools installed, head on over to this path for all kinds of cool info: /Developer/Documentation/CoreTechnologies/AppleScr iptStudio/

    There's also online resources, naturally: Apple's AppleScript site [apple.com], AppleScript Studio Essentials [apple.com] docs, the AppleScript Studio mailing list [apple.com], and lots of other stuff [apple.com].

  • This belongs on apple.slashdot.org (Score:4, Funny)

    by Anonymous Coward on Wednesday August 27, 2003 @12:33PM (#6806436)
    Now post another kde vs gnome flamewar.
  • I give this book my lowest rating ever...seven thumbs up!

  • Get it from just 12.49! (Score:3, Informative)

    by Anonymous Coward on Wednesday August 27, 2003 @12:35PM (#6806462)
    Froogle price comparisian for this book [google.com]

  • Somewhat off topic but... (Score:3, Insightful)

    by davidsheckler ( 45018 ) on Wednesday August 27, 2003 @12:37PM (#6806473) Homepage
    Why applescript? Why not a scripting language
    that does all that applescript does and is
    also crossplatform? This is not meant to bash
    applescript, which is a fine scripting language.
    It's just that applescript won't run on Win32,
    *NIX, VAX ... Other scripting languages will
    (python, perl and javascript even).

    -d
    • I'm right there with you... Personally I have had a hard time finding even the motivation to learn Applescript, when I already have bash and perl at my side. I guess I'm just getting lazy...
    • >
      > Why not a scripting language that does all that applescript does
      > and is also crossplatform?
      >
      AppleScript can do stuff at the OS level that cross-platform scripting languages can't -- that's what the trade-off inherent in being "cross-platform" means.
      Now, if there was, say, a Perl module that handled calls into an application's scripting dictionary, like AS has, I'd be mightily impressed.
      I've never really written AppleScripts, but when I got a script from someone else, its power al
    • you're so absolutely right; coming from a guy who once considered, albeit for only briefly, learning applescript 'cos i just had a new mac. Eventually i decided to remain/go with open source languages such as python/perl/ruby/tcl, but only 'cos my interest was scripting general mini-apps. that said though, applescript on apple is interesting, if your intention is to keep your mac for a considerably long period for it to be worth is. I don't think the comparison with perl/python/js is a fair one 'cos apples

    • Re:Somewhat off topic but... (Score:4, Informative)

      by taybin ( 622573 ) <taybin.taybin@com> on Wednesday August 27, 2003 @12:54PM (#6806652) Homepage
      Why applescript? That's because mac applications can include "dictionaries" of commands that applescript can use. Try scripting photoshop and filemaker in python or some other language.

      That's applescript's true power really. If it was just used as a standalone language without outside application support, it would be fairly weak.

      • Re:Somewhat off topic but... (Score:5, Informative)

        by follower-fillet ( 140975 ) on Wednesday August 27, 2003 @01:06PM (#6806748) Journal
        > Why applescript? That's because mac applications can include "dictionaries" of commands that applescript can use.

        Actually:

        "The Open Scripting Architecture (OSA) is an API that provides a standard mechanism for creating scriptable applications and for writing scripting components to implement scripting languages. The AppleScript component implements AppleScript, the standard scripting language defined by Apple, but developers can also write scripting components for additional scripting languages."

        -- <http://developer.apple.com/documentation/Carbon/R eference/Open_Scripti_Architecture/>

        So you're not restricted to using AppleScript to get those benefits.

        Python, for example, is able to both send and receive Apple Events.
        • but developers can also write scripting components for additional scripting languages.

          That reminds me WHS in Windoes. But the history shows that script programmers on Windows prefer Python and Tcl without WHS.

          • One difference is that (I believe) OSA has been around longer than WHS, and less of an afterthought/add-on.

            As far as I understand it OSA is like WHS + COM (or whatever it is these days). In fact you can even send AppleEvents over networks (if you enable it).

            So, Python + win32 COM bindings is somewhat equivalent to Python + AppleEvent/OSA bindings.

            I think OSA/AE is more integrated into the environment with most applications at least supporting the "Standard Suite" which includes opening & closing docu
        • So you're not restricted to using AppleScript to get those benefits.

          And in fact, the OSA is more than a theoretical possibility. There's a free Javascript OSA module [latenightsw.com] available...use Script Editor to control your mac using Javascript!

      • > Try scripting photoshop and filemaker in python or some other language.

        Just in case you're interested, a quick Google (for Python and Photoshop or Filemaker) brings up:

        http://opensource.adobe.com/ (Stuff seems to be Windows only.)

        Plus references to using Python + AppleEvents including:

        http://www.letterror.com/code/fmpro/
        http://hom epage.mac.com/vng1/FileSharing14.html

    • Applescript is easier, that's why (Score:4, Insightful)

      by ianscot ( 591483 ) on Wednesday August 27, 2003 @12:55PM (#6806660)
      For the people who use it, Applescript is a whole lot simpler than something like PERL. Take a look at the syntax somewhere, you'll see the difference.

      And who are those people? Graphic designers have loved Applescript for a looong time, because they can write stuff for Photoshop without any hassles. Big advertizing departments will often have a huge collection of legacy scripts they've written for various big tasks -- "See the dimensions of all the graphics in this directory and add those numbers, formatted this way, to the end of the file names." They aren't programmers, their minds don't work that way, but they do have large programmatic tasks they need to get done.

      Let's put it this way: I saw that title, "In 24 Hours," and I wondered how it could possibly take that long.

    • The way that Applescript works with the Apple GUI is what makes it interesting to me. I tend to use bash scripts for most things, but Applescript is great for doing "Point and Click" type operations which bash isn't so good at.

      my 2 worth
      • Actually the syntax of Applescript is its greatest weakness. It is one of those "incredibly easy to read, a pain to write" languages. This was less of an issue back when most applications were recordable. You'd hit record and it would generate an Applescript to do what you just did. Then you could modify it. Right now though only a small handful of Applications support recordability and none of them are the main productivity applications. So it is sadly of little use.

    • Re:Somewhat off topic but... (Score:5, Interesting)

      by kennylives ( 27274 ) on Wednesday August 27, 2003 @01:01PM (#6806719) Journal
      2 things come to mind...

      First is that Applescript is great for automating Applescript-aware applications (including Finder) without having to either brute-force it, or write whatever function you're after yourself. For instance (I'm working from memory, and it's been a while since I've worked with this stuff, so it's probably not syntactically correct):


      tell "itunes"
      play "Macintosh HD:MP3 Collection:some tune.mp3"
      end tell
      ...and AppleScript takes care of all of the fiddly details of how to communicate with the application.

      Second, this can be done remotely, assuming that AS-remoting is enabled at the target. Which would get really tricky to do with Perl or Python or even Expect.

      IIRC, it would just be a matter of changing the tell to something like tell "itunes" on "Kenny's Macintosh". The rest of the script would remain the same. But then, debugging is a real nightmare...

    • Applescript is an application scripting language. I sure there is YACC/LEX code floating around for the language. So in theory it wouldn't be that hard to port.

      Python, Perl and to a lesser extent Javascript aren't designed for this. (I say lesser extent Javascript, since there actually is a version of Javascript that compiles to the same format Applescript uses and works in the same way)

      Javascript OSA [latenightsw.com]

      One must also point out that there are glue modules for Perl that allow it to do most Applescriptin

      • Just to add to the above, if you use MacPython, they you do get more Applescript-like functionality. i.e. for controlling other Applications. There is some confusion on this since Apple supports the standard Python. MacPython, while using the same language, is technically a different beast. A lot of the language extensions work in MacPython but not the command line Python (and not the variant Python that you may have installed with Fink). Confusing? Yes. But MacPython includes a nice IDE so is useful

    • Because the AppleScript implementation on MacOSX gives you programmatic access to Apple Events. Those don't exist on any other platform. Apple Events let one application communicate directly to an API established by another application. In other words, AppleScript is less a scripting language (like Perl/Python/etc) and more a way of executing a series of Apple Events, with limited additional scripting capability.

      Yes, it's a very niche market, but folks like Pudge have been working on ways to communicate

    • Why applescript?

      I've got a better question.

      What am I going to do with the other 22 hours?
    • Eh, there's nothing wrong with being good at your niche. While it's handy to have cross platform languages, sometimes there's no need to do so. Actionscript is great for Flash, but would be stupid for system admin, just because it wasn't designed for it.
    • Why Applescript? Because sometimes you are scripting things that are platform specific.

      For example I just finished up part of a Filemaker solution that uses PDF Services in OS X and Applescript to generate, name, and move to a destination folder PDFs from Filemaker records. Picking up the necessary Applescript knowledge to do this took extremely little time compared to what it would have taken me to learn PERL, for example.

  • The problem with this and all other 'in 24 hours'. (Score:5, Funny)

    by Kenja ( 541830 ) on Wednesday August 27, 2003 @12:38PM (#6806477)
    The problem with this and all other 'in 24 hours' is that they don't come with the 24 pack of red bull needed to keep reading the bastard for a full day. And of course in the morning you'll have forgoten everything but the title of the book.
  • I though it was common sense to stay away from all "Learn [Language] in 24 Hours" books.
    • It depends. Some of the authors are actually good, and the just do the "24 hours" thing for name recognition. Most, however, really do suck.
    • I though it was common sense to stay away from all "Learn [Language] in 24 Hours" books.

      A friend sent me a copy of Learn PHP4 in 24 Hours; I've found it to be quite good! I'm a Perl hacker, not a newbie, so most of the syntax is identical; I just have to learn about new things like... variables are scoped to the function, not to the block; arrays really work like hashes and don't always have consecutive numbered elements; elseif is spelled with an e in the middle.

      However, I have noticed a surprising nu
  • ever learned X in 24 hours like the book title says?

    • Re:Has anyone (Score:2, Interesting)

      by error502 ( 694533 )
      Yes. Just not with any of the "...in 24 Hours" books.
      • "Has anyone ever learned X in 24 hours like the book title says?"

        I think it's more about being able to put another bullet point on your resume before you send it with that job application that requires X skill as opposed to truly learning the language in depth. Any experienced coder can learn the basics of a programming language in under 24h but to actually competently code a large project, it takes a lot more practice an in depth study.

        • Any experienced coder can learn the basics of a programming language in under 24h but to actually competently code a large project, it takes a lot more practice an in depth study

          I presume you havent played around with python yet? Seriously dude. Thats a 24h mastery cycle. Perhaps a little longer to find all the best fun in the libs.
    • Yeah.

      'What not to do...'

  • Applescript Additions (Score:5, Informative)

    by Squidgee ( 565373 ) on Wednesday August 27, 2003 @12:39PM (#6806492)
    Apple's beta [aple.com] of GUI Scripting allows for Applescript to click menus and buttons like a person; a fun addition you should check out if you're into Applescript.

    It adds a whole new dimension of customizability to Mac OS X; now you can script your Mac to the same level you can script Linux/*BSD/Unix. =)

  • I've owned Macs for a while and I've dabbled with Applescript for maybe 10 minutes at a stretch every couple of years or so. Really, is it that useful? Strikes me it's great in theory, but like Speech recognition it doesn't deliver... How many times a day can you get a kick out of asking your Mac 'What time is it?'
    • I wrote a semi-automated (as in, easy enough for for high school teachers to use) network-based hard drive image restore system using AppleScript. It booted off a CD, then loaded the image from a network server. Then, after rebooting, it asked a series of questions that properly set the computer's network name, IP address, etc. (Yes, I know there are tools to do all of this automatically. For reasons I'm not going to go into right now [suffice it to say that it was at a school district] they were all unacce
    • Hi,
      Well, for starters, you can automate any repetitive task or workflow in programs that support AppleScript (for example, PhotoShop, Illustrator, BBEdit, FileMaker Pro, Quark, etc.), have said apps interact with one another passing information back and forth, etc. AppleScript is pretty much a prime reason why the publishing industry is so fond of it. Instant automated workflow routines with a click of a button. Also, in relation to speech recognition, you can use Applescript to automate gobs 'o stuff on yo

    • Re:What is it good for? (Score:3, Informative)

      by larkost ( 79011 )
      I actually use AppleScript for a one-off project about every other week. I am maintaining a cluster of FileMaker Pro databases, and there is a lot of data that needs to be massaged. For things that need to touch outside files for their information, and can't be simple imports, I find AppleSctipt very useful.

      I have also worked with AppleScript Studio, and it makes creating small programs on MacOS X very simple. You can even use it to glue nice GUI's onto scripts or other small program segments. I wrote a sm
    • Really, is it that useful?

      Yes. It runs a great deal of my house-- and if I wanted to, I could tie the speech recognition stuff in and voice-control the lights and such, but I didn't want to mess with wiring a mic into every room in the house, or have to remember to put on a lavalier mic every time I walk in the door. I instead opted for a couple closeout 3Com Audreys strategically positioned in my house, and wrote a comprehensive web interface.

      I use this [shed.com] to talk to the X10 modules, and this [sentman.com] to embed Appl
    • I work for a company that does all the logistics work for large conventions and have rather stumbled into the role of writting all Appplescript code. We have several scripts around the company (one for doing releases, one to start clients etc..) and we implemented a great number of features in our in house software by executing small snippits of applescript code from inside our app. So yeah, it's extremely usefull. (Maybe I should say Apple events ar extremely usefull since we tend to do applescripts instea
    • There seems to be quite a bit of Applescript used internally by software installers. (If you watch carefully when Photoshop 7 is installing on OS X, you'll see it launch Applescript to do part of its installation.)

      For the "end user", it all depends on how often you perform repetitive tasks. Applescript can be written to launch specific programs, perform specific functions to a given file, save the changes, and cleanly exit the apps when done.

      On the other hand though, I think some people get a bit carrie

  • Teach Yourself Programming in Ten Years (Score:3, Informative)

    by willpost ( 449227 ) on Wednesday August 27, 2003 @12:42PM (#6806531)
    "either people are in a big rush to learn about computers, or that computers are somehow fabulously easier to learn than anything else. There are no books on how to learn Beethoven, or Quantum Physics, or even Dog Grooming in a few days."

    "Let's analyze what a title like Learn (this_language) in Three Days could mean:"

    "* Learn: In 3 days you won't have time to write several significant programs, and learn from your successes and failures with them. You won't have time to work with an experienced programmer and understand what it is like to live in that environment. In short, you won't have time to learn much. So they can only be talking about a superficial familiarity, not a deep understanding. As Alexander Pope said, a little learning is a dangerous thing."

    "* (this_language): In 3 days you might be able to learn the syntax of (this_language) (if you already knew a similar language), but you couldn't learn much about how to use the syntax. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using (this_language) syntax, but you couldn't learn what (this_language) is actually good (and bad) for. So what's the point? Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". One possible point is that you have to learn a tiny bit of (this_language) (or more likely, something like Visual Basic or JavaScript) because you need to interface with an existing tool to accomplish a specific task. But then you're not learning how to program; you're learning to accomplish that task."

    "* in Three Days: Unfortunately, this is not enough, as the next section shows."

    http://www.norvig.com/21-days.html [norvig.com]
    • Programming is not as highly skilled a task as you seem to think it is. Anyone with the desire can learn to do it, and start accomplishing what they need quickly.

      In the case of a scripting language, they probably want to automate sorting their mp3s for their iPod or other trivial tasks, not write a complete 3D imaging application - and even so, it's not programming skills that would help you, but your knowledge of 3D mathematics.

      You are exactly the type of self-absorbed pompous asshat that makes me const
      • Programming is not as highly skilled a task as you seem to think it is. Anyone with the desire can learn to do it, and start accomplishing what they need quickly. [snip] You're not as important as you think, anyone could do your job.

        The issue is that most people do not have the desire to learn it to do it properly. No doubt I can read a book on dog grooming in 24 hours, and start snipping away the next day, but does that mean I'll do a good job? Know the best techniques? Have anything other than the most
      • "Programming is not as highly skilled a task as you seem to think it is."

        Two things:

        a) for anything above trivial stuff, yes it is.

        b) even for trivial things, at least in america, a lot of people have trouble with logic. They just don't get the concept "in order for the system to spit it out, it has to be put in there by someone". In addition, they have no idea how to structure a large project, or even set goals so they can do it in several smaller projects.

        Even people with CS degrees seem to have
    • "either people are in a big rush to learn about computers, or that computers are somehow fabulously easier to learn than anything else. There are no books on how to learn Beethoven, or Quantum Physics, or even Dog Grooming in a few days."

      While I do agree that your post was informative, I don't think the author whom you're quoting understands the main reason why "Learn $Software_Package in 24 hours" books are so popular. Namely, it's because the computer industry changes so quickly that often people are

  • having used AppleScript before, I don't see how anything other than a syntax reference would be too useful (and as previous posters have pointed out, such references are available online for free).

    there must not be any good SCO stories for today...

  • Useful with the right tools (Score:3, Interesting)

    by TJ6581 ( 182825 ) on Wednesday August 27, 2003 @12:49PM (#6806585)
    I see a lot of posts asking why Applescript is useful. Here's one good reason. Salling Clicker [mac.com]. If you have a bluetooth phone and a mac you can write scripts to do just about anything. The sample ones will control iTunes and the DVD player. I have seen scripts for automatic away messages in iChat when you leave bluetooth range. Some people even use it to control presentations. Check it out it's pretty cool.

  • Oh, Applescript... (Score:4, Insightful)

    by perrin ( 891 ) on Wednesday August 27, 2003 @12:49PM (#6806594)
    "debugging is not exactly trivial in AppleScript"

    No, it is not. I've dabbled in two dozen programming languages, and Applescript is the one I've hated the most. It tries to be normal English but because of its strong typing you have to write the sentences exactly correct, which is annoying and hard to figure out once you get past the simplistic 'hello world' stage.

    The way you need to string the words together is not obvious, and is sometimes not even proper English. I really wish Apple would wise up and drop it in favour for something more intuitive on the advanced level, like javascript or python. /me waits for Mac zealots to moderate this as a troll...

    • Re:Oh, Applescript... (Score:2, Informative)

      by Frobozz0 ( 247160 )
      Apple does let you use JavaScript OSA syntax. You can install it and start writing in a syntax you're more compfortable in.

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

    • Totally agree, although most of my experience was however with Mac OS 7, 8 & 9. File data types I found were the worst, because Applescript in Mac OS 7, 8 & 9 had 3 types: alias, a file path string and the (incredibly brain-dead) Finder "file xyz of folder abc of folder def of desktop" or something. You were always having to coerce between all 3 to get anything done. I don't why they could not have just settled on one data type for files.

      Also debugging was complicated by the fact that Applescript w

    • /me waits for Mac zealots to moderate this as a troll

      I wouldn't moderate it as a troll, but I would moderate it as "-1 uninformed".

      [jmibook:~] jm% whereis python
      /usr/bin/python

      [jmibook:~] jm% whereis perl
      /usr/bin/perl

      Maybe it requires the developer tools; a large download, but still free. [apple.com] Apple has simply left Applescript in place for those who prefer it. You can even call shellscripts from AppleScript Studio, so don't even have to use AppleScript to take advantage of AppleScript Studio's GUI hook
      • Python and Perl are great, but you end up typically just embedding Applescripts in them. You can create objects for some AppleEvents, but you then end up writing modules for the Applications you script. It can be done but rarely is worth the effort.

        Javascript, as the parent post mentioned, would be great. Unfortunately it doesn't really work well as a OSA in practice. Especially when trying to get objects in other Applications. (Perhaps other peoples milage varies - but I was excited about the Javasc

    • Strong typing? (Score:2, Informative)

      by MacDork ( 560499 )

      but because of its strong typing you have to write the sentences exactly correct

      You mean proper syntax? Most every language I've ever used enforces that. Strong typing in AppleScript?

      on run

      set x to "A string"

      foo(x)

      set x to 1

      foo(x)

      set x to x as string

      foo(x)

      end run

      on foo(some_var)

      display dialog some_var

      end foo

      That script will run. Definately not strong typing.

  • Most people _are_ beginners. (Score:5, Insightful)

    by xanderwilson ( 662093 ) on Wednesday August 27, 2003 @12:54PM (#6806647) Homepage
    The book's first weakness, though, is that it starts too far down the learning curve in my opinion. The first few chapters of TYA could be read by someone almost totally new to the Macintosh -- they cover such basics as running the scripts installed with the OS and getting new scripts from Apple and installing them.

    Most Mac users I know don't know or do anything with AppleScript, so I don't think it's a mistake to start where it does. I have the old O'Reilly book which is still great as a quick reference, but I'll have to see this one for myself before recommending it to people. IMO, a lot of people who could really benefit from using AppleScript daily aren't because they feel it's too techy for them. Maybe this book is what those people need. On the other hand, I haven't heard anything about 1-2-3, but I've had good experience with a few of Peachpit's books.

    Alex.

  • Remember Hypertalk, Apple's first try at scripting? The executable syntax was borrowed from COBOL-60. The data structures were worse: "field 3 of line 2 of card 1352".
    • I used to do a lot of HyperTalk. I even wrotes me some XCMDs in C, baby. (Since lost all the source code.)

      You didn't have to refer to the fields and cards by number all the time, you could (and should) give them names and refer to the names instead. Also, as any good programmer would do, you'd use a variable to hold the current card. This is particularly helpful when recursing a stack.

      I still have my HyperCard 2.1 disks and most of the stacks I wrote all saved on quickly disintegrating floppies.

      As for Ap
      • You didn't have to refer to the fields and cards by number all the time, you could (and should) give them names and refer to the names instead. It slowed down considerably when you used named fields. Lookup was a bottleneck. Even the manual admitted that.

        Hypertalk always seemed to be a bad bolt-on to the Hypercard concept. There were some good ideas in there.

        Anyone remember Train Set? Ever look at how it worked?

    • I created Cannons and Castles [phroggy.com] in HyperCard, a sort-of port from an Apple II game. I attempted to make it as unHyperCardlike as possible, which I accomplished with lots of XCMDs and a hell of a lot of coding.

      I must agree with the AC: HyperTalk was great. It had a gradual learning curve, it made basic things simple, and reasonably interesting things possible, if occasionally tedius. It prepared me for OOP - in HyperCard objects such as buttons are tangible rather than abstract (you can create them, move
  • I've often wondered who uses applescript. Even in the days of OS 9 its dorky syntax never seemed appealing. Now with OS X you can use something like perl. If you use BBEdit you can run perl scripts right from the editor. I would think that the market for applescript is shrinking everyday.
  • I have a mac. Ok. I was a fanatic for a while, extolling the virtues of Apple at the expense of Microsoft, etc, but I've outgrown it. A little ironic that Apple and Apple concerns are such flamebait here on slashdot... First, all computers are Machines. They (and their software) are all simply tools to get things done in different environments. AppleScript is a useful tool, and a fairly comprehensive and easy to use one. Doesn't this have its place? Shouldn't the digital community see a good tool a

  • AppleScript Problems (Score:3, Interesting)

    by buckhead_buddy ( 186384 ) on Wednesday August 27, 2003 @01:29PM (#6806941)
    The big lie I always hear about Applescript is that: "Applescript doesn't need lots of documentation, it's self-documenting, english-like, and always current"

    While it's true that the little 3rd party documentation out there has major problems (this book, an overly simplistic Jesse Feiler book, an out-of-date Danny Goodman book, and a Mac OS 9 focused O'Reilly reference), I disagree that AppleScript doesn't need documenting.

    Foremost, it needs some strong documentation on how application writers should be writing their AppleEvent suites and AppleScript dictionaries. This is by far the most non-standard, conflicting, and outright stupid place to ignore.

    Apple has made some half-hearted efforts to write some "standard dictionaries" for suites of software, but if you think css and html are under-specified you haven't looked at these "standards". There's no impetus for you to build the entire "standard" suite into your software. I'm not sure that anyone (including Apple) ever wrote software that actually implemented things like the database suite.

    One problem with not standardizing on open, well specified suites is that you can lose all of your script savyness when a key application is discontinued or decides to overhaul their script interface. Those who wrote MacWrite Pro scripts had their work obsolesced overnight when MacWrite was discontinued. Quark scripters are undergoing some pains right now trying to adapt to the new Quark interfaces.

    Of course, because AppleScript exposes your data model for all of your competitors, you'll make things like exporting data out of your proprietary file format a trivial operation if you stuck with standard suites or even if you exposed all of your functionality via AppleScript. So making fully AppleScriptable applications is not something that the big guys want to do with their data engines.

    Beyond standardization though, AppleScript needs a central repository of script dictionaries and plugins. Right now one's Mac will pick out all of the AppleScript dictionaries on your mac, but what you're trying to automate might be 1,000 times easier in GraphicConverter rather than Photoshop, but if you don't have GraphicConverter on your mac you'll be beating your head against a wall trying to force an app to do something it's not good at. The best one can do today is watch over other people's shoulders via web sites, bbs's, email lists, and by downloading scripts others have written. This whole "steal from someone who's done it successfully" attitude is what makes AppleScript centric web sites seem to spiral into oblivion. Everyone's simply reposting what they've stolen off of other sites, the owne's get frustrated maintaining something that doesn't stand apart from the crowd, and it becomes out of date without constant updates.

    I'm not ignorant when it comes to programming, but I find Python and Perl to be syntactically more forgiving and easier to grasp than AppleScript. I find Cocoa to be more standard and more consistently constructed. I find shell scripting to be more accessible and a better "glue" to bind different tasks together.

    I must admit that I still do write the occasional AppleScript and if you rely heavily on a program that supports it well then it can be a decent tool. But it's long fallen from favor as my first choice of scripting.
    • The big lie I always hear about Applescript is that: "Applescript doesn't need lots of documentation, it's self-documenting, english-like, and always current"

      Sadly, this is very true. Apple has really fallen down on the job of documenting AppleScript, and it's always been underutilized because of it.

      When AppleScript first came out, everyone could understand the potential of the feature, but few people really knew how to use it. Apple's AppleScript Product Manager, Sal Sagohian (or however it's spelled),
    • The big lie I always hear about Applescript is that: "Applescript doesn't need lots of documentation, it's self-documenting, english-like, and always current"

      IME, AppleScript's documentation is pretty good. The scripting dictionary built into scriptable apps usually explains things clearly enough-- sometimes if I'm having trouble wrapping my mind around how to extract a specific field from a record, I'll just open up a second window and fool around with a little code until I get it figured out.

      Of course
      • The whole idea of AppleScript is to *facilitate* easy interapplication communication, not to turn applications into Roach Motels for your data

        Yes. Agreed. That's why it is a problem for certain vendors.

        Data hostage situations don't happen only under Win/Office...

  • Programming? (Score:3, Insightful)

    by WatertonMan ( 550706 ) on Wednesday August 27, 2003 @01:35PM (#6806999)
    Debugging is hardly mentioned (3/4 of one lesson), and debugging is not exactly trivial in AppleScript. I also found no mention of my pet demon with AppleScript; its incredibly strong typing and problems with having data in the wrong type; this is a classic problem with files and file names. In reality, this book teaches you the language without really getting down to teach you how to program in the language.

    This is a very damning problem. One could argue that the O'Reilly book was primarily a reference book. (A reference book dealing primarily with Sys9 and with only a few bits about 10.0 OSX features) But learning Applescript really ought to deal with how to code Applescript.

    It is sad that there are not really good books on Applescript. While the language itself is pretty poor (IMO) the concept is excellent. Applescript Studio, while flawed, is a great tool. Most significant, with OSX, you can mix scripting languages to do very powerful things. i.e. most of my scripts are combination shell scrips and Applescripts. I also have a lot of Python/Applescripts. With Apple's GUIScripting additions to Applescript it is an amazingly powerful tool.

    The only downside in Apple's toolkit are fairly weak scripting support in some important applications. (cough) Mail (cough). The other downside is debugging, which is surprisingly weak.

    If I had a wish, it would be for something like Applescript studio, but with solid debugging and support for shell scripts, Applescripts, Perl scripts, Python scripts and maybe even TCL/TK. It would really be a killer feature for Unix types.

  • I seeO'Reilly has a book on this topic on the way. [amazon.com] I wonder how it'll stack up. At least we can be reasonably sure that it'll be up to date. O'Reilly usually gets it right. Guess we'll just have to see. I personally looking forward to see how it'll stack up.

  • tell people slashdot crowd check this out end tell (Score:3, Informative)

    by Ukab the Great ( 87152 ) on Wednesday August 27, 2003 @08:38PM (#6809956)
    Here's a cool hack [blankreb.com] that someone did in applescript that illustrates why one would want to learn Applescript.

Slashdot Top Deals

If you steal from one author it's plagiarism; if you steal from many it's research. -- Wilson Mizner

Close