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: Bill Cheeseman <email@hidden>
- Date: Thu, 28 Mar 2002 13:04:45 -0500
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.