I tried using AppleScript a couple of times. One of the worst user experiences of my life. Zero documentation for the syntax and semantics of the language, almost no documentation for the library part, the documentation that existed was 7 years out of date (I was on leopard, the documentation still referenced OS 8) and even after those hurdles I was handcuffed to the sparse and poorly designed API that OS X programs had, that was put in as an afterthought.

Calling that a "solution"...

I suspect GP means AppleEvents rather than AppleScript.

AppleEvents are a high level event framework, it lets you tell applications things like 'select the 5th word of the 2nd paragraph', or 'import all mp3s from /Volumes/USB'. AppleScript tries to allow you to use those exact phrases and creates an uncanny valley language.

Automator and other automating applications use AppleEvents to do their magic. Cocoa has AppleEvents built in for the basics, but support has been spotty beyond that so a lot of people are turning to the accessibility framework.

To script a UI application you also need the developers to stop moving things around. I suspect this would be hard, since they are not used to it mattering, if they swap the order of two input fields or such. In the text based world, there is much more aversion to changing the flags.

If you use AppleEvents correctly, moving things around wouldn't matter, because the scripting interface is completely divorced from the GUI displayed on screen.

AppleEvents are things like: "File Open with this path", "Print page 4 of file", "Save As to this path".

If someone creates AppleEvents like, "Click button 4 on dialog 2", then they're doing it very wrong.

What do you mean by "uncanny valley language?" Is it too close to natural language, but not close enough or what?

Yes, exactly that. For example:

    tell application "Finder" to duplicate (every item in folder "Documents" of home whose modification date comes after (current date) - 7 * days) to folder "Documents" of disk "Backups" with replacing

It's almost, but not quite, English. It'll trip you up when writing it.

I switched to Windows, so I honestly have no idea, but I get the impression that AppleScript/AppleEvents has been pretty much utterly ignored by OS X except for a small amount of backwards-compatibility lip-service.

I stopped using Mac OS when OS X dropped Classic compatibility.

It was still a solution, covering all aspects of the issue, and people have done great things with it.

But you conflate the solution with the particular implementation.

It could be whatever else language instead of AppleScript, e.g. Python or Javascript -- it's the idea that matters.

Hooking into graphical software that's not designed for that is a pain in the ass. Compared to stringing together various CLI tools that primarily deal in text interfaces.

What I, personally, prefer to do is construct libraries and simultaneously develop a collection of CLI tools to access them. Then build the GUI afterward, once I've already vetted and tested the underlying business logic.

The benefit of this is the GUI for most users. The CLI for power users. The library for the developers that want to build additional interfaces or plug it into their projects directly.

> I don't even know what that means

I already gave an example, but I can expand on that.

A CLI compiler only has to take its input and run it through the various compilation stages to the end or abort if something is invalid.

To do what eclipse does for code completion as you type on the other hand you have to to hook into the AST generator stage and the type inference engine given partial, invalid inputs, try to fix them up and then do searches on what other known pieces can be dropped into a particular place.

Which means your compiler can't just bail out at its earliest convenience. It needs public, not internal, APIs to massage state back into working condition so the next steps can then run until the IDE has gathered enough information.

Or take a memory profiler (with allocation callsite recording). The first step of interactivity is being able to turn it on and off at runtime. That means hot-swapping out some code, imagine replacing a malloc with a call-stack capturing one. It gets even more complex if you're using custom allocators.

And for the analysis part: In a simple CLI tool you might just run some graph analysis that takes 20 seconds on a multi-GB heap dump which then spits out the top 10 dominators and a class histogram and you'll hopefully know what to optimize. And you might want to diff those outputs (yay for text processing!) for test runs so you know how things change from build to build.

In a GUI you want interactivity, which means you can't just run those 20-second calculations every time the user navigates through some tree view. You need incremental algorithms, caching sub-results - but not too much otherwise the profiler itself will munge too much memory - etc. etc.

So you need APIs that go deeper into your graph logic than what you would think of public APIs needed for the CLI. And of course you need to build the whole GUI on top of that too.

Having used AppleScript in the past and dealt with application stacks that relied on it, I would not characterize it as a "solution".

>> Many CLI tools are also non-interactive. Adding that interactivity adds complexity.

> Most things worth doing are difficult.

The most important thing is to identify and get rid of all accidental complexity.

> Most things worth doing are difficult

Complexity does not mean that it's worth doing because it's difficult.

Uh... huh? You lost me.