Learning and Developing AppleScripts

Googling “how to learn javascript for beginners” here’s some top hits:

The basics for controlling an application is to get an application object, execute methods of the object to get the needed information or the desired effect. You can get information about each application objects valid methods from the File > Open Dictionary menu in the Script Editor.


It is really simple and mostly self-explanatory. Let’s go over it together.

https://cdn-images-1.medium.com/max/2400/1*-SxWfDsCXWKnH76rvypPOQ.png

Firstly, we create a couple of variables that we will use frequently: currentApp for prompting something in the current application, finder for creating and moving files around and systemEvents for accessing to files.

The OS has a set of standard scripting additions that provide the ability to speak text, display user interaction dialogs, and more. To use them, an application must explicitly set the includeStandardAdditions flag to true. The third line stands for that. We’re declaring that we want to use these additions.
After that, we prompt a folder chooser panel to get the folder to be processed. Then we create a new folder in the same directory to move the processed files into it."


And from our own @DanThomas

I’ll tell you right up front - getting up to speed is a daunting task, because the documentation, when there actually is some, is extremely sparse. That’s why I’m hoping you’re willing to document your experience, here in this topic.


While JXA initially looks cool and capable of producing results fast and perhaps easier then via AppleScripting, getting into JXA from the perspective of not really knowing anything about scripting and given the seemingly little being offered directly for the rank novice isn't as approachable as I’m finding for AppleScripts.

I don’t have the necessary distinctions to compare the two languages to meaningfully evaluate whether it’s worth taking the perhaps shorter but seemingly more difficult climb to get going with JXA rather than AppleScripts. It seems AppleScripts was designed with learning it baked into its very structure. That gets a LOT of points from where I’m standing.

Of course the argument that “So what? When you get to the top of that mountain you’ll find that it’s not all that great compared to what you see on the JXA mountain” can be leveled and again I can’t effectively argue.

Do I really want to learn AppleScripts? No . I just want to do some really simple stuff like file some stupid receipts and make some notes and organize some information. Are the tools ALREADY available to do that? YES. And..

I could just read physical books, write on paper, and throw receipts into a shoe box like most people and rummage around looking for stuff when I want or need it but computers appeared and damn it I'm going to get it to do what I want it to do the way I want it to do it and now if that means learning all this coding language thenI will! Do I "want to", no.

Not really. :wink:

TLDR.

If you have an essential question or two in all of that, please post succinctly, and I will try to answer. :smile:

Nothing essential, just appreciations and external thinking for my own clarification that hopeful will benefit others considering joining the climb. Thank you.

Bern,

Most of the text you posted seem like quoted text to me. Please correct me if I’m wrong.

In case I am not wrong, please format quoted text as quoted text. And, BTW, don’t post too much in one chunk. People will not read it (me included).

Back to the topic, more or less:

I started to dive deeper into AppleScript around 2012 or so, quite some years earlier into shell scripting, but that mainly for very specific (occasional) tasks. I’m using Macs since 1994.

In my experience :

With AppleScript you can do many things, with AppleScript-ObjC you can do even more things. Never had a need for JXA. But I like it, because the JavaScript syntax is way easier than the damn AppleScript syntax (which, ironically, was planned as an “easy’ syntax with its similarities to natural languages.)

How to learn it (the “climb” as you name it):

If you are not pressed (by your chief or something), then just let it evolve: You’ll find things in your every-day life you want to automize. Then just do it. Thoroughly. I mean, that one task, thoroughly. Look up the resources on this forum or on StackExchange, etc.

By programming that one task you’ll learn more than you’ll learn with courses (IMHO).

The point is that you don’t have to “know” AppleScript. Nor any other language. However, it is good to know more of AppleScript, and of other languages. But it is also good to know just something about other languages, because this gives you the possibility to look at an object from different perspectives.

It’s a bit like with natural languages: The more languages you know (or practice) the better you understand your own language (this point is very important!) and the easier it will be to understand new ones (and to wrap around any things in general.)

Just my 3 cents

– Tom

Added quotation marks around quotes. Thought the preface to each quote made it clear the following as being quoted. I'll follow the agreed upon convention going forward. TY.

As for posting too much “The definition of genius is taking the complex and making it simple.” ― Albert Einstein

I'm working on it...

Nothing on fire so definitely taking the evolving route. I'm as interested in the process of learning AppleScripts as doing anything useful with it. It's a longer path that interests me.

I like your expression of doing one thing thoroughly. I phrase it "Doing complete work" and we're on the same page.

Definitely, multiple languages shed light on each other. This idea informs my choice to move among multiple sources.

"...JavaScript syntax is way easier than the damn AppleScript syntax..."

Could you give me an example or two? The tell x to do y of AppleScript seems clear and simple.

tell application "Finder"
   empty the trash
end tell

How would JXA or plain JS empty the trash?

Thanks Tom.

28 posts were split to a new topic: How to Quote Text and Script Code Blocks

Edited it to make it more approachable. Thank you :wink:

@BernSh and @Tom, since your extensive discussion about how to make forum quotes was considerably off-topic, I moved all of your related posts to a new topic in the Forum Admin section.

I agree with you. Speaking about Markdown is forum meta, not content.
Sorry if I violated some rules.

Thank you for cleaning up the organization and maintaining the quality of the discussions. I promise to do so as I get better at this.

If with "so" you are referring to "maintaining the quality of the discussions", I think you are already pretty good at it :slight_smile: (no offense meant!)

Exactly what I meant.

I can’t even imagine an interpretation I’d take offense to and I’m not on the defense, fence, or offense about it. :grin:

You are a good and kind man, Tom, thank you for being supportive!

Just reading https://www.cultofmac.com/629988/swiftui-wwdc-2019/ and in talking about the evolution of Apple’s software it said “Before [rejoining Apple in 1997] Steve Jobs was CEO of a company called [NeXT], which produced a cutting-edge operating system called [NeXTSTEP]. Applications for NeXTSTEP were developed in a programming language called [Objective-C].

Apple purchased NeXT because it needed a shiny, next-generation operating system to replace the aging System 7 that Macs ran on at the time. Cupertino adapted NeXTSTEP to become Mac OS X, which later morphed into the macOS, iOS, watchOS and tvOS we know today.

Even after all these years, if you take a look under the hood, the origin of Apple’s platforms remains clearly evident. The names of the object classes Apple uses in its code start with the letters “NS,” for “NeXTSTEP.””

I’d be seeing all those “NS”s in front of things and thinking they had some deep technical meaning I’d someday learn after much pain and suffering from shedding all the blood, sweat, and tears needed to know such lofty things. Nice to discover its much more earthy and relatable origins as that makes the seemingly cold and impersonal machinations of coding much warmer and approachable :smile:.

Some friendly tales and bantering around the camp fire to accompany and enhance the creative act of learning a new language seems inviting.

Hoped so. I added the “no offense meant” only to make clear that there is absolutely no irony involved. (Since by nature I’m more the ironic, sometimes sarcastic type of writer/commenter.)

Thanks for pointing to that good article, especially since I didn’t yet find the time/patience to dive into all the “details” of this year’s WWDC.

And yes, news from the campfire, like this, are incentive also to me to not let down my combined efforts to learn Swift / macOS UI / iOS UI programming, which will ultimately result in the creation of a nice app that will yield me a constant income of €1500/month. [emoji of your choice here]

Besides that I also perceive learning a new language as something really creative. Learning frameworks not so much. (Possibly has to do with the “frame” in “framework” :wink: )

Just coming across articles about scripting languages being depreciated over the next couple of years:


What does this mean in relationship to my nascent AppleScript ambitions? Would it be a better long-term plan to focus on Swift or elsewhere?

I gleaned that with additional work things will continue as before for a couple of years and reading the tea leaves is always tricky, still, this seems be suggesting a significant change in the making.

I don't yet understand the larger structure that scripting fits within and so can't fully appreciate what these articles are saying. If anyone would translate into a CliffsNotes-ish conversation for us neophytes I'd appreciate and maybe understand a little more.

Nothing, I think.

I don’t see AppleScript mentioned anywhere in these articles. And AppleScript is certainly not a “UNIX scripting language”.

Concerning the other scripting languages (Ruby, Perl, Python, …):

The current situation is this:

macOS comes with these languages pre-installed, but usually not in the latest versions. So, if anybody does some active scripting in one of these languages, the usual first step is to install an up-to-date version of the language (e.g. via Homebrew or MacPorts).

As a result you have two instances of the language on your computer: 1) the outdated version that came with the OS, and 2) the up-to-date version you installed yourself.

This can lead to confusion, because you always have to make sure that your PATH variable gives precedence to the up-to-date version. On the other hand, you don’t want to uninstall the pre-installed version, because it is not transparent whether the OS itself is actually using the language (for example for some internal maintenance scripts or similar).

So, for most users it is probably an improvement if Apple gets rid of the preinstalled languages, because you don’t have to worry anymore if your script runs with the correct version of the interpreter. (And obviously we save some disk space by only having one instance of each language on the computer.)

As mentioned in one of the linked posts, the removal of the languages will be a not so good thing, if you are working as macOS service technician, because you can’t any longer run for example your Perl check/repair/cleanup scripts on a client’s computer. You’ll have to install Perl first, or bring your own Perl on an external disk.

I hope this helps and didn’t add more confusion :wink:

1 Like

Another thing worth to think about:

Without the pre-installed languages in future macOS versions you might think it will become more complicated to post Perl/Ruby/Python/etc. scripts on forums (or KM macros that contain such scripts).

I don’t think so. Right now (with the pre-installed scripting languages on every Mac) there are potential portability issues. To eliminate portability issues you have to do one of two things:

  • Before posting, test your script/macro against the macOS pre-installed language version. Problem here: 1) More work, and 2) if someone is using an outdated OS version, he will still have a different default language version on his Mac than you.

  • You tell the user to install the up-to-date version of the scripting language, for example via Homebrew, before running the macro/script. Problem here: For some users it is difficult to install something with a command line tool like Homebrew. And you also have to explain how to set the correct PATH, or ENV_PATH in KM.

In the future – without any macOS pre-installed languages – you only have option 2: The user must install the language on his computer. After an initial “acclimatization” period everyone will have understood that a language that is required for a macro has to be installed on the computer. And doing this will become a more normal thing.

At least I hope so.

Hey Bern,

Apple is fixing AppleScript bugs in Catalina, so I don't think we have much to worry about for a while.

The day automation leaves the macOS I will too, and I'm not alone.

A Mac without adequate Automation is about as useful as a balsa wood boat anchor.

-Chris

1 Like

Yes this is a longer term look down the road consideration.

Looks like automation remains firmly in place. It’s the form it may take that’s Applely unclear. :wink:

Thanks!

Thanks Tom! That’s clearer and useful to be aware of. I appreciate that. :smiley: