Computers are boxes, therefore all software is literally (and figuratively) "in a box", are they not? This might seem like a frivolous jest, but it is not. For example, the author points out that clojure, java, kotlin can interoperate, but notes they are stuck in the same jvm 'box'. This generalizes and recurses, so you must find a specific place to stop, and then motivate that.
One likely place to stop is at "processes". But this must be motivated since ultimately processes are as synthetic a convention as a language thread - it's just that the runtime is called a "kernel" instead of a "runtime".
Ultimately I think what the author is getting at is a data problem, not a code problem. Or rather, it's yearning toward a world where data and code are strongly decoupled, conventions around data are standardized, so that processes written in disparate tooling can successfully interoperate locally. However I doubt there is much appetite for a "model of everything" registry (such things have been tried, and failed, in the past). That said we might take another stab at this, since LLMs make likely that software will become more dynamic in terms of translating data structures at runtime such that one program can examine a peer program and its data structures, and how to map them to local data structures, thus achieving interoperability without a centralized agreement on representation.
It's not long now until we re-invent SOAP and pretend it's a productivity breakthrough.
This is called GraphQL
Having used SOAP and GraphQL, I really disagree with this characterization.
The problem I have seen at most organizations is they simply want their APIs to reflect their database schema, even if its not a good or useful idea. They throw junk over the wall.
They carry this practice over from REST to GraphQL and of course its horrible, its not a good way to use the technology.
Now organizations that understand GraphQL allows you to create a data schema unbound by its sources, they leverage GraphQL quite well, and its very pleasant to use. Unfortunately not enough organizations do this, or do this well.
SOAP was and is still simply a bad protocol and had tons of issues ranging from security to payload size to parsing issues between different clients
Why wouldn't you want your database schema to match how you use it?
The whole point is to decouple the two. The gql queries are written for purpose, they’re not suppose to care about the data sources. This becomes even more important when a single query may grab data from more than a single source.
The vocabulary you speak/write every day is a box.
Your brain is a box.
Your body is a box.
/s