4 ms·
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
by simpaticoder 1y ago
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.
- xnorswap 1y agoIt's not long now until we re-invent SOAP and pretend it's a productivity breakthrough.
- singpolyma3 1y agoThis is called GraphQL
- no_wizard 1y agoHaving 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
- procaryote 1y agoWhy wouldn't you want your database schema to match how you use it?
- no_wizard 1y agoThe 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.
- whatevaa 1y agoVersioning is big one. Initially you can have them same/similar, but it is important to have that capability over time.
- singpolyma3 1y agoThere is nothing you can do with GraphQL you couldn't do with soap or vice versa. They're equivalent protocols. Maybe people got better at API design in the middle but that's not related to the protocol
- dnpp123 1y agoThe vocabulary you speak/write every day is a box. Your brain is a box. Your body is a box. /s