Systems, not Programs

> While the Smalltalk model holds a large number of objects in a single ‘space’ - we could imagine a system where each object has internal space which holds a cluster of inner objects, and so on. This introduces a recursive aspect in the design.

Kind of reminds me of tuple spaces. Which is a neat idea. From the system vs program perspective, your system is running on this tuple space. Programs are individual actors capable of accessing the tuple space and triggered via some mechanism (like being notified if a certain type of data is posted or periodically executing a query and running if they receive a response). You can then grow the system by allowing tuples of different types to accumulate, and developing or extending actors in how they process this store.

https://en.wikipedia.org/wiki/Tuple_space

> The big difference is, you instrument a program, but you do not instrument a system.

We do instrument systems, consider strace or https://zipkin.io/

> A comparison would be a computer system is like a biological ecosystem.

Excellent analogy and one that I really like. What are the 'programs of biology'? One way of decomposing this is 'spacial' - e.g. a cell is a program, a limb or an organ is another larger one etc. But what about the nervous system, circulatory system, etc.? Aren't they useful perspectives but they span different units in the spacial decomposition. Can I view and modify them directly? What about updates - consider attaching another limb vs changing the electrical conductivity of neurons - while preserving some consistency and enforcing constraints.

Have you examined BeOS, really the BeFS portion, in the past?

It offered some of these kinds of things. A contact card could be a file system object with metadata, and you could query the file system not just for them but for all contact cards that had a phone number or AIM handle in the metadata. So if applications like your mail client and chat clients are aware of this they can use one common data store and just pull info from it in a similar manner. This breaks down the silo between applications that might use the same data and/or files.

Well since I've limited to 1 post a day here (very irritating!), this is it!

System dynamics is the name of the field. I studied it outside a CS curriculum as a "high-level" topic, but really I took to it like a duck to water because any good coder, does this. Its the difference between a "green" coder and an "experienced" coder. And it shows up in several of the maths/fields. Anywhere there is complexity, nonlinear feedback, and long delays in feedback, you get "emergent" system behavior.

I try and tell people, you can't oversimplify things, you can only stuff the complexity somewhere else. And when you adopt a framework, its a set of tradeoffs (on where it shoves the complexity). Beware, frameworks that "hide" where they shove the complexity (because it will always bite you in the ass). Sort of like poker, if you can't spot the mark (complexity);)

I hate to tell you this, but most people doing hiring for coders, have NO IDEA about this level of coding. They're just looking for cogs. How many times have you heard, "the system is so complex, no single person at the company understands it?"... inevitably followed by a series out catastrophic failures that are largely, systemic hazards.

Thats why there is such a large "framework adoption" movemen in CS. Not because the companies can't dev the software inhouse; but because they don't understand what they are missing. The mismatch between the "coder" and the "architect" (or worse where they've fetishized the divorce between system requirements and implementation). The whole CI is about trying to close the gap using functional testing and small code updates. But it doesn't work; you can't test for what you don't know (demand-specific instability)... So now you have to instrument the entire codebase just to make it run (or take out the particularization even further ala "containers").

More than anything, this makes the difference in the quality of the coder/codebase. If you have a good grasp of how things change, rather than static targets; you don't have to go through the entire morass. You just code it right the first time.

The other thing that really matters, is domain modeling (separate from system dynamics, which is actually implementation/environment specific). Knowing your problem well, and being able to correctly pin the context boundaries, is super critical.

Last is some control theory; that is, how to auto-remediate the problems as they develop. Believe it or not, you don't need large amounts of instrumentation, in order to do this. Good solutions, automatically trade-off in direct sensing of changes in algo. performance/inputs. They are "ROBUST".