The independent hodgepodge of isolated apps allows function to evolve without breaking other products. The problem with jack of all trades apps like Framework and others was that it is hard to satisfy particular markets with one generic product without bloat. Some people decry variety, but variety is necessary to satisfy all the different needs. Dynabook was a fantasy born of some theory that a single structure would be generally useful. Apple created the Applescript (now called Automator) that allowed you to use Apple Events and communicate between applications. Some older apps were entirely scriptable, but nowadays hardly anyone uses it. There just isn't that much cross communication between apps that makes sense. After all, each project has its own data structures which is really what isolates them; many programs don't agree on how to store numbers, which is a rather major problem if you are talking about intra-program communication.

There just isn’t that much cross communication between apps that makes sense.

I have a hard time believing this in a fundamental way. Perhaps with the architecture we currently have, but I think a lot of the time, despite using different data structures, we’re talking about the same things. Like, a comment on youtube is the same thing as a comment on facebook, even though there is no sense in which they can be interoperated on. I agree that the market has not borne out the utility of a single structure, but I think of this more as a local vs. global optimum kind of problem. Wrt applescript, I don’t have any familiarity with it, but I think a solution that requires that developers implement support for it is doomed to fail. What I imagine working is a system where interoperability is the default. But this makes for a less viable business, as it’s harder to lock in your customers (though, I think this difficulty is desirable from an engineering/social perspective).

Yeah a lot of my problems with programming exist 'between programs', not just inside them.

I think looking at the success of zapier and ifttt among other tools shows that there is actually a market for cross-app communication. More over, I think "sharing" and "import/export" is usually another big primary use case which has been solved pretty nicely these days. Also webhooks as a premise is pretty successful for many developers as a tool for connecting entire companies.

Hmm, I wouldn't say 'solved pretty nicely'. I'd expect, for example, a nice solution to preserve provenance and history as I import/export any media object or slices of it through various transformation tools.

For scripting, I feel like the primary challenge is having robust view-model, a direct way to talk about entities that you see on the screen. It's frustrating because we come close in some sense — I mean we can talk about buttons and lists and menus — but not quite enough to automate things. I'm reminded of extracting text from PDFs.

On business side, RPA, “robotic process automation”, is trending and perhaps becoming a billion dollar industry. It is essentially about using macros, scripting and screen-scraping to automate flows that span over multiple applications. So there is definitely demand in enterprises to get siloed apps to communicate without human intervention.

The reason for all the screen scraping is that web app makers have no intention of facilitating database operations on their private data. In the old days companies facilitated cross-program communication, and it was considered essential for all apps to support open, close, print, etc., as basic operations. If you didn't support those you were considered incomplete.

@Jared Windover Re AppleScript, for the record, developers implementing it was not a problem early on. Almost all of the important Mac apps were scriptable in the early 2000s. The problem is, and always has been, that just too few people use it.

The browser companies never really got behind AppleScript. So once web apps became so dominant, AppleScript was no longer usable because you were missing a connection, and then the commercial apps like Zapier, etc., spring up to fill the void. Basically the industry dismantled the intra-program protocols as the web was ignoring them. The Web and the companies behind it like Google, Facebook, etc. is a very arrogant world that has the fundamental attitude that they are in control, and that other people better get out of the way.

Yeah, definitely that’s true that AppleScript never worked with the web, on the other hand the web has its own approach to interapp communication with APIs which seems to be working out alright? Google's stuff seems pretty scriptable, e.g., Google Sheets, Facebook not so much, but that’s definitely a business decision, not a technical one.

Interesting discussion! I agree with @Edward de Jong / Beads Project that external control of apps has disappeared mainly because today’s dominant players can afford not to offer it and have a commercial interest in creating silos and walled gardens. But we also lack the infrastructure, technical but most of all social and legal, for a market of small to mid-size players to develop interoperable components of non-trivial complexity. Software development is all bottom-up. You take existing stuff (dependencies) and build on them. There is no top-down design as it’s done for material goods, based on markets for standard components and subcontractors that produce to an agreed-on specification. Therefore complex software assemblies are fragile unless they come from the giants who control their full software stack.