• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: what's in a standard library?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: what's in a standard library?
      • From: "Stockly, Ed" <email@hidden>
  • Prev by Date: Re: Is Keypressed dead forever?
  • Next by Date: Re: Is Keypressed dead forever?
  • Previous by thread: Re: Is Keypressed dead forever?
  • Next by thread: Re: what's in a standard library?
  • Index(es):
    • Date
    • Thread