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.
Another things I find quite valuable in my work as a fellow lawyer is Regular Expressions, which can be tied up to pretty much ever other language and automation tool out there.
That has proven to be a great way for fetching cases cited, identification numbers and pretty much everything else that has a similar “mask”.
I took an online course on regular expressions and enjoyed it. But all my case files are PDF’s. I don’t believe I can use regex to search those documents.
Assuming you aren’t using another tool like DevonThink to index your PDF files, take a look at HoudahSpot. It supports regular expressions.
I use it most to fetch information copied and pasted into BBEdit straight from web interfaces (Brazilian legislation is largely available as simple HTML files) or from single PDF files (mostly court rulings and contracts), but I found a terminal utility that will perform those searches and am looking forward to try it soon.
It’s called PDFgrep and is able to match the pattern across a single file or multiple PDF files listing them alongside the corresponding page numbers.
On that note, there’s also a RegEx “dialect” for using inside Microsoft Word and Excel that’s also very helpful. It’s called wildcards over there and has a few diferences from the standard PERL format.
Re-skimming 
this…
… On the Excel question, it might have been this thread or just my general need/frustration that led to this blog post of mine:
And, later, this one:
Automating Microsoft Excel Some More
I might have to have a third post involving the word “Yet”…
1 Like
The language you should learn is the one that’ll do the thing you want now. Any language is an investment of time and effort and pointless failure and experimentation and you need rapid payoffs or it’s futile. The fact that one or other language may be more popular and open broader horizons is relevant only to those who intend to make a living writing programmes. I don’t - I just want repeatable code. As a lifelong tech-creative in film and TV, I started with AppleScript maybe 15 years ago and have found it indispensable. It meshes with the shell - “do shell script” - which gets you down to hex code if you need it. I use it daily across a couple of businesses - my partner’s spa business uses a script I wrote to parse outgoing emails from Timely, a web-hosted booking service that hangs off the website, extract appointment and client data and enter it into a FileMaker database, running hourly. Yes there’s Zapier - incomplete and costly - but AppleScript is free. I have dual OSes on one of my Macs, and use it to do a quick reboot to the other without going via Startup Disk. I use it to turn spaces into underscores, and rename DCPs based on their CPL data.
And I’ve started learning Lua as implemented for Blackmagic Fusion and Resolve, and it’s very, very similar - with AS and a bit of bash (or zsh these days), the biggest issue is whether the delimiter’s a comma or semicolon, curly braces or straight. I’m planning to adapt Bryan Ray’s Voronoi fuse script to simulate Apple Motion’s Crystallize filter, which the great Simon Ubsdell uses all the time in his VFX tutorials, and that’s built in Lua.
In short all learning helps and all roads lead to ease with everything else - learn the one that does today’s task I reckon. AppleScript might be a programmer’s pig, but it’s saved my career.
2 Likes
When I decided to learn coding to program a web app, I knew I wanted to do it in PHP. But I was having trouble wrapping my head around it on my own. I couldn’t find a PHP class, so I signed up for a community college evening class in Java.
I’ve never written a line of Java since, and hope never to have to — but the class was invaluable. It taught me just enough about how to program, and how to think about programming — which carries across languages.
I’m not saying you should take a Java class. But if you learn AppleScript now, and write a couple moderately functional scripts, or modify several scripts other people have written, it will have been worthwhile even if Apple pulls the plug of the language a week later. It will be easier to switch to another language, or to supplement your AppleScript with something else.
Since my foray into PHP (by way of Java), I’ve taught myself Python, a little Lua and a little Javascript. If I have to learn some Ruby to get something done, I’ll manage. Each new language gets a little easier.
3 Likes
I am going to Paris for a week. I need to be able to eat and sleep and get around. My native language is Serbo-Croation.
Should I learn French?
My answer would be no. Learning the French language is a big ask, and you do not need it to accomplish some basic things while you are in Paris. AppleScript is analogous. Learning AppleScript is extremely daunting IMO. I have three books on the subject. And the language knowledge you need varies enormously depending on the context and what task you are trying to accomplish and what applications you are dealing with.
If I actually has ever learned it, I would have forgotten it. What you need to know is just enough to complete the task at hand. Just enough French to order a meal and get a hotel. AppleScript is “necessary” to accomplish certain tasks. Learn enough to do what you need.
After you have solved 10 different problems with AppleScript, the 11th will be easier because you will remember little bits and pieces. For Paris, you will bring a French-SerboCroatian dictionary. For AppleScript you will use Google to look up certain things and try and find the solution to your problem or a similar problem on line and use that as a guide.
Learning some very basic AppleScript would be useful. On the order of what you might learn about French by listening to a training tape about French in your car while driving for a month or two before you fly to Paris.
AppleScript is a weird language. Trying to be fluent in it was for me a fool’s errand. But there are things that I want to do that require it. It is useful.
3 Likes