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.

An open source HyperCard clone: https://github.com/jhawcroft/cinsimp/

An open source HyperTalk (modernized and improved in many ways) https://github.com/kreativekorp/openxion

I've used OpenXION for shell scripting once or twice, on a lark, and it was a pleasant blast from the past.

For a while, there was a wonderful third-party alternative to Applescript known as "appscript"[0]. Your example above in Python would've been:

    app('Mail').outgoingMessages[its.subject=='JavaScript']

Appscript also had bindings for Ruby and ObjC.

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

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.

Someone should marry Perl & AppleScript: the best read/write language ever invented!

or the worst.

As Larry Wall said: "The potential for greater good goes right along with the potential for greater evil."[1]

[1]: http://www.wall.org/~larry/pm.html

PS. I always wanted to quote this :-)

True. Actually, it probably wouldn't be too hard to just write AppleScript within Perl to begin with. ;-)

Which is frustrating for programmers, but pretty neat if you share AppleScript on web boards (which seems to happen a lot) :)

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.

Really not sure what the point of either of these would be, could you fill in more of a real word example?

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.

The problem is the Javascript language requires you to import the Cocoa stuff

ObjC.import('Cocoa')

And then you get stuff like

task = $.NSTask.alloc.init task.running == task.isRunning

The AppleScript version

if application "iTunes" is running then --- Do stuff... end if

It may just be me, but in some cases the AppleScript version is easier and better.

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 Cocoa/Objective-C links are for building apps, not higher-level automation.

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.

The AppleScript example feels like COBOL - in theory it's more readable, bit it ends up being that there is just far more room for error / ambiguity.