Applescript seems like a very powerful scripting tool because of its strong integration into the MacOS system. I've heard the English-like syntax is supposed to be a big strong point. For simple programming examples, it seems to work fine. I put together a script to update fields in MacOS Pages documents. The example I lifted from the web to update fields in a document works fine for the example text, but often breaks and is very cumbersome for the single-page Pages documents. After several months, with my more than 40 years of programming, I've been quite disappointed with Applescript.
Yesterday, I pulled out Keyboard Maestro and was able to get a script to do the same thing in about a half hour. And after looking over KM, I've found that it has a very robust integration with MacOS apps that I found so appealing in AS.
I've been told that AS is going away and that Swift is taking over. And I've heard that the downside of Swift is that it doesn't have the existing integration into MacOS apps that AS has.
What are your opinions on all this? Should I bother with AS over KM? Or bother with having to build MacOS App support with Swift?
What's are the possible downsides to just using KM (along with calling shell scripts from it)? Is there a better choice?
It depends on your telephone, and possibly tablet.
(The alleged similarity of AS to English proved more puzzling than enlightening in my experience. It took me longer to learn AppleScript than most other languages, including C, Basic, Pascal, Lisp and Prolog)
Yeah, same here. I learned APL in about two weeks at IBM, and AS seems to be way more verbose than it needs to be, and with some strange rules once you get past very basic applications. I assumed it was because of the various internals for each Application it had to deal with. But KM seemed to have surmounted those.
Does anyone know if all those languages like Swift, JS and others actually have convenient interfaces to MacOS, or do you have to go the route of scouring the net for libraries and extensions and custom utility packages?
For the moment, I am going to use AppleScript and JXA interchangeably. They are both based on the same core Apple Event model, that just have two different languages sitting on top. I'll come back to this in a minute.
KM can easily do many automation tasks that it used to require a script to do, and is, in general, much easier to use. However, some things are still best done by script, but KM can easily use most any scripting language, especially AppleScript, JXA, and shell scripts. It can also use Swift, and there have been a few attempts to maximize the use of Swift, but I have not seen any real of Swift to benefit workflow automation.
So, I approach almost all workflow automation tasks by starting with KM. Many times KM can do everything I need, so I stop there. Sometimes I need to interface with the scripting model of an App (like you did with Pages), so then I turn to AppleScript or JXA. KM can not really talk to the Apps scripting model, only its UI. Let me just add here that both AppleScript and JXA are completely dependent on the App developer to provide a good scripting model. And, believe it or not, Apple often provides a poor scripting model for its apps. Pages is one of the worst.
The hard decision is whether to learn AppleScript or JXA.
Here are the pros and cons, IMO:
I've used both Lisp (really popular early supercomputer language), but with Iverson, you mean APL. While at IBM, I built a really big diagnostic and data manipulation system entirely in APL. What people say about it being "write-only code" because it comes off as nearly indecipherable is pretty correct. Nobody would likely be able to maintain my code but me. But I loved that language's beauty and conciseness and really was able to write programs while the person requesting the requirements was writing them down. I also got the source code for one of the APL systems (nyah-ha-hahh) and ported it to my AT&T 3B1 along with creating my own APL font. I got a hold of a second Iverson book of "APL Tricks" and had already come up with all of them. So yeah, I was a sick puppy.
But AppleScript seems to be way clumsy for programs of any complexity beyond tutorials.
Actually, AppleScript can be very powerful. It is still the best language to control, and get/send data to Mac apps. When combined with Objective-C, called ASObjC, it is very powerful.
Yes, the AppleScript language is hard to understand and learn. But don't let its apparent simplicity or "clumsiness" fool you. In the early years of desktop publishing, AppleScript was the premier language to automate complex processing.
To be clear, you can also use JXA to do the same thing. So now you can choose the language you like best.
Hey guys, I think the question of the OP is what is the best tool to do workflow automation on a Mac.
There are lots of interesting and powerful languages, but very few can actually do workflow automation. AFAIK, only KM, and AppleScript / JXA, can do general purpose automation with good communication with apps. Shell scripting can do a lot of system stuff, but generally it is not well suited to communicate with most apps.
There are other tools, but they have a speciality, limited scope.
So, if a person is starting from scratch with no or little knowledge of KM, AppleScript, and JXA, I would start with KM. Use it to do your automation until you hit a brick wall that KM can't overcome.
Then you will need to pick AppleScript or JXA. I'd recommend JXA as being the easiest to learn, with the most built-in functions.
Amazing. I never knew that. I was under the impression, however, that there were some statistical analysis programs
that were similar to or based on APL. I remember HAPL was a hardware design language I used in college. Very cool.
I was just thinking that it would be very nice if I could execute an APL program from KM in the way we execute shell,
And it occurred to me that since I have an APL system recently installed on my MBP (my older systems haven’t been
compatible for years on the newer MBPs), I might be able to cobble together some sort of character interpreter (there
were lots of those around for APL years ago) that would translate some “pseudo-APL-character” interpreted stuff,
and send it to my new APL machine via the shell.
Sometimes a picture of the logic of a system gets pretty close to what an APL program to do it actually ends up looking like.