This is a great resource for learning javascript https://eloquentjavascript.net
2 Likes
Thanks! I’ve made note of it!
+100 on this.
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.)
2 Likes
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.
1 Like
+100 on this. I wish I had understood this years earlier than I did.
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.
1 Like
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.
1 Like
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).
That was @provuejim’s point. You don’t get to choose. You’re at the mercy of the implementation.
1 Like
Absolutely! One of my favorite tech book chapters of all time is the one in which he walks you through his experience trying to figure out how to script FrameMaker. It’s in the appendix in the 2nd edition, but in the 1st edition it was one of the first chapters of the book and did such a great job of demonstrating how even the author of “the definitive guide” had to bang his head against the wall a lot to figure things out sometimes.
I was in a similar position and had this same conversation with myself a few years ago. I was mostly a copy-and-paste AppleScripter. Should I go deep and really understand AppleScript, or should I learn something with a future? At first I thought the answer was obvious: Go with the future. I’d learn JavaScript so that I’d have a skill that can be applied across various platforms, including JXA on the Mac and Workflow/Shortcuts on iOS.
Then I read about the dearth of JXA documentation, and about how (as @drdrang pointed out) JXA requires an understanding of how AppleScript works. On top of that, I realized that while I may someday replace my personal Mac with an iPad, my work Mac is not going to change to an iPad for a long, long time.
Did I want to learn something I might use in the future, or did I want to learn something I can start applying to my life now. I went with now and spent a year or so really boosting my AppleScript skills. For me, it was the right decision.
For you? It really depends on what you need and what will be realistically practical for you.
1 Like
As the author of an application that supports AppleScript, I can tell you that implementing it is a difficult, thankless task. Apple’s documentation is poor and confusing (what else is new), and they really only provide a minimal skeleton for you to build on. So it’s no wonder that there wound up being so much variation between implementations. And since so few users will actually use AppleScript, developers can’t really afford to pour significant resource into it. As I mentioned before, many developers just throw up their hands and don’t provide any AppleScript support at all.
The original question was whether it was worth it to learn AppleScript at this point in time. If you need to build an automation solution that ties together multiple apps, it’s pretty much the only way to go (assuming the apps you need to use have scripting support). It seems like Apple is probably not going to drop AppleScript any time soon, just let it coast with no investment or promotion. There probably won’t be many new apps that support AppleScript, but there aren’t many new Mac apps period. It doesn’t really cost Apple anything to let things continue, so I anticipate the status quo to continue. AppleScript can’t be easily replaced because doing so would require the participation of all the developers.
By the way, I recently added x-callback-url automation support to my application (so it could talk to apps like Ulysses, which support this but not AppleScript), and AppleScript doesn’t look so bad compared to x-callback-url. (However, my hat is off to the x-callback-url developers for figuring out a way to make interapplication communication possible at all on iOS, without access to the internals of iOS. A very clever hack!)
2 Likes
Then that’s not an issue of the language, it’s an issue of the novice’s conceptualisation and understanding of the language.
Yes, it does come up a lot, but to the extent it has really just become something that’s echoed and passed on as de facto truth. But I’m not in any way suggesting that anyone who claims it is difficult is somehow wrong, or lying, or stupid. Not at all. Everyone finds different things difficult or easy, even experienced programmers who are only used to one type of language paradigm (often the case), finds switching to another kind challenging. A good example is the challenge many experienced coders have when they first attempt a functional language after being used to only imperative ones.
So it’s these statements that I’m not agreeing with. Yes, applications can definitely create their own terminology. But they absolutely cannot make the way the language is compiled and executed result in a different outcome that they’ve tailored to their own whims, which is what it sounds like you might be suggesting.
The application will have its own commands, many unique to it by name. But, it can’t decide to include a command that only accepts parameters written vertically. Every command is strictly defined by a name, which you look up in the dictionary; and it can optionally take a direct parameter, which it will indicate in the dictionary; and then a bunch of labelled parameters, each of which is labelled and typed in the dictionary.
The only other thing I can think of that has some variation between apps is to do with whether or not core suite commands are implemented and available. Some apps allow you to call open location with it, some don’t. And the level of dereferencing that takes place when an application returns a collection of objects is something that one needs to experiment with to determine what can be done with the collection afterwards, in terms of applying other commands to the items as a collection of individually in a repeat loop. But that’s not unusual at all.
Yes, it does. As someone who has learned foreign languages, whether I pick up a philosophy book in German or an instruction manual for television in German, the language follows the same grammatical rules (more so than English). The style is different, of course; but if I learn to read an instruction manual in German, I can most certainly read and understand the content of the philosophy book in German. I may not have come across the word Philosophie in the instruction manual, but I can sound the word out and look it up in a dictionary. I don’t claim to understand the philosophical concepts being discussed in German, but that’s wouldn’t be related to my German language ability, but rather my knowledge around philosophy.
And computer languages are actually processed and learned by humans in the same way as spoken or written languages, and target the same areas of the brain. The evolution and structuring of language syntaxes also appear to be homeomorphic to each other.
Although this will be less true in the near future and already is in some cases, for now, computers are very precise, very predictable, and very structured with the way they process instructions and carry them out. Therefore, even if someone arsehole developer wanted to make life as hard as possible for us like Apple is doing with everything they can think to deprecate, they wouldn’t physically be capable of getting a machine to receive an instruction and have it carry out that instruction differently. AppleScript’s language parser isnt sufficiently advanced or adaptive to be able to cope with anything that isn’t well defined to it, even if it appears ill-defined to human eyes at first. Indeed, the structure of Apple events themselves, whilst hideous, is nonetheless extremely consistent and logical. One way that could demonstrate how underwhelmingly regular AppleScript is as a language is to write scripts using the raw chevron syntax. This removes the terminology clutter, which I think is what throws some people in terms of how the language looks on first glance. But as all chevron codes are either 4 or 8 character codes attached to a finite set of named wrappers (event, handler, constant, class, script, property and data), without changing anything else, it’s immediately clear that there’s a one-to-one relationship between the language words and the terminology used to invoke them.
What did you decide?
Reporting back, @tonycraine, I’ve started learning AppleScript and found myself using it quite a lot in enhancing my everyday automations with Keyboard Maestro.
It also showed a side effect in making easier to grasp a few concepts on python (my current endeavor).
Two of my shareable projects that could benefit others both on everyday use and hopefully in helping understand AppleScript are:
-
An adaptation of @MacSparky elink TextExpander macro for using with Spark (on MPU Talk)
I’ve also managed to tie Hazel and Keyboard Maestro way further with AppleScript and look forward to having python scripts onto the game as there are many things that can be done with its text and data manipulation functions.
Finally, I deeply recommend as resources for anyone looking for good resource materials both Script Debugger app (it’s live dictionary helps understand how the items of an app relate to their information structures, thanks both to @provuejim and yourself, @tonycraine for the recommendation) and @Sal’s book on AppleScript (it’s huge, but if you follow the first chapter you’ll be ok for many things).
3 Likes
Depending on who you’re emailing you may find this modification of @MacSparky’s script useful:
1 Like
Too bad I didn’t come accross this forum post before buying Hasaan’s second edition book as well as Matt Neuburg’s book lol.
Last year I had picked up a new client that had multiple mac users that needed to connect to a Windows file server. Being mostly a Windows IT engineer, I was up to the challenge of working with macOS. I actually enjoyed researching and building that script so much that I decided to purchase a mac of my own as well as some applescript books to dive deeper into the language.
1 Like
I’m a lawyer and teaching myself Javascript. Wonder how you use it in your practice though. Programming is just a hobby right now but I’d love to make it more efficient for me in my litigation practice.
It mostly started with wanting to use Drafts to track my time. It was tedious to turn the handwritten notes I kept into something I (or my assistant) could enter into my firm’s billing software. I started by just adding a button to Drafts that inserted the current time. Then I modified it to round to the nearest 6 minutes to make the duration calculations easier. Then I decided I didn’t want to calculate the durations, and instead wrote a script that took one of these “timeslips” and turned that into an email that had the correct durations, including combing separate entries for the same client. Then I added client number lookup. Then I added added a step to also send the time to my own .csv file and to create nice reports from it. There’s a much larger explanation of all this on my micro.blog. But in short, I started with a small annoyance and slowly built it to add more and more convenience for me.
I have another Drafts action script that takes notes of a phone call or meeting, prepends them to the appropriate client’s com log, and adds any tasks from the meeting to Things.
Really, I think the best way to learn is to find small annoyances—tedious or error-prone tasks that you have to do frequently. Pick one. And see if you can’t write a script to do it more reliably. Manipulating text seems to be the best way to start, particularly since regular expressions can come relatively easy to lawyers who are used to “terms and connectors” searching in Westlaw or Lexis.