Re: What makes AppleScript COOL!
Re: What makes AppleScript COOL!
- Subject: Re: What makes AppleScript COOL!
- From: Phil <email@hidden>
- Date: Fri, 7 Dec 2007 23:58:13 -0500
On Dec 7, 2007, at 10:46 PM, Stockly, Ed wrote:
1) Script recording. This would help both Apple and scripters:
Apple
wouldn't be blamed for every developer's (sometimes poor) choices
in how they
expose their app, and scripters would have a much easier time
dealing with
these implementation decisions since it wouldn't take so much trial
and error
to figure out how to get something done.
I used recording a lot in OS 9 if I was struggling to figure out how
to
issue a particular command.
It's nearly gone in OSX and I don't miss it.
What I do miss is Scripter's Command Builder, which would allow you
to build
working commands by pointing and clicking at command components
pulled from
the application's dictionary.
It also provided a better way of looking at dictionaries.
I wasn't familiar with SCB but that sounds like that approach would
also address the problem which is essentially this: figuring out how
to tell AppleScript what you want it to do. (I actually spend less
time telling other scripting languages *how* to do things, which are
usually low-level enough that you can't simply tell them what to do,
than I spend telling AppleScript *what* I want it to do. Seems
counterintuitive.)
2) Debugging. Why is it still necessary to buy a (relatively)
expensive 3rd party application in order to debug Applescript code?
Get over it. Script Debugger is relatively cheap. I script Quark,
InDesign,
PhotoShop, just to name a few, on scripts that are run on hundreds
of macs.
To keep them all going all I really need is a single copy of Script
Debugger
(Although I think we bought 4 copies). Compared to the money we
spend on all
our installations with those apps, the cost of SD is a drop in the
bucket.
If you're serious about AppleScripting you should use the best tools
available to write and debug your scripts. (Deployment is a different
matter, see below).
I don't disagree that Script Debugger is a necessity, and a great
tool, if one uses AppleScript to any serious degree. However, for
casual/home scripters, paying more for a script debugging tool than
they paid for the OS plus iLife isn't realistic. Also, compare and
contrast the default AppleScript tools with what you get for Obj-C/
Cocoa development. Imagine that Apple only provided an 'Objective-C
Editor' with the relative capability of Script Editor, didn't have
Cocoa, provided 8 year old documentation for the language, and
required 3rd party tools and add-ins to get anything meaningful
done.... who would be doing any serious development in/with/for
Objective-C? (memo to Steve Jobs: Apple has 15 billion in the bank.
Spend a few million to buy or build something like ScriptDebugger and
integrate it with OS X! ;-)
3) Provide example scripts and real language/dictionary
documentation
for the code that *is* controlled by Apple Guide from 1999!?)
Agreed.
Just one other point about third party software vs. Apple software.
Without naming names, suppose all my scripts depended on a third
party osax
or FBA for basic every day operation. Text handling, for example, or
parsing
XML data, or copying and deleting files. I can imagine myself
explaining to
my boss or some other department head that the reason the script
won't work
on these new macs is that some software I downloaded for free from the
internet isn't compatible with his new processor or the new system
and won't
be until the guy who writes it and releases it has bought an Intel
mac and
upgraded to the latest system and has the time to work on it.
There's plenty third party developers do that's good and useful,and
I buy
their products and my company buys them too, but there are some eggs
I'd
rather keep in my own basket or Apple's.
ES
That's really the point of the items I listed: universally useful
things should be provided by Apple out of the box. After all, the
odds of some new 3rd party attempting to enter the OS X workflow
automation space is highly unlikely and a brittle, incomplete toolset
only hurts Apple's customers, and in turn, Apple.
I'm a little frustrated right now as I've spent the last several hours
working on getting a piddly little AppleScript to automate a workflow
between Safari and OmniOutliner. It's mostly working now but in
addition to taking several hours to automate 30 seconds worth of work,
I had to open a ticket with Omni (you guys rock: question answered
nearly immediately), had to use Script Debugger, have to reinstall
QuickSilver so I can assign a keyboard shortcut to it (Quicksilver
isn't at all bad but only needing it to assign a keyboard shortcut to
an AppleScript really bites), and still have a rather mysterious issue
with AppleScript (see my post re: AppleScript and Spaces) I keep
telling myself that this exercise was worth it since I perform this
workflow repeatedly but I don't dare do the math on the time
investment... I'd probably have to do keep doing it for the next 50
years to break even. (I'm not naive enough to think that this time
investment will pay off in future AppleScript development...
AppleScript is the only language I've ever used where your previous
efforts / knowledge gained don't count the next time you try to do
something different.) I am an Obj-C/Cocoa developer, among other
tools and languages, and continue to be amazed at how painful
AppleScripting is... I pity the non-technical user.
Thanks,
Phil
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden