3 ms·

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

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.

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.