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).
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.
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.
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.
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
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.
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 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.
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.
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.
[+] [-] andyfleming|11 years ago|reply
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).[+] [-] Tloewald|11 years ago|reply
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).
[+] [-] js2|11 years ago|reply
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.
[0] http://appscript.sourceforge.net/index.html
[1] http://appscript.sourceforge.net/status.html
Edited to add: I see the author of appscript has additional criticism linked to elsewhere from this thread - https://news.ycombinator.com/item?id=8329408
[+] [-] spullara|11 years ago|reply
[+] [-] acdha|11 years ago|reply
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…
[+] [-] crusso|11 years ago|reply
[+] [-] rikkus|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] linguafranca|11 years ago|reply
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.
[+] [-] lancer383|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] slyfu|11 years ago|reply
[+] [-] STRML|11 years ago|reply
[+] [-] robinhoodexe|11 years ago|reply
[+] [-] tjl|11 years ago|reply
[+] [-] collyw|11 years ago|reply
[+] [-] kevinSuttle|11 years ago|reply
Also, I'll just leave this here: https://www.quora.com/What-is-the-most-valuable-programming-...
[+] [-] ryanmarsh|11 years ago|reply
Checkout: https://github.com/node-app/Nodelike, and my own side project https://github.com/cucumber-instruments/cucumber-instruments
[+] [-] itafroma|11 years ago|reply
The general consensus at the time was that this was an experimental replacement/supplement to AppleScript.
[+] [-] charlieok|11 years ago|reply
Recall the “Joel test”.
http://www.joelonsoftware.com/articles/fog0000000043.html
In particular, item two:
I take that one pretty seriously. If I have piece of software I'd like people to be able to use, I'd like to be able to tell them to do the following: 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?
[+] [-] chrisweekly|11 years ago|reply
Anyway, the author gives a nice, simple overview of limitations of this approach, as well as simple reasonable use cases for it.
[+] [-] thomasfoster96|11 years ago|reply
Now if these APIs were usable via node-webkit...
[+] [-] cdnsteve|11 years ago|reply
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
[+] [-] coldtea|11 years ago|reply
Were did you get that idea? Extrapolating your personal usage habits?
Mail.app is one of the most frequently used OS X programs. From 30+ Mac users I know, most of them use Mail.
Not everybody has switched to webmail (or wants to).
I personally use it with a Gmail account.
[+] [-] weaksauce|11 years ago|reply
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.
[+] [-] MiddleEndian|11 years ago|reply
I switched away from OS X in 2011, and I still miss Mail.app.
[+] [-] dubcanada|11 years ago|reply
[+] [-] vezzy-fnord|11 years ago|reply
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.
[+] [-] js2|11 years ago|reply
http://www.cs.utexas.edu/users/wcook/Drafts/2006/ashopl.pdf
[+] [-] rubymaverick|11 years ago|reply
https://gist.github.com/ericallam/a5cd76651c327b116a6e
[+] [-] milos_cohagen|11 years ago|reply
[+] [-] oatmeal_coffee|11 years ago|reply
[+] [-] geetarista|11 years ago|reply
[+] [-] ryanmarsh|11 years ago|reply
You can check it out here https://github.com/cucumber-instruments/cucumber-instruments
[+] [-] lukeredpath|11 years ago|reply
https://github.com/songkick/rubium-ios
You can use it with Cucumber or Rspec or whatever.
[+] [-] johnpowell|11 years ago|reply
It was pretty easy to record with automator and then have cron run that at a given interval. But that didn't work with click and drag.
Luckily there is a pretty simple way to do this with Python.
Here is a sample with clicks and dragging. http://pastebin.com/fG1d081k
[+] [-] andybak|11 years ago|reply
[+] [-] MagerValp|11 years ago|reply
No better way to learn than straight from the person who's responsible.
[+] [-] sleepychu|11 years ago|reply
[+] [-] delinka|11 years ago|reply
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.
[+] [-] andyfleming|11 years ago|reply
[+] [-] mamoriamohit|11 years ago|reply