Marion Dickten wrote:
> Stefan wrote:
>
>> All this is to say, Apple should be aware that such use
>> automation/efficiency cases can be an extremely potent
selling point...
>>
> It's even more than that.
> In those countries where salaries aren't as low as in the US,
AS may be the way to go if the firm is to SURVIVE.
Again, you're all preaching to the audience here, and while it may
us give the warm fuzzies, it won't make automation any more relevant
to Apple's future plans. "Potent" to you is "not even a rounding
error" to Mr Cook et al. Apple is a *consumer* products company now.
Look to Siri, look to Extensions. Look to OSX-iOS
cross-compatibility. Look to content sales. Look to the nebulously
ubiquitous "iCloud". That's where *any* Apple automation technology
needs to make itself relevant.
> BTW, has anyone realised AS is the *one* thing left that is a
really fundamental functional advantage of Macs over Win PCs (curse
them)?
Debatable. Windows has significant integration support; it's just
not pitched at non-programmers. For professional and enterprise, MS
provides an infinitely better end-to-end technology stack,
ecosystem, and support. Which, I realize, still isn't saying all
that much, but let's not keep pretending that Apple or AppleScript
has any real relevance to corporate markets, other than PHBs with
their shiny new iPhones finding fresh ways to make IT's lives a
misery.
> And how would it be if, instead of trying to get _javascript_ to
replace AS, someone wrote a bridge to enable AS to tap directly into
V8?
I assume you meant _javascript_Core. (V8 is Google's JS interpreter.
JSCore is Apple's.) And it would be profoundly pointless to bridge
the AS interpreter to the JS interpreter, since the latter would add
no useful functionality to the former while the bridging itself
would add significant complexity and confusion to an already
horridly complex and confusing language. If you want extra
functionality in your AppleScript and are willing to invest the
extra learning and work [1], use the AppleScript-ObjC bridge; that's
what it's there for.
> Other than the functionality of V8, I really don't know what is
the big deal about replacing one syntax with another. Both syntaxes
need getting used to, both can be learnt quickly.
You completely miss the point. What JXA is _supposed_ to bring the
the Mac automation ecosystem is USERS. _javascript_ is a well
established, well supported language that, while it has many faults
of its own, has nevertheless managed to achieve a level of mass
adoption that poor old AppleScript can only fantasize about. the
language to get started, all they need is .
To argue that the benefit of Apple event-based automation is
integration and then to say other languages shouldn't integrate
Apple event support is absolutely daft. Tens of thousands of current
Mac users *already know* _javascript_; they don't need to learn it in
order to write code. Give them a high-quality
_javascript_-to-AppleEvent bridge and the education to use it, and
they can automate their apps using a language and tools they are
already familiar and comfortable with. Telling them that they must
switch to AppleScript before they can automate their apps is like
telling them they can join the Super Special Elite Treehouse Club
only after they saw their legs off.
> After all, it is the APIs that constitute the real value of a
language.
By APIs, in this case you mean "AppleScriptable" (i.e. Apple
event-aware) applications. Which are not actually
AppleScript-specific, and never have been. Heck, AppleScript wasn't
even the first language to support Apple events: Userland's Frontier
beat them to it. Even back in pre-OS X days Python and Perl had
their own Apple event bridges (aetools+gensuitemodule and Mac::Glue
respectively), while Late Night Software introduced their
_javascript_OSA language component as a full alternative to
AppleScript. The *only* reason Mac application scripting has ended
up coupled to AppleScript is because the Apple event bridges in
other languages have almost always sucked both in implementation and
in user education and support. Only Frontier and appscript ever
worked more or less right, and those ultimately failed for other
reasons [2].
BTW, _javascript_ for Automation isn't Apple's first attempt to make
Mac automation accessible (and palatable) to users of other
languages either. Tiger included Perl's Mac::Glue bridge, though in
addition to Mac::Glue's technical problems its user community was
miniscule and moribund so it never made a dent. Later, during
Leopard development, Apple had a three-way race going between the
RubyOSA (Ruby), appscript (Python+Ruby), and Scripting Bridge
(Objective-C) Apple event bridges to see which would be bundled in
the OS. In the end, it was decreed that there should be only a
single "one-size-fits-all" solution; thus Scripting Bridge made it
in and the other two did not. Unfortunately, Scripting Bridge was
written by Apple engineers with little clue or interest in how
application scripting actually works in the real world [3], so was
crap for anything non-trivial and has never caught on.
JXA is merely their newest attempt to address this ridiculous
deficiency in their own OS. And, I suspect, most likely their last,
since JXA's Apple event and OSA component support is garbage too. In
fact, until WWDC14's surprise announcement, it looked as if
_javascript_ was on its way to replacing the traditional
AppleScript/Apple event/OSA system in favor of app developers
embedding JSCore directly into their apps and letting it talk
directly to ObjC APIs via the _javascript_-to-ObjectiveC bridge
announced at WWDC13.
It's such a crying shame: Apple have this fantastically empowering
technology (Apple event-based automation), yet twenty years on and
they're still making an absolute cack of it.
Regards,
has
--
[1] If not, unfortunately you're just as SOOL now as in the last 20
years. Maverick's library system was supposed finally to address the
problem of effective code sharing and reuse, but as usual the AS
team forgot that implementing a library loader is only 10% of the
work: the other 90% is in educating and building community, support
tools, and an online repository for efficient distribution. Which
they've done absolutely nothing to address; heck, they've not even
bothered to provide even a minimal standard library for essential
everyday operations like text-find-and-replace and list-sort.
[2] Frontier ceased to be a significant alternative to AppleScript
once Userland refocused it as a cross-platform web development
platform instead. Appscript died out because numbnuts here fell
asleep on the job, failed to get it into Leopard after Apple
provided a rare welcome mat, and stymied after 10.6 once the Carbon
APIs it depended on started to go away.
[3] Namely Chris Nebel, chief engineer on the current AppleScript
team, and Bill Bumgarner
. I think Matt N. summarized it best:
<http://lists.apple.com/archives/applescript-implementors/2007/Nov/msg00040.html>
|