I love AppleScript because whenever somebody asks, "Why don't they make programming languages more like English?" all you need to do is show them AppleScript.
The functionality exposed by OSX apps via AppleScript is often incredible, but the language itself is annoying.
The question is whether or not applications will support it. With the emphasis shifting away from OSX desktop applications to cross-platform and cloud apps, will OSX app developers still take the time to expose scripting functionality?
> I love AppleScript because whenever somebody asks, "Why don't they make programming languages more like English?" all you need to do is show them AppleScript.
For the record, AppleScript is not “natural language programming”; it is merely more similar to English than most programming languages. As with most mainstream programming languages, human terms (usually English) are used for keywords like “if”, “then”, “else”, “while”. It still has a very limited and structured grammar, like most programming languages.
In deference to the expressive flexibility demanded by humans, it does provide a few alias terms (“=“, “equals”, “is equal to”) and a few places where something can be written either left-to-right or right-to-left (“name of document” vs. “document’s name”), but even that is common in other languages. e.g., document.name vs. name(document), foo(bar.baz()) vs. bar.baz().foo(), and C’s support for both ”! && ||” and “not and or” operators.
Obviously, tastes vary, and I’m not trying to convince anyone that they should like something they don’t, but often people who complain that AppleScript is unlike languages they are more familiar with have only taken a cursory look at examples of AppleScript and are unaware that it has a syntax that is in fact similar to other languages. The primary differences are that it is very light on punctuation and prefers using descriptive words over abbreviations, because its goal is to be approachable for first-time and casual programmers. Even for AppleScript experts, this often helps make understanding or maintaining code easier.
Personally, I’d like to see AppleScript support some more “compact” syntax, like square brackets for array references, but I do not think it’s reasonable for AppleScript’s target audience to have to learn the meaning of “a ? b : c” before they can read simple conditional statements like “if a then b else c”.
Using words instead of punctuation isn't so bad --- I would be willing to learn a creole pidgin in exchange for being able to program without punctuation characters and using Voice Recognition. But three-word keywords like "is equal to" just make it impossible to intuit the AST from the language, and intuiting the AST is ultimately what makes a programmer feel comfortable with the languages. In this regard, AppleScript was like SQL but worse.
Python, OTOH, strikes a decent balance (assuming de-punctuating is your goal), avoiding punctuation by using keywords for 'and' and 'or' and 'not' , without making the grammar incomprehensible.
AppleScript is not a solid argument against natural language derived programming languages in general. AppleScript's problems have more to do with the fact that it looks like it should be flexible and powerful but in reality it is fairly limited and inflexible (and its documentation and error reporting are terrible, compounding its problems).
I think AppleScript's problems have more to do with the fact that it relies too much on external parties to do its stuff. The moment you do
tell application "foo"
every bar whose third baz is frob
end tell
whatever you write in that tell phrase gets executed by application "foo" (the logic runs in the process, and has to be written by the implementers writing the "foo" application). Implementing that flexibility is lots of work and hard because Apple did not supply much support libraries (1). Because of that, all implementations were incomplete (and differently so) and buggy. That "and differently so" was the main reason one cannot get comfortable writing AppleScript. Even if the above worked, there was no guarantee that, for example
tell application "foo"
the third baz of every bar
end tell
worked.
The essence of AppleScript goes very far:
- The editor imports syntax from "foo" the moment it sees that tell application "foo" block.
- When compiled, it converts that into a standardised binary format (an Apple Event)
- When run, AppleScript sends that event to "foo", and "foo" parses and executes it.
In essence, it turns application "foo" into a service that shows its internal state in its GUI (in 1993).
(1) in their defence, I don't think they could have written good support libraries in the language of the day. A few C++ 'interfaces' in header files might have helped, though.
Yes, implementing the object-oriented Apple Event Object Model (the conceptual model used to refer to properties and elements in another application) can be challenging to implement in a non-OO language like C. These days, Cocoa Scripting (in the Foundation framework) provides most of the code to map from Apple Events to Objective-C method calls, and using a language like Objective-C makes writing the rest of the code much more straightforward.
HyperTalk was brilliant because everything seemed to just naturally work. The grammar and object model were both highly intuitive – you really could just guess the right syntax.
AppleScript and HyperTalk are aesthetically very similar but every time I have to write something in AppleScript I get oddball parse errors that I can never decipher and I need to randomly try things until an approach succeeds (for reasons I don't understand) or I give up.
Where HyperTalk was friendly and forgiving, AppleTalk is punishing.
I loved HyperTalk, but my experience with it was that:
A. Almost any English sentence was grammatically valid.
B. Almost none of those sentences did what you expected.
I find AppleScript a more regular language overall. I think the biggest difference is that HyperTalk was built in to the HyperCard environment, and therefore most of the “language” was in fact just HyperCard-supplied functionality, whereas AppleScript has very little built-in functionality, and sometimes this surprises people when they discover that it’s up to some other application to decide what the behavior of the script is.
SQL is fantastic for relational data - it maps pretty closely to relational algebra.
About all I'd change is placing the column names after the table/object names - "FROM table1 SELECT col1, col2" instead of "SELECT col1, col2 FROM table" because it makes code assist features easier. (Microsoft did this with LINQ)
SQL makes sense, but at its core, it's a query language, not a programming language. You can do lots of arbitrary computation with it if you want and use it for things it's not good at, but for its intended purpose, it works pretty well.
1) He didn't say "implementing it" is simple. Just that the language (using it, getting started with it) is simple.
2) Vendors get a lot of benefits by NOT providing a standard implementation (lock-in, for one).
3) It's not like everybody runs around implementing every new standard that comes out. Vendors have their own timelines and priorities. Heck, we've waited how many years for CSS3 to be implemented? (and it's still missing full support...).
The functionality exposed by OSX apps via AppleScript is often incredible, but the language itself is annoying.
The question is whether or not applications will support it. With the emphasis shifting away from OSX desktop applications to cross-platform and cloud apps, will OSX app developers still take the time to expose scripting functionality?