After pushing a while on “block”-automation Apps such as Shortcuts and Keyboard Maestro, I’m finally realizing that the next steps in my automation story will probably require more “abstract” scripts.
I’ve been toying around with Python (Automate the Boring Stuff) and more recently with AppleScript (I mean, trying to understand it besides the copying and pasting other’s scripts).
Now I fell I’m really getting a grasp with these languages, mainly AppleScript. Last episode with Doug Adams actually really got my mind going with AppleScript.
However, considering Apple’s lack of interest in automation tools for macOS in last years and even the depart of @Sal from Apple has got me thinking if this effort will be able to pay itself back.
Taking a look at the landscape for automation languages and our multi-devices world, I wonder though if it will be a good idea to invest my time in AppleScript or if this time and effort would be better invested in learning other more future-proof automation language which could be more easily ported into an iOS or even a Windows machine. And if so, which of these languages does the community thinks should better contribute for the tasks related do a lawyer/law professor?
As a fellow lawyer, I’d suggest investing the time learning javascript. It works on both Mac and iOS and there’s a lot of great materials out there for learning.
I don’t know the future of AppleScript, but I would bet on Siri Shortcuts automation over AppleScript at this point. But to up your automation game (while Shortcuts is early days):
I’d also say that, in my experience, the most effective way to learn javascript (or really, any programming language) is to have a specific use-case in mind.
For me, that was getting Drafts to do what I wanted it to do (which became more sophisticated as I learned more). Drafts has a very useful script reference that has lots of examples showing how you can use little bits of javascript to make Drafts do the things you want it to do. Scriptable does too, though I find Scriptable’s documentation a bit more confusing, at least at first.
Whatever you choose, pick some little bit of automation you want to accomplish and feel free to ask for help along the way.
Great advice from @cpac. And Drafts is a great sandbox since it’s so limited and focused yet useful in functionality, so great place to start. And plenty of simple examples as existing Drafts.app scripts.
Yeah Drafts is a good place to start, especially as it’s almost the same scripting on Mac and iOS now.
But…you’ll be limited by its general reliance on URL schemes for inter-app communication. With apps like Devonthink, Omnifocus, Filemaker, Bibdesk, and the whole MS Office suite, there’s so much more you can do with Applescript natively.
I’m with the other folks on investing in learning something like Javascript if you want a language that you can learn and can also apply some automations too.
Although AppleScript can achieve some amazing things (see the videos here) it’s definitely weird and inconsistent.
There are examples of doing things in Applescript on the web. Too few, in my opinion, bu they are there. At least being able to understand them and adapt them would be handy.
But, as others have said, javascript has widespread usefulness.
I like to think my bona fides as an AppleScript hater are well established, so when I go against the grain of the foregoing comments, I’m going against my own grain, too.
If you want to do what AppleScript does on a Mac, you have to understand AppleScript. JavaScript for Automation (JXA) is nice, but it’s weird, and most of the weirdness comes from twisting JavaScript syntax to accommodate AppleScript ideas. You have to know what those ideas are to understand the twists.
More important, the great majority of Mac automation example code you’ll find on the web is in AppleScript. If you want to progress as a JXA scripter, you’ll have to know enough AppleScript to translate.
If you do decide to learn AppleScript, you must get Script Debugger. It’s a bit expensive, but invaluable. Trying to use AppleScript without Script Debugger is like trying to walk around in the dark in a furnished room with the lights out. Script Debugger is like turning the lights on.
Especially valuable is the Explore tool. Most applications have little or no documentation for how AppleScript is supported in the app. There is a lot of guessing, hair pulling and head knocking. Script Debugger’s explore tool eliminates all that – you can instantly see what each app supports, and quickly experiment with it. When I first got Script Debugger 15 year ago or so, I had a problem in scripting iTunes that I had literally been working on for days without any progress. With Script Debugger, I figured it out in less than 10 minutes.
I know I sound like a paid shill, but I have no commercial connection with Late Night Software. I have gotten to hang out with Mark Aldritt (the author) a couple of times long ago at WWDC and MacWorld, he’s a cool guy (and quite talented), but I don’t work with them.
Another important point is that AppleScript isn’t really a single language. There is some overall structure, but each application you want to script mostly has it’s own language. So you don’t just learn it once, you have to separately learn how to script the Finder, how to script Safari, etc. for every program you want to automate.
This is also why AppleScript is the only thing that does what it does. It’s the only language that has this tight integration with all the apps that support scripting. (Well, technically so does JXA, but as @drdrang mentioned, that integration was really designed for AppleScript itself and is only crudely bolted on to JavaScript in the JXA system.)
Sadly, most of the scripts readily available online and most often used by novices, who then share them and raise their popularity, are very badly written. The effect is self-amplifying by teaching newcomers how to create terrible scripts and pass them on. I think that’s the biggest obstacle to learning AppleScript, because only programmers stand a chance of being able to gain proficiency, and the majority of programmers loathe AppleScript because they aren’t comfortable with the syntax, and so also never get familiar with it to appreciate its value. There’s literally nowhere I can think of that houses a library of AppleScripts of a standard I would be happy to use.
JavaScript isn’t at all a bad suggestion, as it’s well established, versatile, and powerful. It’s also a nice blend of both imperative and functional paradigms, with some object oriented guff thrown in but totally avoidable. It’s also the other available language in the open scripting architecture that can be used to send Apple events that control applications, i.e. you can write AppleScript using the JavaScript language. It’s sadly not being maintained at all, but it has some very appealing attributes.
But my suggestion in relation to automation and scripting in macOS would be Hammerspoon. It’s established and doesn’t seem to mind that no one knows about it. It’s extremely powerful, in that it could let you do anything for which the operating system has the code that allows it to do so. The limiting factor is only one’s knowledge and skill and experimentation. It’s scripted out of the box with Lua, which is easy to learn, surprisingly capable, and well established and used by a variety of applications, most notably by gamers who create mods for their RPGs, and by VLC to extend its functionality, etc. But it’s not going to be something you would use for developing, in case law wasn’t your true calling.
So the other suggestion from an all round perspective is python. It’s easy to learn, powerful, imperative/declarative, functional, and hot with developers too.
So this is not true at all. Each scriptable application defines its own classes, properties and commands, but the way these get implemented remains consistent with the rest of AppleScript. The syntax is the same, and all one has to do is glance over the application’s dictionary to see the terminology available for use. It’s quite logical.
To the novice, it’s absolutely true. I thought I had a reasonable grasp of AppleScript and scripting apps like the Finder and Calendar. Then I tried to write a script to control Excel. I felt like I’d landed on a different planet.
That’s probably because Excel has a really poor AppleScript implementation. Like, really, really poor. And very idiosyncratic. It’s not a good example of an AppleScript implementation at all.
I’m really surprised to get pushback on this point, which is a common complaint that comes up when AppleScript is discussed. Yes, the syntax is the same no matter what application is being used, and you can look in an applications dictionary to see the terminology. But different applications can use the terminology completely differently, there is no standard. Every application developer comes up with their own way to do things. When you are coding up a solution, the question is “how can I get it to do what I want”, and knowing that answer for one application usually isn’t of any help in figuring out how to do that for another application. It’s the opposite of logical.
Here’s another way to look at it – medical textbooks and poetry are both written in English, but knowledge of one doesn’t get you very far in the other.
It’s not just an issue for novices! Matt Neuburg, author of “AppleScript: The Definitive Guide”, told me that this was probably the biggest problem in writing the book, and in feedback he got from readers. He found it really frustrating because though he could exhaustively teach AppleScript syntax, that doesn’t help much in learning how to deal with specific applications. Yes, you need to learn the AppleScript syntax (and I recommend Matt’s book), but then for each additional application you want to script you’ve got a new learning curve (if you’re lucky, if your unlucky, the application developers won’t have bothered to create a scripting interface at all).