Re: what's in a standard library?
Re: what's in a standard library?
- Subject: Re: what's in a standard library?
- From: has <email@hidden>
- Date: Tue, 29 Nov 2016 20:02:22 +0000
Stockly, Ed wrote:
My thinking is that if something is to be distributed by Apple as an appleScript, then it should be written as an easily read and editable appleScript or should be locked. That's how Shane distributes his libraries, and others I've seen. (Of course the source scripts could be made available too.)
Ah, I see where you're at now. I would expect Apple to put standard
libraries into /System, codesigned, and [presumably] saved in run-only
format for security. So I think you're pretty safe there.
My thinking is also that if apple were to distribute a "Standard Library" it would be a collection of well-written AppleScripts that are easily understood and edited and serve as an example for novice to experienced appleScripters of good AppleScripting, and how to build their own libraries.
You're mixing Learning with Using. Teaching ASers how to write their own
libraries is a separate problem. AS users don't need to learn how to
write an osax in order to use an osax; they just read its dictionary and
use it; job done. Libraries which are good for learning from are
not-good for production use, and vice-versa. Different problems have
different requirements; there isn't a one-size-fits-all answer.
The purpose of standard libraries is to let users perform common generic
tasks quickly and easily, without having to know or care precisely how
they work. As widely-used production code, they also need to be robust,
capable, and fast; requirements that ADD complexity. Sure a "standard
library" _could_ use a simple 6-line bubblesort handler instead of the
complex `sort list` handler I wrote, but it won't provide helpful error
messages when something goes wrong; it won't provide users with an
option to perform more complex sorting, e.g. numeric ordering, list of
records; and it'll be unusably slow on all but very small or nearly
ordered lists. (You want a "how to write your own libraries" guide for
learners, go buy all remaining copies of Apress's Learn AppleScript 3rd
edition so that they have to do a 4th one.:)
The libraries I've offered are professionally-developed,
production-quality code. It took me the better part of a decade to learn
how to write code to that standard, but AppleScript users should not
have to to spend years teaching themselves before being allowed to do
simple everyday tasks like replacing text and sorting lists quickly and
reliably. If that was what they cared about doing they'd have gone been
professional programmers instead! Writing standard libraries is 100%
pure scut work. The only reasons I did it are 1. cos I already have the
skills so it was far quicker and easier for me to do than anyone else,
and 2. so no other AppleScript would ever have to do such unproductive
scut work again. (Also 3. it's good practice for me as my next language
will need one too.)
I certainly don't see Apple distributing Has' libraries as a standard library. Aside from the fact that he has repeatedly and gratuitously insulted the intelligence of everyone at Apple would who's green light would be needed, right or wrong this collection is not appropriate as a standard.
"Gratuitously insulted the intelligence"? I've said often enough that
the Chrises may be competent maintenance coders but their design skills
suck. And I've said often enough too that Sal is a lovely bloke and
great end-user evangelist, but he was a poor product manager, because a
product manager's #1 job is to build new markets and win new customers,
and thus make his employer richer, not to spend his employer's money
building broken products nobody uses.
Look, all the evidence to back up my assertions already exists:
Scripting Bridge and JavaScript for Automation are riddled with defects
and don't work correctly with a wide range of commands and apps, and
both have failed to win new Automation users, even though Objective-C,
Python, Ruby, JavaScript, etc are hundreds of times more popular than
AppleScript. Anyone who disagrees with my assessment is welcome to
change my mind by providing the *evidence* I'm wrong. Vague handwavy
accusations will not.
Much of the commands in the libraries duplicate what's already in Scripting Additions; system events; the Finder; etc. (Maybe slightly better, maybe slightly differently, maybe the differences aren't significant)
Nonsense. There's no overlap with SE/Finder; I considered doing such a
library having seen Shane's own, but decided not to for exactly the
reason you describe. The File library has `read file`/`write file`
commands, which provide capabilities missing from Standard Additions
`read`/`write`, and are much simpler and less error-prone to use too.
There's a `round number` command in Math that provides capabilities
missing from Standard Additions' `round`. That's pretty much it. Any
other commands I've forgotten about, please write their names down.
Some of them seem geared toward a specific purposes and not really appropriate for general use (nothing wrong with that, but probably not appropriate for a standard library).
Please define 'specific purposes' and state which commands. Ignore the
TestTools and TypeSupport libraries; they're in there to support the 7
user libraries. I'm all for getting rid of bloat: Shane pointed out one
or two not very good commands in an earlier version; I agreed and took
them out. The Stack and Queue objects in the Objects library are kinda
borderline, but I felt the other two (Dictionary and Timer) would feel
lonely if I put in any less. I already took out the Set object as NSSet
works well enough for that. Basic web access is such a common job it'd
be remiss not to support that; ASers shouldn't have to wade through `do
shell script` and `curl` documentation just to upload and download.
The one "specific purpose" concession is the "Shell Script Support"
suite, which is only of interest to those users who write
#!/usr/bin/osascript scripts. OTOH, if it wasn't included, those users
couldn't easily distribute those scripts, because you can't bundle
libraries within .applescript files, only .scptd ones. Apple are the
ones who decided to make writing AS shell scripts possible; these
libraries make them easy to write as well. All the other
Terminal-friendly languages have them; why shouldn't AppleScript too?
Unless you think shell scripters aren't worthy to use AS?
If you like these libraries and find them useful, then by all means use them.
I might do the same (along with other libraries). Although I have workarounds that I've written myself over the years for a lot of these, once I get comfortable with a reliable way to install libraries on whatever client machines may be running them, I may use some of them.
A standard, easy-to-use system for distributing standalone libraries is
one of those problems that's 8th or 9th on the list, sometime after
"Save AppleScript from Deprecation" and "Add a Standard Library" first.
For now, it's simplest just to distribute your own work in .app and/or
.scptd format, and bundle any required libraries into those each time.
(There's also a feature in macOS 10.11+ that allows you to put AS
libraries into a 'dummy' .app, and once that app's installed onto a Mac
all AppleScripts on that Mac can import them, just as if they were in
one of the standard `Library` locations. Needless to say this design
still gives me the screaming horrors: I Radared a ticket that got the
most serious security hole plugged ASAP, but it's still a mess of
security holes and accidents waiting to happen. But at this point not
really my problem.)
Honestly, Ed, I think you're letting your discomfort at code you can see
but don't understand, plus personal animosity blind you. You're not
fazed by all the code you can't see either: AS, StandardAdditions, ASOC,
InDesign, and everyone else. And who cares who wrote what; only thing
that matters is who gets to benefit by using it for free instead of
being made to write their own. It's solid product; I wouldn't offer this
community anything I wouldn't use myself in my own professional work.
Look, nobody else inside or outside Apple is going to write an AS
standard library, or else they'd have *already* done it cos they've had
*three years* now. Who else is going to do the job, and do it to a
standard users can trust their own workflows on? Suck it up; I don't
care if you never use them yourself, but do it to help your fellow
AppleScript users who will. And do it to help AppleScript, because
persuading Apple to add a significant NEW AppleScript feature in 10.13
would be a VERY positive sign that this new Siri team cares about
AppleScript users too.
-------
One More Thing…
If you think *I'm* insulting to Apple, here's our beloved Mr Welch in
cracking form:
https://medium.com/@johncwelch/apple-and-sal-119b20c19b5
Now I love John: smart, incisive, funny, never suffers fools; but this
is not the time to rage blindly at Apple for a decision that should've
been taken years ago. In successful business, it's the Product, not the
people, that must come first. I may be harsh in criticising others, but
I'm twice as harsh criticising myself. All the mistakes Sal has made I
made first, so I'm talking from a position of painful personal
experience here: my mistakes KILLED ALL MY PRODUCTS and BURNED ALL MY
USERS, which is not something I want to see repeated here. Don't
underestimate just what a weak and vulnerable position AppleScript is in
right now, just because it's incredibly important to you. You have to
look at it from Apple's perspective and what it does (or doesn't do) for
them.
At least I'm putting my money where my mouth is, which on this occasion
is $1000s of unpaid work developing, documenting, and testing seven
general-purpose libraries as a gift to the Apple community, and a way
for Apple to keep those customers' trust. And all I'm asking is for
everyone here to send a POSITIVE MESSAGE to Apple saying "We, the users,
still care about your Automation product, and here's some quick, easy,
[nearly] zero-cost requests on how you, Apple, can instantly make it
loads better too." Apple's response will tell us a lot. Others are
filing tickets and reporting them successfully closed as duplicates;
what does it cost you to do it as well? Ten minutes at most.
Yeah, it's a Hail Mary. So what? It's still better than DOING NOTHING
(not the Automation way at all!), while NEGATIVE REACTIONS—like swearing
at Apple for firing Sal or pleading not to kill Automation off—will
definitely not help, cos Apple's ALREADY DONE the math on what these
moves will cost THEM, and the answer's not even a rounding error on
their iOS budget. The ONLY thing we can do as a user community is offer
Apple even BETTER REASONS not merely to keep it but to build on it too,
i.e. positive improvements that bring it new users.
Seeing both an AppleScript standard library and Swift Automation support
in 10.13—improving AppleScript's value and winning Apple's Automation
technology its first NEW MARKET IN A DECADE—is what I would call a
promising start.
Regards,
has
--
p.s. I'd love to write a beginner's guide to creating AppleScript
libraries of your own, but I can't because there's no market for a 4th
edition of Learn AppleScript. So if you want one, please go get Apress a
market for that.
_______________________________________________
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