Thank you for taking the time to respond, and I'd really appreciate if you can clarify my follow up below too!
> every thing in the system is a dynamic object -- there are no "date structures"
I'm still programming in data structures :/. I've seen many of your talks over the years and it took me quite a while to realize what you mean by objects (I think) is not just the textual specification (i.e. 'source code' in today's world), but rather a live, run-able thing that can be probed, inspected and made to do its thing, all by sending messages to it. In the Unix world this would be more akin to a long running server process, but with a much better unified, discover-able IPC mechanism (i.e. 'messaging'). The only thing that needs to be standardized here is the messaging mechanism itself. Larger processes would be constructed by just hooking up existing objects. Automatic persistence would mean these objects don't need to extract and store 'just data' outside themselves, etc.
This model blurs the distinction between what today we call 'programming' (writing large gobs of text), what we call 'operations' (configuring and deploying programs), and what we call 'using' (e.g. reviewing, organizing my photos). Instead, for every case, I would be doing the same kind of operation - i.e. inspecting and hooking up objects - but the objects I'm working with would be different, and the UI could be different. This makes programming more interactive ('let me see if this object can talk to that object by actually connecting them' vs. 'let me see if I can write a large blob of text that satisfies the compiler, by simulating the computer in my head').
The other thing I notice is you don't slice the computation the same way that is so common today. E.g. today I write source code (form #1 of computation), which runs through a compiler to produce an executable file (form #2 of the same computation), which is then executed and loaded in memory (form #3, because now it merges with the data from outside itself). Form #1 is checked in to source control, form #2 is bundled for distribution and form #3 is rather transient.
Instead, you're slicing computation on a different axis and all forms of the same computation are kept together - i.e. the specification, executable and runtime forms are one and the same 'object'. The decomposition happens by breaking down along functional boundaries. This means modification of the specification can happen anywhere I encounter one of these live objects, right then and there. I don't have to trace the computation to its 'source'.
So my main question is - am I on the right track here?
> Going back and doing Engelbart or Parc also makes no sense
I agree, but given the sad state of composition, even if we had some of those ideas today, it would seem like a step forward :) IMO, today we want to think of farms of computers as one large computer, and instead of programming in the small, we want to program all of them together.
> every thing in the system is a dynamic object -- there are no "date structures"
I'm still programming in data structures :/. I've seen many of your talks over the years and it took me quite a while to realize what you mean by objects (I think) is not just the textual specification (i.e. 'source code' in today's world), but rather a live, run-able thing that can be probed, inspected and made to do its thing, all by sending messages to it. In the Unix world this would be more akin to a long running server process, but with a much better unified, discover-able IPC mechanism (i.e. 'messaging'). The only thing that needs to be standardized here is the messaging mechanism itself. Larger processes would be constructed by just hooking up existing objects. Automatic persistence would mean these objects don't need to extract and store 'just data' outside themselves, etc.
This model blurs the distinction between what today we call 'programming' (writing large gobs of text), what we call 'operations' (configuring and deploying programs), and what we call 'using' (e.g. reviewing, organizing my photos). Instead, for every case, I would be doing the same kind of operation - i.e. inspecting and hooking up objects - but the objects I'm working with would be different, and the UI could be different. This makes programming more interactive ('let me see if this object can talk to that object by actually connecting them' vs. 'let me see if I can write a large blob of text that satisfies the compiler, by simulating the computer in my head').
The other thing I notice is you don't slice the computation the same way that is so common today. E.g. today I write source code (form #1 of computation), which runs through a compiler to produce an executable file (form #2 of the same computation), which is then executed and loaded in memory (form #3, because now it merges with the data from outside itself). Form #1 is checked in to source control, form #2 is bundled for distribution and form #3 is rather transient.
Instead, you're slicing computation on a different axis and all forms of the same computation are kept together - i.e. the specification, executable and runtime forms are one and the same 'object'. The decomposition happens by breaking down along functional boundaries. This means modification of the specification can happen anywhere I encounter one of these live objects, right then and there. I don't have to trace the computation to its 'source'.
So my main question is - am I on the right track here?
> Going back and doing Engelbart or Parc also makes no sense
I agree, but given the sad state of composition, even if we had some of those ideas today, it would seem like a step forward :) IMO, today we want to think of farms of computers as one large computer, and instead of programming in the small, we want to program all of them together.