4 ms·

AppleScript's syntax was a mess of pseudo-english that was a pain to write (although considerably easier for newbies to read). The editor helped here quite a b

AppleScript's syntax was a mess of pseudo-english that was a pain to write (although considerably easier for newbies to read). The editor helped here quite a bit. That said, the infrastructure backing Applescript was amazing (especially for the time). The MacOS scripting interface was just as powerful as /proc, but far more structured. Every application and system service defined its own object-relational schema, and Applescript provided a SQL/Sparql-like language for querying that schema ("set foo to all of the Documents"). The schema and associated documentation were self-contained within the applications themselves via the resource fork, and Apple's HIGs set fairly high expectations for the quality of this documentation. And of course, as the GP notes, other languages could tie into the scripting framework (I have fond memories of using both Frontier and Hyperscript in this way).

Someone 4y ago
“Every application and system service defined its own object-relational schema” On the minus side, every application and system service had to implement its own object-relational schema, and there was little support for doing that. In theory, you could tell any text editor or text processor such things as “tell every sentence whose third word is "foo" to set last word to first character” and that entire code fragment would then run in the process of the editor, but in practice nobody implemented the support for such complex commands. That every application basically chose its own subset of the language is part of the reason AppleScript is so hard to write.
- hhas 4y ago
  > On the minus side, every application and system service had to implement its own object-relational schema, and there was little support for doing that. This was true in classic Mac OS. ObjectSupportLib provided some building blocks but there was no OS framework for implementing a “scripting” (Apple event IPC) View layer, comparable to what the OS provided for building a GUI View. Mac OS X 10.2 finally introduced the Cocoa Scripting framework—which wasn’t… great: Object-Relational mappers are Hard to do right when manipulating ordered Arrays (which OO-based apps love to use) instead of unordered Sets (as in traditional RDBMSes)—but was just about Good Enough. Alas, while CS made it a lot easier for Cocoa app developers to add “AppleScript” support to their apps, the fact the whole platform was shackled to the AppleScript language by default killed its ability to grow market. 10 million geeks on Mac OS X, and maybe only 50 thousand who could stand to touch AppleScript at all. But, as I noted up thread, when Apple tried to create geek-friendly alternatives to AppleScript, Scripting Bridge and JXA (which should have been pure catnip to y’all because Apple event IPC itself is awesome) they screwed the pooch so badly they didn’t only ruin those products but wrecked all the third-party alternatives as well. … > In theory, you could tell any text editor or text processor such things as > > “tell every sentence whose third word is "foo" to set last word to first character” > > and that entire code fragment would then run in the process of the editor, but in practice nobody implemented the support for such complex commands. Yup, queries are awesome. And there were in fact some apps that implemented robust query support at this level very, very well—e.g. Tex-Edit Plus, Adobe Illustrator—but those tended to be apps written pre-OS X by developers who worked very hard to nail it. (Adobe Illustrator’s scripting support was written by Mark Alldritt, better known for his [Script Debugger](https://latenightsw.com/ https://latenightsw.com/) editor.) In fact, you can run a query much like the above (replacing `sentence` with `paragraph`) in Apple’s own TextEdit, which uses Cocoa Scripting’s Text Suite to implement its text object model. The query itself works, but the `set` command silently fails. Commands like `move` and `duplicate` are even less reliable, often disappearing text entirely! The CocoaScripting framework needed a really good mathematician to engineer it, but got a random NeXT dev instead; and with AppleScript’s original creators long gone from Apple they just bodged it as best they could. … > That every application basically chose its own subset of the language is part of the reason AppleScript is so hard to write. Nope. No harder than using third-party Python libraries in a Python script is. Each library has its own API, with commands and objects specific to its particular task. The real problem was twofold: 1. Each app’s own API documentation was almost always massively inadequate. There was no way for a human user to tell which object queries could be used in which commands, except by actually trying it and seeing if it worked. Horribly opaque and unpredictable. I doubt most app devs even realized how inadequate their docs were, because most devs didn’t use AppleScript themselves. 2. AppleScript then compounded the confusion by layering the IPC stuff in mountains of syntactic sugar, enough to rot the teeth out a sperm whale, ostensibly to make AppleScript “simpler” but instead just making it impenetrable. The road to Hell is paved with good intentions… and AppleScript’s with the arbitrary injection of keywords. Pedagogical nightmare. … There is a postcript to all this, which is that Apple really are fools to throw away all these decades of work despite its flaws. Because they have Siri now, which is a query builder, and that, combined with what is probably the most powerful and flexible general-purpose user-level query handling architecture ever built outside of google-dot-com, ought to be THE killer USP across all of their platforms ny now. Alas, best tech in t’world can’t fix Stupid. PEBKAC.
dmitriid 4y ago
> and Apple's HIGs set fairly high expectations for the quality of this documentation. Ah. And herein lies the problem with modern day Apple

Someone 4y ago

“Every application and system service defined its own object-relational schema” On the minus side, every application and system service had to implement its own object-relational schema, and there was little support for doing that. In theory, you could tell any text editor or text processor such things as “tell every sentence whose third word is "foo" to set last word to first character” and that entire code fragment would then run in the process of the editor, but in practice nobody implemented the support for such complex commands. That every application basically chose its own subset of the language is part of the reason AppleScript is so hard to write.

hhas 4y ago
> On the minus side, every application and system service had to implement its own object-relational schema, and there was little support for doing that. This was true in classic Mac OS. ObjectSupportLib provided some building blocks but there was no OS framework for implementing a “scripting” (Apple event IPC) View layer, comparable to what the OS provided for building a GUI View. Mac OS X 10.2 finally introduced the Cocoa Scripting framework—which wasn’t… great: Object-Relational mappers are Hard to do right when manipulating ordered Arrays (which OO-based apps love to use) instead of unordered Sets (as in traditional RDBMSes)—but was just about Good Enough. Alas, while CS made it a lot easier for Cocoa app developers to add “AppleScript” support to their apps, the fact the whole platform was shackled to the AppleScript language by default killed its ability to grow market. 10 million geeks on Mac OS X, and maybe only 50 thousand who could stand to touch AppleScript at all. But, as I noted up thread, when Apple tried to create geek-friendly alternatives to AppleScript, Scripting Bridge and JXA (which should have been pure catnip to y’all because Apple event IPC itself is awesome) they screwed the pooch so badly they didn’t only ruin those products but wrecked all the third-party alternatives as well. … > In theory, you could tell any text editor or text processor such things as > > “tell every sentence whose third word is "foo" to set last word to first character” > > and that entire code fragment would then run in the process of the editor, but in practice nobody implemented the support for such complex commands. Yup, queries are awesome. And there were in fact some apps that implemented robust query support at this level very, very well—e.g. Tex-Edit Plus, Adobe Illustrator—but those tended to be apps written pre-OS X by developers who worked very hard to nail it. (Adobe Illustrator’s scripting support was written by Mark Alldritt, better known for his [Script Debugger](https://latenightsw.com/ https://latenightsw.com/) editor.) In fact, you can run a query much like the above (replacing `sentence` with `paragraph`) in Apple’s own TextEdit, which uses Cocoa Scripting’s Text Suite to implement its text object model. The query itself works, but the `set` command silently fails. Commands like `move` and `duplicate` are even less reliable, often disappearing text entirely! The CocoaScripting framework needed a really good mathematician to engineer it, but got a random NeXT dev instead; and with AppleScript’s original creators long gone from Apple they just bodged it as best they could. … > That every application basically chose its own subset of the language is part of the reason AppleScript is so hard to write. Nope. No harder than using third-party Python libraries in a Python script is. Each library has its own API, with commands and objects specific to its particular task. The real problem was twofold: 1. Each app’s own API documentation was almost always massively inadequate. There was no way for a human user to tell which object queries could be used in which commands, except by actually trying it and seeing if it worked. Horribly opaque and unpredictable. I doubt most app devs even realized how inadequate their docs were, because most devs didn’t use AppleScript themselves. 2. AppleScript then compounded the confusion by layering the IPC stuff in mountains of syntactic sugar, enough to rot the teeth out a sperm whale, ostensibly to make AppleScript “simpler” but instead just making it impenetrable. The road to Hell is paved with good intentions… and AppleScript’s with the arbitrary injection of keywords. Pedagogical nightmare. … There is a postcript to all this, which is that Apple really are fools to throw away all these decades of work despite its flaws. Because they have Siri now, which is a query builder, and that, combined with what is probably the most powerful and flexible general-purpose user-level query handling architecture ever built outside of google-dot-com, ought to be THE killer USP across all of their platforms ny now. Alas, best tech in t’world can’t fix Stupid. PEBKAC.

dmitriid 4y ago

> and Apple's HIGs set fairly high expectations for the quality of this documentation. Ah. And herein lies the problem with modern day Apple