Friday, May 22, 2015

LaunchBar Action Editor and AppleScript List Syntax

LaunchBar 6.4 introduces a new action editor:

  • Easily create new actions from scratch or duplicate existing actions for customization.
  • Configure action properties, runtime behavior, and more. Values are pre-filled where possible.
  • Configure and modify action scripts with various scripting languages.
    • Script templates provided for AppleScript, JavaScript, Python, Ruby, Shell script and Swift.
    • Easily add or remove Suggestions Scripts and Action URL scripts.
    • Configure script properties.
    • Open scripts in default editor for editing.
  • Manage action resources
    • Add, rename or delete resources.
    • Set image as action icon.
  • Manage localization
    • Add or remove localizations.
    • Manage localizable strings.

There is actually quite extensive support and documentation for custom actions now, with more emphasis on sharing actions (and therefore code signing to make that secure). It’s also instructive to look at the built-in actions to see how they work.

I learned, for example, that at some point AppleScript added support for using square brackets for list literals. I do not see this documented anywhere, so I’m not sure how far back scripts with this syntax will work. But it’s nice when you have a mix of lists and records to be able to write:

[{k1:"v1", k2:[1, 2, 3]}, {k1:"v2", k2:[4, 5, 6]}]

instead of using curly brackets for everything:

{{k1:"v1", k2:{1, 2, 3}}, {k1:"v2", k2:{4, 5, 6}}}

Note that you cannot use square brackets and colons for record literals. Except in Swift, where you have to use square brackets for everything.

10 Comments RSS · Twitter

FWIW, the lists-with-square-brackets works on 10.5 (I don't have anything older than that handy to test), though (at least there) AppleScript will convert any square brackets to braces when you ask it to give you back the list or any part thereof.

Offhand, 10.5 seems about right for when this probably appeared, because that's also when we got other "other-language-compatible" syntax features (shell-style comments being the one I think of first).

@Smokey Thanks for checking!

Square brackets are the original list notation from AppleScript 1.0, back from when its list type used a linked list implementation.

Linked lists (as any fule kno) have dreadful O(n) performance characteristics when accessing arbitrary items (the most common use case), so vector array-based lists were introduced in a subsequent update (1.1?). However, rather than just replace the original linked list implementation, they kept it and added the new vector array implementation alongside, using curly braces to distinguish these new vector lists from the square bracketed linked lists. No idea why they did this, especially as linked lists have long since been de-documented and (I think) deprecated, but the stupid things are still in there along with all the other accummulated rot and damage of the last twenty-odd years.

Oh, and for bonus irony: AppleScript's vector arrays use a truly brain-damaged implementation that manages to turn what should be O(1) (constant-time) lookups into O(n) (linear-time) lookups, so that they perform no better than linked lists unless you invoke certain arcane and nasty (and potentially crashy) kludges to sneak around the performance-killing algorithm.

(And folks who claim that AppleScript is "non-programmer friendly" wonder why I now laugh bitterly at them...)

@has Thanks for that history. Seems to me that it would still be worth using the square brackets for readability; the linear performance shouldn’t matter for literal-sized lists. And, as you note, the vectors are slow, anyway. Also, my understanding is that AppleScript’s records are also slow because they are implemented as (flattened) lists of pairs rather than as hash tables.

"And folks who claim that AppleScript is "non-programmer friendly" wonder why I now laugh bitterly at them"

FWIW, I can accomplish wonderfully complex things in AppleScript, but despite some efforts, I can't program in anything beyond BASIC. In high school, I was a wizard in BASIC, but when they threw easy 'real' programming languages at me, I was extinct. Most programmers just don't understand scripters.

AppleScript is quite obviously not nearly the best possible scripting language, but it is most definitely "non-programmer friendly" in the sense that a scripter like me can find samples, easily understand them just by reading them, modify them, and expand exponentially from there into writing from scratch...

(Also, FWIW, all the cruft of the last twenty-odd years still working is damn nice from my POV. Old stuff doesn't break. Old learning is still useful. It's sooooo non-Apple in a very good way.)

@Chucky: "Not quite as obnoxiously hostile as popular programmer languages" is not the same thing as "non-programmer friendly". The gap between AppleScript and C++ is far less than the gap between AppleScript and Logo, for example.

The truth is, AppleScript is a huge bait-n-switch: it looks friendly and approachable compared to other languages, but that's all just smoke and mirrors: once you actually get into using it, it is as complicated, convoluted, and intolerant as any other "programmer language". Worse, by disguising all that complexity beneath an ambiguous, obfuscatory syntax, it makes it far harder to understand what is actually going on.

Yes, the "English-like" syntax means anyone can look at an AppleScript script and get a good general idea of what that script does, and that's a laudable goal. Unfortunately, the way AppleScript does this conversely makes it nigh impossible to see exactly how it does it. And since understanding the "how" is essential to being able to write your own scripts, it makes AppleScript far, far harder to use than a genuine end-user language should ever be.

AppleScript's harder even to use than "real programmer" languages like Python and Ruby. At least with those, once you get over the initial hump of being able to read their more cryptic, technical syntax, being able to write it is not much harder because at least they're truthful: what you see is what you get. With AppleScript, you have no idea what you're looking at, because the meanings of words is determined almost by magic; and worse, those meanings can completely change from line to line even within the same script.

This is the whole problem. AppleScript is not a simple language; it's a complicated language that lies to you in a well intentioned by deeply misguided attempt to pretendthat it's simple. And as my old mum always learned me: your lies will always catch you out.

If you want a simple language, the correct way to do it is by stripping out all the needless complexity until all that's left is the bare minimum of features and behaviors actually required to do the job. Instead of creating complex grammar rules and omitting all the punctuation needed to read that grammar effectively, create really simple grammar rules instead.

(This might seem utterly obvious to you and me, but programmers are complexity junkies whom when faced with a simple problem, will create a complex solution just to show off what amazing complexity wranglers they are. Eliminating complexity or even avoiding it completely is all but anathema in a culture where endlessly one-upping your peers is infinitely more important than solving your users' - Who they? - actual problems.)

For instance, in the Logo language you only have two basic structures: words and lists. There's also a couple of word-modifier symbols (for quoting and naming), and parentheses for grouping words together. Plus, of course, the special to WORD...end structure that allows you to invent your own words as you go. It's an entire grammar that can be explained in a dozen pages and learned in an hour: simple, regular, predictable, and the code it produces is quite readable too - almost a pidgin English.

(And lest any Real Programmer scoff at Logo as a "toy language", Logo is a hybrid of Lisp and Forth, two of the most minimalist yet also most powerful, expressive, and endlessly extensible programming languages ever created.)

Compare with AppleScript, whose grammar requires several hundred pages to explain, and even then is fudging some details and doesn't even cover all the potential exceptions-to-the-rule that arbitrary keyword injection by applications, osaxen, and now script libraries can introduce. (And let's not even mention the borderline nervous breakdown that writing those hundreds of pages caused me.:p)

I'm not just talking from opinion here, mind: I cut my scripting teeth on AppleScript starting fifteen years ago, learned it three times over till I finally understood it right (and I can count on my fingers the number of folk in the world who genuinely understand how AppleScript works), and still have thumbs to spare. I also eventually took the plunge into some of those "scary programmer languages", and discovered much to my surprise that once you got over the initial hump they were relatively smooth learning thereafter (whereas with AppleScript it's the initial entry that's smooth and humps everafter). I've also attempted three AppleScript books, only one of which made it (by the skin of its teeth), so I know how hideously hard it is to explain as well as understand. And I now design, document, and train my own end-user languages, drawing on all that I've learned through practice and reading.

So I'm still going to snerk at you, albeit with deepest sympathy, because I know what's achievable in AppleScript, and I know how much more could be achieved if it wasn't an utter bag of poop.

Oh, and I know exactly what you mean about education in "real programming" totally destroying your ability to understand and control your own damn machines. It's not because Programming Is Really Difficult (because it isn't inherently so) but because generations of Programmers Have Made It Really Difficult.

And the worst thing is that they've done this for no reason other than they like it this way. Because if human languages are tools for self-expression and communication, then the sum-total expressed by today's mainstream programmers is Ug Bang Rock! - and just imagine how much trouble they'll be in for should the rest of us ever realize this!

(With apologies for length, natch.;)

"The gap between AppleScript and C++ is far less than the gap between AppleScript and Logo, for example."

No doubt. But they tried Logo on me! And no go.

Like I say, most programmers just don't understand scripters. I was a 99th percentiler with algebra, but when they threw trig and calculus at me, no go. To understand a scripter's mindset, you need to be able to go there. I'm a humanities guy with excellent command of basic logic.

"So I'm still going to snerk at you, albeit with deepest sympathy, because I know what's achievable in AppleScript, and I know how much more could be achieved if it wasn't an utter bag of poop."

Again, I'm well aware that AppleScript is not nearly an optimal scripting language. I far preferred using Microsoft's language(s) to script Word, even though I was learning them from scratch, instead of using what I'd already learned about AppleScript. (Though my background with BASIC may have helped.) But as non-optimal as AppleScript is, it really does Just Work.

"The truth is, AppleScript is a huge bait-n-switch: it looks friendly and approachable compared to other languages, but that's all just smoke and mirrors: once you actually get into using it, it is as complicated, convoluted, and intolerant as any other "programmer language". Worse, by disguising all that complexity beneath an ambiguous, obfuscatory syntax, it makes it far harder to understand what is actually going on."

From a programmer's standpoint, I'm well aware of the truth of this.

But from a scripter's standpoint, what really matters is readability and human language.

"AppleScript's harder even to use than "real programmer" languages like Python and Ruby."

Again, for a programmer, I fully agree.

"At least with those, once you get over the initial hump of being able to read their more cryptic, technical syntax, being able to write it is not much harder because at least they're truthful: what you see is what you get."

Right. But non-programmers like me never get over that hump. I've played with Python. And I'm still not a programmer.

-----

I think I'm basically not disagreeing with you on the merits of AppleScript, has. I'm just saying you don't understand the mindset of scripters.

Again, I can do amazingly complex things with AppleScript. For that brief, shining moment when AppleScript Studio let you write apps in pure AppleScript and Interface Builder, I built reasonably complex actual apps my household still uses everyday. I even contemplated building something to sell.

I can bridge into single lines of PHP, JavaScript, and UNIX to do extra stuff with AppleScript.

In short, I'm an absurdly high level scripter. But I can't get past the hump on even the easiest 'real' programming languages. And it's not like I gave up after high school. I've actually made attempts a couple of times since. It's just not me.

So, once we've finally accepted the point that I'm a scripter, and not a programmer, we're left with the merits of AppleScript as a scripting language. And like I say, I'm not sure we're in much disagreement on the topic. The only real difference may be that I'm saying the thing really does Just Work. I've got the thousand page manual on my hard drive, and I've very rarely had to refer to it. Lots of available samples and readability / human language have taken care of the overwhelming bulk of my needs.

I’m one of LaunchBar’s developers and I wrote almost all of the developer documentation linked above, including the code samples. As for using square brackets for list literals in AppleScript: That wasn’t a conscious decision on my part. Just like every time I write AppleScript, I’m just tried to get it to work syntactically whereas all that Objective-C and Swift in my brain may have influenced my typing a bit 😇

"But they tried Logo on me! And no go."

They probably taught it wrong. Like I say, tasked with a simple problem, Real Computer Experts invariably provide the most complicated, impenetrable "solution" possible. It simply wouldn't occur to them that Logo could be taught as simply as this:

1. This is a Word.

2. This is how you perform Words.

3. This is how you add your own Words to the vocabulary.

This is why Logo failed in its goal of making computation accessible to everyone: Papert spent all his time demonstrating he could successfully teach it to kids, when what he should've been doing was teaching it to *adults*. Because they're the ones who ultimately determine what, why, and how kids learn, and if adults' understanding is an utterly broken pile of crap then that's what the kids' understanding is going to be too.

...

And, y'know, good for you if AppleScript provided you the "in" into an otherwise seemingly impenetrable world - after all, it did the same for me too. But over the years I've gotten past the initial Dunning-Kruger phase to realize just how incredibly badly it actually does it, and just how far short it falls of being what it could and should be (and could've been were programmers not so atrociously bad at learning from their own history).

At best, AppleScript offers a few tantalizing clues on where to (and where not to) go next in making computers more accessible to ordinary humans. (It is, for example, why kiwi lets you write trim text instead of trimText, and why it's largely self-documenting through auto-generated dictionaries.) Plus, of course, it is proof of concept that empowering "ordinary users" to take greater control over their own machines offers incredible potential for all. But there's an awful long way still to go if modern computing is ever truly to deliver on that promise.

What's important for folks like us is not making the same mistake that the programmers make, of thinking that just because we've now got ours, a massive problem does not still exist for everyone else. Remember, for every AppleScripter like yourself, there's thousands (millions?) more end users for whom AppleScript is no more penetrable than any other programming language. That's an atrocious failure rate by any measure.

As users turned programmers, we know firsthand the value of putting programming tools in users' hands. And if the "real programmers" won't hand us suitable tools on a plate, perhaps we'll just have to create them ourselves. Hey, I'm already rolling up my sleeves; how 'bout you? :)

Leave a Comment