Also, what would it look like if you got everything you want and this were fully implemented? How much would stay the same and to what extent would everyone do things differently? What implementation code would be running and where? (personally I'm OK with the 10x claim btw)

I think your data-first perspective strongly leads to a declarative approach overall, not the call-response RPC style. You may need to go and climb a mountain and meditate on this fundamental dichotomy! Just use spreadsheets as a data point. I strongly believe and commend this to you as aligned to your broader perspective.

@Jimmy Miller - Excellent observation about the 10x claim. I put it there to set the bar really high in terms of how much simplification I demand myself from this conceptual framework. My intent is to get people raising an eyebrow, rather than getting them drooling thinking of a payoff. But I acknowledge this is risky. Behind this (and I just put this in the Programmers' Preface) is that if many of us feel in our bones that easily 90% of software is pure accidental complexity (in the Brooks sense), then a 10x leap can come through by finding a way to drop this baggage with better tools (both conceptual and embodied). - Concerning your point about bottlenecks, I am referring to the conceptual burden of designing and implementing a system, where human brains (not computer performance) seem to be the limiting factor of the speed of development. My personal experience with several of these processes tells me that the use of the wrong abstractions, and a certain unfounded fear of concrete data, is what kept many smart people going in circles around something that ended up being quite trivial once understood. I'd really like your take on what are the human bottlenecks you've experienced, because it's very likely I'm oversimplifying things here. - Concerning consistency (and I'm grateful you made it all the way to the bottom!), I studied CAP and PACELC in detail as I wrote this section. Concerning your specific point, if X sends a message to Y and Y fails to process it without X knowing, this failure of consistency can be understood as an absence of stopping (or lack of transactionality). This is akin to the second non-parallel source of inconsistency I mention: `Not checking for errors in multi-step sequences.`; the lack of acknowledgment from Y to X is to me exactly equivalent to a sequence happening in a single node that doesn't stop when an error happens in the middle. But I'm open to more challenge in that example, and if you can find other counterexamples to my point I'd really appreciate them. The whole section was an exercise in trying to think the problem of parallelism and consistency from first principles; in every instance of the problem I found, I could always narrow it down to calls being expanded simultaneously (even concurrently by a single processor) that touch related data. What was liberating to me of understanding like this is that the concept doesn't require partitioning, parallelism or concurrency, but it describes the problem at the core of them all.

@Andrew F - I just put a link at the top, and even mention the core thesis in the link itself. Thank you for skimming past that long slog of an intro. - As for the applied cases, they are within each pillar. The pillars are alas quite lengthy, and I don't know how concrete they are. The most meaty one, in terms of solving concrete problems, is pillar 4 (logic), but probably 1 should come first. - I've been thinking about your point of the two flavors of manifesto (one to convince that there's a problem, another to tell the convinced how can we solve it). I realize that I'm basically writing this for those who already feel there's a problem. Guess I'm in the right community, after all!

@Duncan Cragg - I wrote this over the last three months; previous technical writing I did was much more applied and definitely not an attempt at a complete conceptual framework. I got the idea for the main point and the five pillars in one go; the [first draft](https://github.com/altocodenl/TODIS/commit/385d8934c4114ba2873270a12f85f34588139fec), dated a couple of days after the original idea had different pillars but the embryonic core was there. While it may feel it's coming a bit out of nowhere, all of this was brewing in my head for a long time, and only made possible by myriad influences from others (for example, a lot of Rich Hickey and Joe Armstrong in the last few months). - As for how it'd look if these principles were made into a tool, you put me in the spot! What I'll work on next is [cell](https://github.com/altocodenl/cell), which is a programming system. I plan on building it based on the principles of TODIS, and fully expecting that I'll have to perform surgery of uncertain extent in TODIS based on my experiences inside the trenches of cell. I'll be very happy to share some progress in cell when I have something, but for now it's absolute vaporware. Your questions about how things would look like if these ideas were implemented, how would people be working differently with software, I'll have foremost in my mind when I design cell. I really appreciate you stating them. - As for calls being imperative, I'd love to analyze this further with you. In the framework, there's nothing inherently declarative or imperative about a call. If anything, a call, in the sense of communication with intent, it's really a "what". The "how" lies in the implementation of the call (the logic, pillar 4); whereas the outside part of the call is an "interface", pillar 5. At the very end of pillar 4 I spout:

Microcode could be seen as a declarative interface to a CPU ("I tell the CPU what operation I want and let the CPU actually manage its own logic gates"). Similarly, a line of a very high level program might be seen as imperative ("give me all the rows from this database where the creation time is less than three seconds ago"). I propose that we eliminate this distinction

- In other words, at every level the outside of the call is declarative and its logic is imperative. There's no hard absolute line that says "above this, it's all declarative"; our understanding of it is self-similar, fractal, working at every scale in the same way. - Rather than try to convince you, I'd really like to understand why/how you see that a model based on calls is inherently imperative; and perhaps more importantly, whether declarative operations (when they are requested, not when they are implemented) cannot be modelled themselves as calls. I promise to keep an open mind! - I just discovered your work on Onex. It seems we're both in love with the spreadsheet! Cell too is a programming model based on the spreadsheet. Really cool that you're working on that direction!

Everyone who joined in this thread, thank you again for your brain cycles and kind words. They mean a lot.

Initial thought: cell's "quadrivium: language, database, service and interface" map onto my own ONR, ONN, ONP, ONT: language, core database, p2p networking, i/o. Are you stealing my ideas??? 🤣

Onex vs Cell: I don't have number as a separate type, just string or symbol representations of number. This is biting me a bit in my string interning algo, as each tiny change in a number creates a new string in the pool. I sketched out an alternative for numbers but binned it. Even so, this is all about non-functional requirements - efficiency - not about the higher level model.

still in the weeds, and feeling like I'm hijacking this thread so this will be my last comment for now: "As for

null

, it can be represented by the absence of a certain key in a hash; but inside a list, it has to be represented with something else, such as the text

null

or an empty string." - I have two special concepts for unspecified values: unknown (could be anything but isn't set yet) and nothing (known-to-be-absent or is definitely not going to be set). Or not available vs not applicable. Setting a hash or map property to nothing deletes that property. setting a list value to nothing deletes that entry in the list.

Hi! Back again. On the "calls being Declarative, implementation being Imperative" topic: are you saying all APIs wrapping implementations are Declarative? That's not what most mean by Declarative! This is a good article to read in this area: https://stackoverflow.com/questions/602444/functional-declarative-and-imperative-programming/8357604

The common (non-academic) understanding of Declarative is that you declare a bunch of relationships in any order and then apply those to real data to get more real data. Every time you ask the question, and regardless of the order that your declarations are applied, the answer is the same. This so far means Declarative isn't Turing Complete, but to achieve that you simply circulate around your answers or outputs back into your questions or inputs.

@Andrew F - My fear about putting the pillars "up there" is that the document will be too geared towards programmers; I still have the hope that non-programmers that are interested enough in information systems might get some value from that intro that, from a programmer's perspective, seems to be a "fish describing the water". I could be utterly wrong, though. - I'm interested in your take that calls come first, data comes afterwards. If you have something in writing about it (or want to post about it here), I'd gladly take a look. To me, I feel that you first have to have the chemical elements in order to later get the unicellular organisms. If data are the elements, the coming to life comes afterrwards. Then, you might reach a situation where most of the matter in an area is actually within live organisms, and it flows according to their own logic.

@Duncan Cragg - You've squarely earned an acknowledgment, in my eyes. You're the fourth human to give me feedback about TODIS! - I'm not stealing your work in Onex, yet. Now that you linked it and I know about it, I might 😄. But always giving due credit. And cell will be fully open source and public domain. - Concerning the fourfold mapping, amazing! It means we're seeing convergence; we were working separately on similar problems and are finding that we need the same things. To me, that's very healthy; it indicates the problem domain is not a solipsistic figment of individual imaginations, but something rather more objective. As for interface, I see it as an "interface maker", rather than i/o. But if you were referring to interfaces by i/o, then the mapping is 100% the same. - To me, number needs to be its own type, conceptually. The operations on them are very different from the ones we do on text. And I'm in love with the notion that from the two single data types (number and text) you can extend to the two multiple data types (list and hash), where numbers are the keys of list and texts are the keys of hash. It's just too elegant to pass up. Now, ask me in some time when I'm in the cauldron of implementation. But I'm a sucker for conceptual integrity. - Concerning null or undefined, I really don't want to add any values that are not part of the four base types. That's why I narrowed down on the empty text as my only null-like value. It's still a convention, which I like, because it gives others the possibility of picking something else, as long as they make it a value. The other thing I want to do concerning this (warning: vaporware) is to make references to nested objects that don't resolve to anything respond with an empty text, rather than throwing an error. Redis has this attitude towards structures that don't exist and I think it's the mother lode. - On declarative vs imperative, my contention is that you can put any operation in terms of a call, and that you can consider really anything as declarative or imperative (I know, bring the kindling and the stake, I'll even help you light it up). This is not a troll, though, I do mean it. Let's take a declarative call, like a SQL statement (is that a good example? If you have another one, please do send it to see if I can still make a point about it). Let's say that the SQL statement has some order required to it, but it's safe to say that you're not sending a search algorithm over the wire that the database will execute for you. Still, you're sending a message to a destination (that's what I consider a call, by the way). As a response, you obtain the result to your query. Is that declarative? It can be. But consider now me sending an opcode. I'm also sending a message (this time, to the CPU), saying that it should perform an operation. Now, am I telling the CPU how to organize its logic gates to achieve that result? Hardly. Whether the CPU uses complex logic, or microcode, I haven't specified. All I care about is that I get my response. The lack of ordering in what is normally considered a declarative call is simply a convention, in the same way that the order of arguments you send to an opcode is also a convention. It is a way to express what you want; the destination, which processes (expands) your call into a response, is in charge of that how. And even very declarative layers, like DSLs (including SQL) are actually quite structured in how they take their inputs. Even more unstructured/higher level paradigms (like LLMs) an still be seen in the call/response model. Does this make any sense?

- Clearly there's a difference between a SQL query and an opcode. The former is built with the latter. SQL is more high level than opcodes, but that doesn't preclude us from using the same model to describe each of these operations as calls, and to see all the commonalities between them (destination, message, response and expansion).

@Duncan Cragg I think that, like gender, applications make sense, but in a much more fluid and open way than traditionally conceived or expected. To me, an application is data plus logic for modifying that data, which are also data. The application lives in the dataspace. To what extent that data is public, or how modifiable by users is the logic that operates on the data, those are the axis along which we play. I wasn't aware of Substrates, thank you for bringing it to my attention! There's a lot there in common with what I'm thinking, particularly the notion of building affordances from data using data. I do see that from the same data, one might create different representations. This breaking of the 1:1 between data and a representation of it is key; from one part of the dataspace, multiple references and transformations are possible! @Kartik Agaram earlier brought Subtext to my attention (https://www.subtext-lang.org/OOPSLA05.pdf), which I wasn't aware of earlier. No worries about "stealing", I figured you were joking :D. And indeed, there's been quite a grab on the part of the big corporations; but by us working in public, I think that the balance of power can be tilted. I also just found out about Unit (https://github.com/samuelmtimbo/unit/tree/main) (thanks Kartik!) and his purpose is exactly the same one as mine: create systems that empower more people. The technical can also be political!

Further than Substrates, SOLID and Chris Gebhardt's InfoCentral that I mentioned, there's also @Guyren Howe’s FREST to compare to. And perhaps further out there's @Alexander Obenauer’s Itemized OS and even Victor's Dynamicland, all of which share a sense of data primacy and reactivity.

Also, I was hoping to see something like ID-able objects that could be seen on the internet via something like a URL. As I say: "Can we have a data object for °F and one for °C and the calculation as a third entity?" - so each with a unique ID? Otherwise, how will I fetch your temperature over a network? Also (sorry!) - in your call-response abstraction, a response can keep responding? (another way of asking if you have observer over the net thus can do spreadsheet-like dependencies over the net)

And finally ... 😄 what do you think about my chat example challenge?