Re: technical Applescript question: enthusiasm among the members of the AppleScript engineering team [long]
Re: technical Applescript question: enthusiasm among the members of the AppleScript engineering team [long]
- Subject: Re: technical Applescript question: enthusiasm among the members of the AppleScript engineering team [long]
- From: Charles Srstka <email@hidden>
- Date: Thu, 28 Mar 2002 17:28:33 -0600
I agree that AS Studio is pretty cool. I only wish it had a nice easy
function or method that you could call from Objective-C code to send an
applescript.
Being able to do something like:
[NSScriptStudio sendScript:@"tell application \"Finder\" to activate"];
or
NSSendScript(@"tell application \"Finder\" to activate");
would be really nice, as would something like
[NSScriptStudio runScriptAtPath:[[NSBundle mainBundle]
pathForResource:@"someScript" ofType:@"applescript"]];
as would
[NSScriptStudio runScriptNamed:@"someScript"];
which would do the same as the previous line. Of course, I know I can
just fork/exec osascript, but it seems like it would be more elegant to
do it with an API, and probably faster as well.
On Thursday, March 28, 2002, at 12:04 PM, Bill Cheeseman wrote:
Apologies in advance for this very long answer. Erik tickled one of my
obsessions. If you aren't interested in AppleScript, move on.
on 02-03-28 10:20 AM, Erik M. Buck at email@hidden wrote:
I do recall that at the 2000 WWDC Mr. Jobs said in his key note that
Apple
realized that AppleScript is an important part of the Mac experience
for
professional users and AppleScript would be preserved in OS X. (Was
there
any doubt prior to that ?)
Yes. AppleScript very narrowly "made the cut" at the last minute, back
when
Mr. Jobs was killing technologies left and right in order to save Apple.
Thanks to some very intense and very direct lobbying, I understand that
he
eventually realized that the publishing industry depends heavily on
AppleScript for work flow automation, and that this in turn generates
hardware sales.
This is really good to hear for several reasons. The AppleScript team
seems
like a shining example of adoption by a historically Apple group of a
historically NeXT technology. There have been many negative comments
about
OS X "loosing" beloved features of prior Mac OS versions. There have
been
many complaints about OS X "loosing" beloved features of NeXTstep. Is
AppleScript an example of both camps being satisfied ? Do technical
differences between the level of AppleScript support exist between Mac
OS
versions ?
My impression is that AppleScript is in fact an example of both camps
being
satisfied. I can't say that I know very many old-time Nexties who are
getting into AppleScript, but the AppleScript mailing lists (there are
several, and they are very active) have enthusiastically embraced Mac
OS X
and Cocoa. I am not the only established AppleScripter who has turned to
Cocoa development.
Core AppleScript technology is now, with Mac OS X 10.1, at least on a
par
with its Mac OS 9 counterpart, and in some ways better. Most scripts
written
for one environment run without change in the other, and you can control
applications running in one environment from the other. There are
differences in AppleScript commands, as between the two environments,
in the
ways that you would expect. For example: different keywords for the
"standard" system folders, recognition of the Mac OS X "domains" in
AppleScript for Mac OS X, the addition of AppleScript capabilities for
dealing with Terminal scripting conventions (e.g., quoting), the
addition of
AppleScript capabilities for dealing with Unix path names, recognition
of
different line endings (line feed as well as carriage return).
Integration of AppleScript into Mac OS X is proceeding in what I think
of as
four phases. We're well over half way along in the process.
First was under-the-hood operating system support, and it was pretty
much in
place in Mac OS X 10.0. This included the AppleScript "component" which
provides what you might call the AppleScript runtime, the Standard
Additions
scripting addition which provides some important AppleScript commands
that
aren't part of the core language implemented in the component, and the
Script Editor (which was in fact the first Apple-supplied application
to be
Carbonized). Because of this, existing scriptable applications that were
ported from Mac OS 9 to Mac OS X in the early days had full, working,
system-level AppleScript support in Mac OS X 10.0.
Second was Finder AppleScript support, which is very important because
AppleScript can do very sophisticated file system manipulations and
maintenance using the Finder. The Mac OS X 10.0 Finder had very limited
and
buggy AppleScript support. In Mac OS X 10.1, it is almost all there and
almost all working correctly.
Third was (is) adding back AppleScript support to a large number of
system
utilities and Apple-supplied applications that are scriptable in Mac
OS 9
but aren't yet scriptable in Mac OS X. This is ongoing, and big advances
have been made. (For example, QuickTime Player, System Profiler, speech
recognition, etc.)
Fourth is AppleScript Studio. With the imminent release of AS Studio 1.1
final, this is starting to look like a tool that Apple will use to push
AppleScript very hard in months to come. Apple's AppleScript and other
sites
have just begun, in the last week or two, to include small AppleScript
Studio applications to control important system functions and "digital
hub"
applications.
Finally, to get back to a technical issue in this technical forum: How
is
AppleScript Studio being used and what technical advantages and
disadvantages apply to AppleScript on OS X vs. OS 9. How does
AppleScript
compare to Objective-TCL for in-application scripting ? I am primarily
interested in any limitations on the access to application objects
imposed
by AppleScript.
I addressed the OSX vs. OS 9 question above, and to some extent what is
being done with AS Studio. AS Studio is only just starting to gallop
out of
the starting gate, so it's hard to predict where it will go.
I'm not really qualified to talk about comparisons between AppleScript
and
other scripting or control languages for in-application scripting,
because
I've focused on AppleScript. AppleScripters with more experience of
other
scripting languages usually say, pick your language to match your
project.
For example, it is generally recognized that PERL outshines AppleScript
for
string manipulation by miles; although AppleScript certainly lets you
handle
strings in all the ways you would want, it isn't fast and it isn't
elegant.
Also, AppleScript (before AS Studio) has only very limited built-in user
interface widgets, so maybe Tcl/Tk are better in that area; I wouldn't
know.
AppleScript does support object-oriented scripting; you can create
objects
that encapsulate data and commands, and that support inheritance and
conditional overriding of commands. But I have no idea how these
compare in
sophistication with other object-oriented scripting languages. Multiple
inheritance is not supported.
In general, AppleScript is too slow for efficient in-application
scripting
in any context where massive amounts of data must be massaged. This is a
result of the fact that it is implemented in ways that make it excel at
interapplication scripting. There, the overhead doesn't matter because
you
have no alternative. This in turn means that you can do your massive
data
manipulation in an application written for that purpose. In my legal
career,
for example, I started using AppleScript long ago to move data from an
Excel
spreadsheet to a specialized application that did sophisticated risk
analysis, then back to Excel for organization and display. One of my
projects took over an hour to run on an old SE/30 (this was a truly huge
spreadsheet), but it saved literally days of work required if done using
other techniques. (It was down to about 30 seconds on a PowerMac G3
minitower.) In the case of applications that have a proprietary
in-appliation scripting language, I always advise scripters to write the
in-application part of a script in the application's native scripting
language because it is always faster, then call that script from
AppleScript
to do the interapplication communication.
The core advantage of AppleScript is interapplication communication.
Many,
many applications come with scripting dictionaries that let you control
their features from AppleScript. (Or from any other Open Scripting
Architecture scripting language, such as Userland's UserTalk, an
outline-based scripting language built into Frontier; JavaScript,
thanks to
a third-party utility; and, of all things, QuicKeys Script; and there
are
projects to make other recognized scripting languages OSA-compatible,
such
as PERL, Tcl/Tk, Python and others.) When you need to put together an
automated, multi-application work flow project, AppleScript is the tool
of
choice. It is awesome to watch some of the scripts used in the prepress
industry in action, flowing text and graphics automatically from one
application to the next, and the next, and the next, untouched by human
hands. That's how the TV guide is put together every week at the Los
Angeles
Times, for example, and USA Today's daily weather maps, as I understand
it.
AS Studio will be going after these markets. (And that means Cocoa has a
foot in the door, too, right?)
Another AppleScript design goal is the ability to write scripts in
"plain
English" terminology, in order to make the language accessible to the
masses. In this, AppleScript is historically sort of an offshoot of
HyperTalk, the HyperCard scripting language. It carries the notion
farther,
though, for example, by allowing many synonyms for basic commands. You
can
also optionally use articles like "the" and "a." I did a last-minute
edit of
the recent AppleScript book, "AppleScript in a Nutshell," for O'Reilly,
and
I had to correct one passage where the author described what an example
script was supposed to do in what he called "pseudocode," or a plain
English
summary description; but his pseudocode was in fact executable
AppleScript
code that could be run in Script Editor as is, without change, and he
hadn't
realized it. Personally, despite striking examples like that, I have
always
thought the "plain English" notion is silly, but that's probably
because I
have many years of programming experience in many languages, and it all
has
come to seem like "plain English" to me. HyperCard certainly attracted a
large mass of non-programmers because of its accessiblity, and so has
AppleScript, although some people claim that the "plain English" feature
actually makes scripts harder to understand. The "plain English"
ambition
also makes AppleScript somewhat verbose -- but that's an issue that
won't
bother Cocoa programmers!
An interesting aspect of AppleScript is that the language is inherently
extensible. Since any application can implement any commands it likes,
and
since any one script can be written to control multiple applications,
you
can end up with an enormous hodge-podge of terminology to work with.
Although there are standards of a sort, in the form of official
AppleScript
"suites" that applications can implement, developers inevitably go off
on
their own tangents. There are therefore odd inconsistencies in the way
common terms are used from one application to another. This is something
AppleScripters just get used to, although it does compel a fair amount
of
"trial and error" scripting to make things work. Also, third-party
scripting
additions (of which there are hundreds in Mac OS 9 but as yet only a
handful
in Mac OS X) can add commands to the language globally. This is very
powerful, and it is a way to bring very efficient code to AppleScript
for
complex calculations, but it does lead to rampant global namespace
conflicts
-- again, an issue that won't bother Cocoa programmers!
The most interesting aspect of AS Studio is that it's really just Cocoa
with
some scripting classes grafted on. The theme of my review of AppleScript
Studio in the January issue of MacTech Magazine is that any AS Studio
application can intermix AppleScript and Cocoa to any degree desired,
from
almost all AppleScript to almost all Cocoa. One way of looking at this
is
that AS Studio allows you to add two powerful features to any Cocoa
application (if you have access to its code): (1) Scripted control over
its
Cocoa interface objects that are supported by AS Studio. Just about
every
Cocoa view object has an AS Studio counterpart that amounts to a thin
AppleScript wrapper on the Cocoa object. Not to mention scripted control
over the Cocoa data objects that are accessible through Cocoa's
traditional
AppleScript support as well as AS Studio additions (AS Studio's
AppleScript
strings are NSString objects, for example, and AS Studio's AppleScript
lists
are NSArray objects). AS Studio includes a "Call Method" AppleScript
command
that basically lets you write Cocoa code to perform calculations and
manipulations and then call it from AppleScript. Almost all of the
AppKit
and Foundation are available to AppleScript in this fashion. In fact,
the
lead AS Studio engineer has been posting small examples on his iDisk
using
Call Method to work around gaps in AS Studio 1.0's implementation; for
example, to give AS Studio users access to NSUserDefaults via
AppleScript in
order to create application preferences. (2) Control of other
applications
via in-application AppleScript commands. You implement the latter via
Carbon
calls at this point, with no real Cocoa API. The former will allow you
to
demonstrate and quality assure your applications by writing scripts to
put
it through its paces automatically, as well as giving scripters the
ability
to integrate your application into their automated work flows.
You can probably tell that I find AS Studio pretty exciting.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont - http://members.valley.net/croquetvermont
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.