The problem isn't the AppleScript's wordiness, it's that knowing the exact way to phrase a command correctly is horrible (and it doesn't help AppleScript is implicitly strongly typed).
In HyperTalk you could write something like put 4 + 4, get it; or set fred to 4 + 4; or put 4 + 4 into fred. You could leave quotes off a string, or put quotes on a number, and it would usually "just work". This made HyperTalk easy for non-programmers to write, yet still easy for programmers to write well (and debug). AppleScript allows even more syntactic constructs than HyperTalk, but they all turn out to be semantically different in incompatible ways. (It's very much like they map directly onto C++'s . -> * and & directly.) So if you can set fred to 4 + 4, you probably can't put 4 + 4 into fred. (I'm pulling these examples out of my ass without looking up actual syntax because I can't be bothered.)
I went from being a competent HyperTalk programmer to "godlike" thanks to a book by Danny Goodman (The HyperTalk Bible, I think). When AppleScript came out, Apple commissioned Goodman to write the definitive book on AppleScript -- I read it and still couldn't get anywhere. AppleScript is kind of like Blender. I can eventually figure out how to do anything, but knowledge of how I did it evaporates almost instantly. It's perhaps the worst programming language I have ever actually tried to master.
Danny Goodman later wrote books on JavaScript and DHTML which, for their time, were just as great as his HyperTalk stuff, but no-one has ever been able to make AppleScript not suck (for me, anyway).
I miss HyperTalk. It was my first "love" programming language. I agree, HyperTalk was different enough from AppleScript that you could be productive in HyperTalk, but lost in AppleScript. It might be due to the fact that AppleScript is a general purpose language, but HyperTalk was essentially a limited DSL for interacting with the HyperCard GUI environment. HyperTalk's limited scope was its best and worst feature.
I'm still surprised no one's made a small open-source HyperTalk clone. A compile-to-JS-and-run-in-the-browser version would be pretty cool.
Unfortunately, Apple deprecated the underlying API in 10.6 that made appscript possible and never provided a suitable replacement[1].
As always though, the problem wasn't Applescript, but rather limited support for Apple Events by applications. Unless that problem is fixed, adding Javascript support to the OSA isn't going to help much.
I've always found AppleScript to be a read-only language. It is obvious what it does once written, but writing it is very frustrating as you have to get the phrasing just right.
The main problem with AppleScript was all of the corner cases – above doesn't look so bad but once you tried to do anything more complex you'd have a thicket of convoluted code because they didn't allow many of the basic language features we take for granted in JavaScript.
The main thing I'm curious about is the quality of the bridge with the native APIs. AppleScript had so many never-fixed areas where bugs in the underlying implementation produced nonsensical error messages (e.g. `A scripting error has occurred: Can't make «class ppth» into a «class ppth»`) which required you to get out a debugger to figure out what was really going on. Be helpful to novices right up until you pushed them over a cliff…
Right. The problem with natural-ish language processing is that it's:
1. Inherently imprecise.
2. Not true natural language processing, so it's not as forgiving of
syntax errors as you'd think - making it even more difficult
to try to say what you want to say.
#2 is right on. Making a language look like english seems silly to me. Spoken languages are ambiguous where programming languages can't be. Why try to make it look like english when really it behaves nothing like it?
Unless you had a parser that could truly read it like english.
That looks pretty straightforward - it retrieves a list of messages from Mail which have a particular subject. Presumably you can then perform actions on them.
I think you're misreading the document, I don't think you actually have to instantiate an NSTask in order to compare whether another application is running. You would just do something like this:
Mail = Application('Mail')
if (Mail.isRunning) { ... }
The history behind AppleScript involved being able to write it in any language, not just English. But that was a terrible idea and Apple knows that.
English (more specifically, JavaScript) is the Lingua Franca for the majority of programming, and we've all come to accept that, for better or worse, in good times and in bad, in sickness and in health.
Given that he mentions he was in contact with the dev team, we can be pretty sure he provided feedback. Ten years ago I participated on that list and 'has' was full of opinionated feedback for everyone. He's the one who wrote appscript, mentioned elsewhere on this thread.
I'd rather have Lua to be honest... But JS is better than AppleScript in this regard. While easy to understand, it wasn't suited for large projects and debugging was kinda nasty.
The Open Scripting Architecture (OSA) used to support additional languages instead of just AppleScript, I recall that Perl was one of them in the past. Unfortunately, this changed at point. I'm hoping that Javascript support points to them re-opening this.
OSA does not support things, it's the underlying platform hook. AFAIK third parties have always been free to implement OSA bridging. In fact one bloke did exactly that[0] when JfA was first announced.
Yes, you could already do Lua (see LuaCocoa) and other languages like Python (PyObjC), Ruby (RubyCocoa/MacRuby), and even JavaScript (JSCocoa) via ScriptingBridge way back from 10.5.
Ubiquity should not be an excuse for the promotion of what is, by all objective measures, a rather poor programming language.
This is especially true when it's an environment where there are numerous other languages available, and they're all so much better than JavaScript. Lua, Python, Perl, Ruby and even Tcl would all be better choices.
It's mildly excusable when it comes to web browsers, because JavaScript really is the only viable option. But that just isn't the case with a full-featured environment like OS X.
Ok, that's two steps but the point stands. Hopefully they already have git and a javascript runtime included with a fresh install of their operating system (assume they just brought the computer home from the store), and the script included in the project takes care of everything else from there.
What I definitely don't want to have to say is “Set up this whole massive toolchain for language X [and Y [and Z]] before you can run the project.”
Can this be done today on the latest releases of, say, Windows, OSX, and the most popular two or three Linux distributions? If not, are we close?
Naturally there's already a npm module for interacting with it: https://github.com/brandonhorst/node-osa (note the git repo is at 0.1.0, a couple months newer than its published npmjs counterpart at 0.0.2).
Anyway, the author gives a nice, simple overview of limitations of this approach, as well as simple reasonable use cases for it.
This seems interesting because it feels like I can gain more control over the desktop which previously I felt limited to by Bash or Python. Being a web dev I never wanted to get into Obj. C or Swift so this seems like it's opening some doors to a broader audience. It's funny they are showcasing Mail - does anyone actually use the desktop mail client? I thought that's been dead since 2003?
Can you leverage this API from within Node.js running on OSX ? Then we can start to see some cool, realtime desktop stuff.
EG:
How I think this could be used for a developer:
"Applet" or script that opens up a dev project you're working on.
- Open Sublime text (or whatever IDE)
- Pull latest down from Git
- Fire up your respective local server if needed
- Run tests
- Release unicorns if everything goes Green through Desktop notifications of some type
It's funny they are showcasing Mail - does anyone actually use the desktop mail client? I thought that's been dead since 2003?
I'm not sure if you're referring to OS X Mail in particular or desktop mail clients in general, but I personally still use the latter (Thunderbird) very frequently. Binding all of your webmail addresses into a single local application is quite convenient.
I have been using mailmate as a successor to thunderbird because thunderbird's search was so slow amongst many other show stopping bugs for me. It's worth checking it out if you search your mail a lot or have power user mail needs... The smart folders are a neat feature that are very powerful and fast.
I have used AppleScript to open the current finder location in a new iTerm tab and to open all selected files in vim or the folder if nothing's selected... AppleScript is terrible but the end product is useful.
Another one was to merge a folder of PDFs into one document and another to convert a bunch of images into one PDF. Useful stuff but a bit awkward to create it initially.
And I don't think hideous is a complaint, hideous is a personal opinion.
Imprecise, you'll have to expand on.
While certain things, depending on you want to do turn into a wild goose chase requiring multiple hundred lines of code to get something simple. That will not change with JavaScript, in some instances it looks like it may require even more lines with JavaScript. And it is a natural language, language. I don't think it is as terrible as you make it out too be.
As a recent Mac OS user, there were a bunch of things I wanted to automate with AS. I looked and looked for documentation and basically never found a coherent set of docs anywhere. So, I'd (still) love to see the thorough documentation.
But, that's just AppleScript. The problem is that the scripting dictionaries for applications are inconsistent. But, that's the fault of the developers and you'll run into the same problem with Javascript.
Oh, for a good overall site, I'd recommend Mac OS X Automation,
The best documentation is Matt Neuburg's _AppleScript: The Definitive Guide_ [1] although it may be a bit dated now. Matt is one of the most talented tech writers out there.
When OSX first came on the scene there was a javascript OSA. A company called "Late Night Software" or some such had a drop in that allowed you to use js.
I wrote up a script a couple of months ago using JS for Automation that will automatically rotate a Keynote file from portrait to landscape (for use in prototyping on Keynote for iOS that only supports landscape). It was my first experience writing any automation script, so there was a lot of trail and error and google searches. I personally would much rather work in JS than Applescript. Here is the script in case you want to take a look at some more JS for Automation:
This is an ok idea, but go look at the API for iPhoto, Contacts or iTunes and you'll realize it is irrelevant what scripting language is used. Really sucks that Apple doesn't open up their apps to scripting better.
Apple has its issues with scripting in its apps but other companies like Microsoft and Adobe have robust scripting support in their applications. Developers like me have created significant workflows using scripting that save my company money, time, and errors. Apps like iPhoto and iTunes are really small potatoes by comparison. Having Javascript with Cocoa for scripting is truly powerful stuff.
Adobe's scripting APIs are usually 2 versions behind in functuality and very buggy. Anyone with significant workflows that script Adobe apps got there through lots of pain and suffering.
Yes, I know because I script for them all the time, but at least Adobe's API's try to be more robust than Apple's. My point was really more towards there being more to scripting than just Apple's own apps.
my experience as well; i doubt any app has such extensive scripting support as Microsoft Excel; OmniGroup's apps omnioutliner and omnigrafle also had excellent scripting support--demonstrable just by opening up an app's 'dictionary' using applescript editor (and comparing those dictionaries w/ the dictionary iphoto, itunes, etc.)
In Instruments since iOS 7 this has been somewhat possible but the JavaScript context was fairly locked down. I wanted to drive my UI automation tests with Cucumber (Ruby) so I wrote a little driver that patches Instruments to get access to the JavaScript context and expose it to a rudimentary server which listens for commands from your Cucumber tests.
Yes, when I wrote this some time late last year I vaguely recall that Appium wasn't quite able to fit my need. It looks much nicer now.
I want something even less complex for the developer to set up. I want something that shows almost no brittleness. One way to do that is to use Apple's UIAutomation directly. I also wanted to be able to use Ruby and Cucumber, so I built as simple a bridge as I could.
In what sense? Apps show up in ps output, can be signaled with kill...
If you mean "capable of participating in plumbing," then you'll be disappointed. The app developer has the responsibility to add such functionality to consume stdin and produce to stdout.
I'm excited about the potential this will unlock. Applescript, while not too complicated, is a pain. Being able to throw together something quickly with javascript is going to make simple app scripting much more accessible.
> Does this work with JSC REPL for trying things out?
It does not: just tried it. The document lists the places it will work:
> The component can be used from Script Editor, the global Script Menu, in the Run JavaScript Automator Action, applets/droplets, the osascript command-line tool, the NSUserScriptTask API, and everywhere else other OSA components, such as AppleScript, can be used. This includes Mail Rules, Folder Actions, Address Book Plugins, Calendar Alarms, and Message Triggers.
It doesn't have a proper REPL mode, but the closest thing to what you're looking for is probably osascript.
> Hopefully this represents a system they can easily extend to other languages in the future.
The system ("open scripting architecture") has been there since the 90s, before OSX. Apple used to ship support for alternative languages, and osa's always been there for third parties to interface with.
Yay. I loved that the scripting framework existed and that so many native apps implemented it, but I've hated the actual AppleScript language ever since I first learned it 20 years ago. Has we not yet learned the folly of the "natural language" programming language? Luckily I'm not old enough to have ever used COBOL.
Many of the problems of AppleScript come from inconsistent scripting support from the applications. A command in one application will work subtly different in another one. Unfortunately, this problem will continue with Javascript.
Back in the OS 9 days, there was support for additional languages instead of AppleScript. I recall that someone did a Perl implementation and I think there was a later Javascript implementation. This support was pulled at some point in the OS X days. I'm glad to see that at least Javascript has been added back.
> This support was pulled at some point in the OS X days.
The underlying tech ("open scripting architecture") has been there all along though, so third parties could have implemented OSX bridges regardless of what Apple shipped. I can only assume nobody really cared much, leading apple to remove alternative implementations and nobody to take up the slack (because nobody really cared much)
ScriptingBridge which was a layer to formally connect other languages to OSA is still there (unsure about 10.10), but neglected. It was introduced in 10.5 along with official support for PyObjC and RubyCocoa in that release. Apple also touted being able to do the same from Objective-C.
Other 3rd party language bridges such as LuaCocoa and JSCocoa provided ScriptingBridge support.
Because node + npm have much broader appeal and libraries already available, and those that Apple is offering could very easily fit into this system. For that matter, Apple could have pre-published them as npm modules to the local global store for their platform.
node/npm exists and is very vibrant. Embracing it would have been a better move imho. Much the same reason they didn't creat ATML (Apple Text Markup Language) as a system for documents that only macs can use. They probably would have been better served by embracing a JS platform that already works well on Macs with libraries/modules that would have worked well for their platform.
Exactly, Node isn't the same as JavaScript.. node + npm is a very vibrant cross-platform ecosystem of utilities and libraries that Apple could have fit very will into.
Yes, it's based on a different JS engine than what they use... that really isn't the point... just like Python, Ruby and Java aren't Apple platform inventions.
I am simply disappointed that Apple chose to embrace NIH instead of a broadly supported, and growing system that would have been a great fit for this purpose.
AppleScript and the Open Scripting Architecture[0] long predate OSX, and could be used by third-party scripting languages[1], that just never caught on with developers/users.
Apple had caught up with WSH before WSH even existed, the underlying technology[2] dates back to System 7 (1991)
AppleScript [1] was introduced in 1993, the fact that you can now do the same things AppleScript does using a different scripting language is (for virtually all practical purposes) a matter of semantics. But nice try anyway /s
Well back in 1993 the only place I ever saw a classic Mac live was at the university. Even then it was on a tiny room just with 10 LCs. Everywhere else on campus was UNIX and PC.
The home market was divided between Atari ST, Amiga and PC.
Arggghhh, drives me nuts when people vote down this type of correction. As someone that lives somewhere where the language is not my native language, it drives me crazy that people never take the time to correct my mistakes, meaning I never learn that I'm making them. Seriously people, pointing out someone's error in grammar / spelling is not a bad thing!
It's not a bad thing, but it's not something that's supposed to be on the top of a thread either. A downvote to make it stick to the bottom is proper in my opinion, I doubt anyone would downvote it to oblivion.
Considering that if compiled into a .app it should require Gatekeeper (AppleScript does), it's not a big worry. If it's not compiled, you can easily view the source.
Not sure if this is what OP was getting at, but it's possible that the attack vector will baloon if more 3rd party apps are pressured to provide logical scripting interfaces
Considering Apple has been locking down the system with App Store distribution and Gatekeeper (and sandboxing), the attack vector risk will probably be constrained.
Here is some of the new JavaScript syntax:
Here is what it looks like in AppleScript While the AppleScript sounds logical, the JavaScript syntax just feels so comfortable and familiar (obviously).