5 ms·

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.

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?

coderzach 12y ago
You show them AppleScript and SQL and they say "Wow, what was I thinking, english is a terrible basis for a programming language."
- pconner 12y ago
  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.
- meritt 12y ago
  SQL is pretty damn simple.
  - iso8859-1 12y ago
    Why are there no production-quality implementations of the newest standard then?
    - coldtea 12y ago
      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...).
- JohnBooty 12y ago
  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)
  - delian66 12y ago
    I guess the reasoning for the 'SELECT ... FROM' is that the FROM part is optional, for example you can do stuff like 'SELECT 40+2 AS the_answer' .
- coldtea 12y ago
  Well, if they think that about SQL, they are wrong. SQL is more like math than natural language. That it is declarative doesn't make it like Applescript.
- deleted 12y ago
  [deleted]
bla2 12y ago
> 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. Yup :-) AppleScript has an interesting history, it used to support multiple "natural languages" (such as French, ...) in addition to English: http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf (This is probably why many AppleScript Guides still say "English Dialect" on the first page, e.g. http://download.info.apple.com/Apple_Support_Area/Manuals/servers/AppleScriptFinderGuide.PDF http://download.info.apple.com/Apple_Support_Area/Manuals/se... ) Here's a Dijkstra rant from '77 against natural language programming: http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667.html http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667....
- cnp 12y ago
  Wow! That dissertation is so interesting.
- turingcar 12y ago
  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”.
Camillo 12y ago
HyperTalk was surprisingly ok, though.
- gilgoomesh 12y ago
  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.
  - turingcar 12y ago
    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.
gilgoomesh 12y ago
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).
- Someone 12y ago
  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.
  - turingcar 12y ago
    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.

coderzach 12y ago

You show them AppleScript and SQL and they say "Wow, what was I thinking, english is a terrible basis for a programming language."

pconner 12y ago
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.
meritt 12y ago
SQL is pretty damn simple.
- iso8859-1 12y ago
  Why are there no production-quality implementations of the newest standard then?
  - coldtea 12y ago
    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...).
JohnBooty 12y ago
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)
- delian66 12y ago
  I guess the reasoning for the 'SELECT ... FROM' is that the FROM part is optional, for example you can do stuff like 'SELECT 40+2 AS the_answer' .
coldtea 12y ago
Well, if they think that about SQL, they are wrong. SQL is more like math than natural language. That it is declarative doesn't make it like Applescript.
deleted 12y ago
[deleted]

bla2 12y ago

> 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. Yup :-) AppleScript has an interesting history, it used to support multiple "natural languages" (such as French, ...) in addition to English: http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf (This is probably why many AppleScript Guides still say "English Dialect" on the first page, e.g. http://download.info.apple.com/Apple_Support_Area/Manuals/servers/AppleScriptFinderGuide.PDF http://download.info.apple.com/Apple_Support_Area/Manuals/se... ) Here's a Dijkstra rant from '77 against natural language programming: http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667.html http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667....

cnp 12y ago
Wow! That dissertation is so interesting.
turingcar 12y ago
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”.

Camillo 12y ago

HyperTalk was surprisingly ok, though.

gilgoomesh 12y ago
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.
- turingcar 12y ago
  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.

gilgoomesh 12y ago

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).

Someone 12y ago
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.
- turingcar 12y ago
  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.