Chris, thanks for creating and sharing such a tremendous resource.
JMichael
Good list of references !
Stepping back a bit, perhaps the key is really to get a clear grasp and practiced familiarity with the core concepts – after that the syntax of any particular language is really just a variation in detail.
My list of the core concepts would probably be:
- What is a variable, really, and what is going on in assignment of values to variable names ?
(and what kind of values are there ? Numbers, strings, true|false ‘booleans’, and lists, for a start) - How do
true | false(‘boolean’) values work in combination with operators like AND, OR, NOT ? - How can one break a problem down into a nest of sequences, branches and loops ?
and then how can you:
- hide details with ‘sub-routines’ ?
- apply a function to a value and collect the function’s result ?
and for extra credit
- how do you write a function whose definition includes itself ?
- why would you want to ?
- how can you use a function as the value of a variable ?
- and why would you want to do that ?
And for context:
What does Lisp look like, and how, broadly, does it work ?
( There is a sense in which all language translators/interpreters rewrite to something very much like Lisp before rewriting down to machine code, and while a dialect like Applescript is relatively niche and ephemeral, we can be fairly confident that even in other galaxies the deep structure of coding is bound to be Lisp-like. See section 9 (conclusion) of Phil Wadler’s paper )
Expertise is not so much knowing the details as grasping the fundamentals, and the best introductions to Applescript might even be books like:
https://mitpress.mit.edu/books/little-schemer on Lisp
or http://eloquentjavascript.net/ on Javascript
( The concepts are the same, and once you have those, the details will come easily : -)
2 Likes
Following on from @ComplexPoint’s, err, point, one of the best ways to learn basic programming I’ve seen recently is the Hour of Code, which teaches these sorts of fundamentals. It happens that they use JavaScript, which is very handy for web programming, and now becoming very handy for Mac automation programming as well.
2 Likes
I'm not sure that I agree. 
I find the so-called "natural language" of AppleScript to actually work against the fundamental knowledge I have of programming, and the many years of programming in other languages. Since I have never thought about coding in a natural, english-language like sense, I find AppleScript to be counter-intuitive.
If a person has never programmed before, of course they need to learn the basic concepts of program design. But learning another language that is nothing like AppleScript might be more of a hindrance than help.
It seems to me that few of the terms used in AppleScript are used elsewhere, and most of the terms common in other languages (and even design) are not used in AppleScript.
So, IMO (and I am far from being an AppleScript expert), a person with no programming experience is better off starting with AppleScript focused training, be that books, tutorials, videos, or other.
As Chris mentioned, much of learning AppleScript is learning the unique code for a specific application. For me, the fastest way I have learned is by example, inspecting, testing, code written by others.
Just my 2¢.
Yes, I do think AppleScript’s well-intentioned “Englishness” is inadvertently obfuscating, although I’ve had a lot of fun using it over the years.
As you already have all the concepts in place, it might be worth experimenting with JavaScript for Applications once you install Yosemite. It feels in a way slightly late in the day to start putting a lot of work into making sense of Applescript, especially given the broken or defective nature of its record type, and its dependence on 3rd party fixes for some library basics like regexes.
( AS records can’t tell you what keys/fields they’ve got, and raise errors if you test them to find out )
Thanks for the suggestion. I will most likely dive into JXA as soon as I upgrade to Yosemite.
Is JFA intended to be a full replacement, or alternate, to AppleScript?
IOW, should I be able to do anything in JXA that I can do now in AppleScript?
Does JXA use, or access, the AppleScript API provided by an app?
Yes, they use exactly the same library interfaces – it's just a set of alternate syntaxes for accessing them. Anything reachable by AS is equally reachable by JXA.
The Yosemite .sdef library viewer now allows you to switch between three viewing syntaxes:
That's great! Many thanks.
Rather than continue our off-topic discussion about learning AppleScript and JXA here, I have started a new topic. Please continue your excellent posts here:
Learning & Using AppleScript & JavaScript for Automation (JXA)
That is at least the intention.
Following other folks' efforts to use JXA since its inception I've noted that a number of things were (or still are) broken, however Chris Nebel and Chris Page at Apple have been working hard at improving AppleScript infrastructure — so I expect things to keep improving.
-Chris
Yes, I am sure it will continue to develop, but in my experience ver 1.0 is already an excellent resource. FWIW I have written a fair amount of it by now without hitting any glitches : -)
( The NSXML access took me a while to figure out :- )
( You can see a range of explorations in the JavaScript for Automation Cookbook wiki )
Chris, could you share the specific things that are broken?
Hey Michael,
Since I'm still using Mavericks and for that matter know only a smattering of JavaScript I've only paid attention in passing.
Once I upgrade my system I'll start doing more JavaScript and take JXA for a personal test drive.
-Chris
There was some active grumbling on various forums by someone who (it turned out) had written their own JavaScript bridge which they felt Apple should have used.
The word ‘broken’ was used fairly vehemently, but there wasn’t enough detail for me to get a sense of any specifics.
I don’t know what the technical merits of the argument were, or why Apple apparently declined the offer, but I’ve personally found JXA an excellent medium to work in, and I’ve always been able to make all the calls to application automation interfaces without any problems.
The core JavaScript language interpreter is, of course ( after so many years of browser competition) very highly optimised and battle-hardened.
That's actually Hamish Sanderson co-author of one of the best AppleScript books and developer of appscript.
While he definitely has an ax to grind with Apple (and others) he probably is one of the top five most knowledgeable people in the world of the deep mechanics of AppleScript and Apple-Events.
Note: I'm not saying JXA is broken — I'm just giving fair warning that people should be aware this technology is very young on OSX and not everything has worked smoothly — especially in the early days. One specific issue that comes to mind is: Subject: JXA failure with delay function.
This I believe is supposed to be fixed in El Capitan.
Personally I'm quite looking forward to using some of JavaScript's goodies, and I think I'll like the syntax once I get used to it.
-Chris
Looks like that was solved in the thread by calling the delay function properly.
Sounds like you have the reverse problem I have. You know AppleScript extremely well and it sounds like JavaScript is something new. I'm just the opposite.
I'll probably upgrade to Yosemite very soon, knowing what I know now about JXA. It's been about a year since Yosemite was released.
I know this topic is about AppleScript, but I just ran across a related article on:
Finding, creating, reading and updating KM variables from JXA Javascript
that I thought might be of interest.
Ah! Batman and Bruce Wayne!
Thanks.