Shane Stanley wrote:
> On 12 Dec 2015, at 10:02 AM, has <email@hidden> wrote:
>>
>> TBH, I'd be surprised if there are very many apps in App
Store that provide any sort of Apple event ("AppleScript"
automation) interface, never mind support attachability (the ability
to run scripts).
>
> I agree. But that also means that the main point you raised
about libraries being per component instance is largely moot.
Though that's like saying it doesn't matter we botched the heart
surgery because the patient died of a brain aneurysm first... :/
Sorry, but fifteen years of learning to write my own code
defensively, while watching in horror (and anger) as "Real
Programmers"' systems constantly explode on their unfortunate users
(Hi, TalkTalk!), means I've zero trust or tolerance for any code
that isn't. When writing software that other people will use and
depend on, total paranoia should be mandatory. Unfortunately, as
anyone who's ever read a Software EULA knows, phrases such as
"professional responsibility" and "personal liability" don't exist
in most programmer's vocabulary; and it's all downhill from there.
> I've no idea why libraries were implemented that way, but you
don't seem to countenance the possibility that there were pros as
well as cons.
The only 'pro' would be in ASOC-based apps, as all of an ASOC app's
scripts are related so should arguably share the same library
instances as well, although even that doesn't require the use of
OSAIDs.
The only reason I think they used OSAIDs for library script objects
is because they already used OSAIDs to hold ASOC script objects,
which (IIRC) creates a new OSAID for every ASOC class and instance.
Which is why ASOC explodes as soon as you try to use a large number
of script objects in it (unlike better designed bridges such as
PyObjC). So the counter-argument would be that ASOC is designed
badly and the library loader merely continues the trend.
> Without knowing all the details -- and I suspect that applies
to you as well as me -- it seems a tad churlish to assume the worse.
Since the AS team virtually never talk to their users, informed
guesswork is the best we've got. And I've studied all of their work
and have some inkling of how they think, so my best informed guesses
are 1. because it exists (and programmers can't resist playing with
complicated toys); 2. because they never actually use AppleScript or
talk to those who do, so lack insight into the pros and cons
themselves; and/or 3. because they're less concerned about
delivering genuinely good solutions to users than ticking completion
boxes on corporate paperwork. I'm all for speaking truth to power.
Worst that can happen is I'm wrong (which I often am), in which case
I should get corrected.
But lest we lose sight of the bigger picture, the flaws of AS's
library loader are a mere drop in the stagnant pond compared to the
AS team's (and AS community's) total failure even to try to
bootstrap a functioning library ecosystem. (Bear in mind I even
offered to do the grunt work for them and give it to them gratis,
and didn't even get a response.) I mean, this is extremely
low-hanging fruit - trivial to pick with major benefits to ALL AS
users - and no-one's done a single damn thing about it. Chris Page
in particular, had he not spent weeks (months?) screwing about with
the AS parser's guts (a scary and unnecessary risk), could have
complemented his shiny new loader (which should've been a week's
work max) with a lovely standard library, instantly addressing a
crapload of AS's 20 year-old daily deficiencies and proving to every
single AS user just how awesomely USEFUL his system actually is.
(Alas, totally bass-ackward priorities are a chronic failing in
corporate software development, where programmers spend all their
time creating excitingly complex technical problems just so they can
solve as cleverly as they can for their own entertainment - instead
of taking their time to talk to learn their users' actual everyday
problems and delivering simple, practical solutions that address
those problems quickly, quietly, and efficiently.)
> I mean, once you know about the issue -- and it is spelled out
pretty clearly in the ASLG -- it's hardly crippling.
Actually the ASLG's wording is extremely poor (feel free to file a
ticket on it). It completely fails to state that the biggest risk is
two completely unrelated scripts can interfere with each other in
heinously unexpected and non-obvious ways if both happen to use the
same stateful library. I dunno why they have a problem just coming
out and saying it (it's not as if other languages, e.g. Python and
Ruby, don't have the same problem too), but it's just hopelessly
mealy-mouthed and 99.9% of AppleScripters will not realize that this
is actually a *dangerous* behavior, nor how safely to avoid it (i.e.
don't keep *any* mutable state in reusable libraries).
>>> So perhaps they could just change in the name of, well,
keeping up. (And yes, it has its own issues, but in these days of
potentially loading frameworks via script, I'm surprised any
developers are sticking with running AS any other way for the sake
of their own app's stability.)
>>
>> Yeah, I've been banging on for years about the need to
replace OSA with an out-of-process architecture for loading and
running scripts for precisely the same reason.
>
> Careful -- you're sailing perilously close to approving
something that's been done, even if you don't mean to.
No, the NSUserScriptTask classes are a cheap garbage hack. OSA is
vastly more powerful than that (like OpenDoc for scripting
languages), but hobbled by archaic, poorly understood API (even the
AS team don't understand it how to use it, as they proved with JXA)
and its insistence on running everything in-process (which except
for a few specific use cases is not what you, or modern OS X, want).
If you want to get a rough impression of just how deep and powerful
OSA really is, go spelunk Satimage's Smile.app.
But OSA is from an utterly different and largely forgotten culture
to modern-day Apple: an innocent time of Lisp and Smalltalk
Machines, when software was to be open and customizable by and for
its users' benefit; whereas nowadays it's just a black-box revenue
generator, where users use, programmers dictate, and Apple's
inescapable tollbooths are meticulously positioned on every road.
And so it goes.
>> Anyways, apologies for being soapbox-y
>
> We expect nothing less. I'm still looking for the poison
footnotes...
No worries, [1]
has
[1] TO DO: <insert poison footnote here>
|