>And how! Let me rant the ways: At least you admit it's a rant. ;-) > >1. In trying to be like a natural language, it's got innumerable > ways of stating every little thing. Which variants are usable at a > given time varies considerably. Which can be annoying. Perhaps as annoying as a full beastiary of special variables, only some of which are useable at any given time. And, what exactly is wrong with "There's more than one way to do it"? > >2. It is a language for talking to applications, yet it encouages > app developers to provide an "object model" above and beyond, > and thus often quite different from, the one that most users > experience through the standard GUI interface. The AS interface > is thus often absent, buggy or incomplete when provided, and > almost never supported. "Almost never supported" is no longer true, nor has it been for about two years. Most serious applications being released for the macintosh have at least *some* applescripting capabilities built in. > >3. Though "driving" the user interface as a normal user would do > would be the easiest and most direct way to handle many scripting > tasks, AS has no mechanism whatsoever for doing this. > There is an (invaluable) third-party product, PreFab Player, that > lets an Applescript programmer navigate as users do, but because > it's an add-on rather thans something built into the OS, it only > works some of the time. I disagree completely with qq{"driving" the user interface as a normal user would do would be the easiest and most direct way to handle many scripting tasks}. It's not. Having to say something like: select document "MyDoc3" do menu item "Print" or worse yet move mouse to coordinates {x:50,y:15} click mouse move mouse to menu "File" click mouse with holddown move mouse to menu item "Print" release mouse instead of print document "MyDoc3" is bad. > >4. <timing and synchronization problems Paul mentioned earlier> > >Apple could have saved itself and everyone else huge amounts of >time, money, and energy, and had a better product besides, had it >started by providing a regular, reliable system for navigating every >MacOS menu, dialog box, and control item. I'd much rather not have UI come up when automating an application. Anything I can specify with a UI I should be able to specify WITHOUT one (and ain't that a Unixish thought!). Encouraging people to implement AS so that the UI gets "driven" would lead to exactly the kind of tortured coding I showed above. Avoiding that kind of programming is exactly what the object model you complain about is trying to do, as well as STANDARDIZE behavior between applications of a similar natures (like virus checking software, or page layout programs (|dream here) ). >If you mean _Danny Goodman's AppleScript Handbook_, I would neither >rate nor recommend it highly. It got me through rough spots that >otherwise would have frustrated me to death, but it's not >particularly orderly or well-organized, especially for experienced >programmers. It couldn't compare, for example, to the >Wall/Christiansen/Schwartz _Programming Perl_ book. > Here, I agree with you. The Goodman book is much overrated. He doesn't cover anything that isn't said in other books (perhaps he said it before most others). The only AppleScript book I've found USEFUL has been the AppleScript Language Guide. The only other AS book I've found that I *might* pay my own money for is Trinko's dummies book. It actually covers some advanced topics that are not specific guides to individual apps. AppleScript is Turing complete; subject to it's own whimsies,foibles, peculiarities, odd notions, and strange ways of doing things; capable of making people angry and happy; and in all other ways just the same as any other programming language out there. Now that we actually have TWO sides to this language war, let's get back to the business of babbling about MacPerl, shall we? -Jeff Lowrey Systems Programmer Sells Printing Company ***** Want to unsubscribe from this list? ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch