Best MacOS Scripting Tool - KM or AS or Swift?

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.

If you are using iOS as well as macOS, JavaScript (a very useful adjunct to Keyboard Maestro) may be a better investment of your time than AppleScript. (iOS will never have any AppleScript utilities, but it has several JS-based scripting resources, including the Omni apps, on which scripting development has now moved to JavaScript both on the mac and on the iPad / iPhone.

(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?

1 Like

My primary Mac automation tools are: KM, AppleScript and JXA, JavaScript in Browser, Shell Scripts

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.

So, IMO, you need to learn KM, and then either AppleScript or JXA. If you need to do a lot of web page scraping/manipulation, then you will need to learn JavaScript (separate from JXA).

The hard decision is whether to learn AppleScript or JXA.
Here are the pros and cons, IMO:

AppleScript

PROS

  • Can use Script Debugger 7, a huge point in its favor:
    • Full IDE for developing AppleScripts
    • Full sophisticated debugger
    • Great for exploring and App's scripting model
  • Easy to make use of Objective-C power
  • Has a number of really good Script Libraries -- all free
  • Has great support at the Script Debugger Forum (Late Night SW)
  • There are many script examples available on the Internet

CONS

  • The "English-like" language is more of a hindrance than a help
  • It is missing many basic functions that other languages have built-in
    (fortunately, the Script Libraries help fix this)
  • I agree with @ComplexPoint, it is one of the hardest to learn languages I have ever used.

JavaScript for Automation (JXA)

PROS

  • Uses the same underlying scripting model as AppleScript
  • Everything you can do in AppleScript, you can do in JXA
  • It uses the same JavaScript core language as is used by millions developing web sites
  • I find JavaScript, and therefore JXA, easy to learn and remember.
  • JavaScript has many, many powerful functions built-in, including
    • String manipulation
    • Array handling
    • Object handling
    • Regex
    • Math
    • Date/Time
  • For more information, see JXA Resources

CONS

  • Lack of a good IDE and debugger
    • That's the only main con
    • You can use Safari to debug JXA, but it is nothing like Script Debugger 7+
  • While there are lots of general JavaScript, and JavaScript for Web, examples available on the Internet, there are very few JXA examples

So, it is a tough decision. But I would probably go with JXA. You'll find it much less frustrating to learn.

I hope you find this helpful. To be more helpful, we would need to see a list of the workflow automation tasks that you expect to work on.

Questions?

APL? :slight_smile: Applescript May be way more verbose than it needs to be - and you could say the opposite about APL. :slight_smile:

I wouldn’t think Applescript is going away but I would agree Keyboard Maestro and JXA are better bets to invest time in.

(Now whatever happened to that lovely multicoloured APL keyboard?) :slight_smile:

((((( I  do ((((Not))) Know)))))                     :slight_smile:
1 Like

Judging by the content of your contribution @jonathonl you are recommending Lisp :rofl:

1 Like

There was an earlier reference to Lisp, and I thought it would be fun to use it.

However, whilst I read Ken Iverson's book, I never learnt/mastered

SD←((+/((X - AV←(T←+/X)÷⍴X)*2))÷⍴X)*0.5 etc.

but I was curious to see how many people knew anything about Lisp, you being one of them. :slightly_smiling_face:

1 Like

Well - I don't know anything about APL or Mr Iverson, but the nightmare that was my Lisp-based operating system is now but a long-forgotten dream :scream:

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.

1 Like

Actually whole internal tools (CP80) and a product (Application System - from Warwick Lab) we’re built in APL.

As for LISP (and other functional-like languages), I was taught those in college. Bring it in with your CARs and HDRs... :slight_smile:

I would say javascript and python are the two most useful languages to learn right now. (And System z Assembler comes a close third.) :slight_smile:

Maybe I should do JXA this weekend...

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.

2 Likes

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,

applescript, javascript, etc..

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.

1 Like

Thanks for bringing us back on track, JM! :slight_smile: And thanks for a concise reply!

1 Like

However, I DID appreciate ALL the input! Especially stuff that got me interested in finding a way to interface APL with KM!

1 Like

Well, how about that. All I did was use the shell to echo an APL command to GNU APL via an execute shell command to KM. Nice. Now where's that Lisp interpreter... :slight_smile:

2 Likes

@JMichaelTX, do you have any pointers for JXA learning materials? I have not used JavaScript, but do understand OO principles well.

Sorry, no. But any ideas I run into will be posted.