11 ms·

My reason for drawing your attention to this section of the talk is to show some of the ideas (now 40-50 year old) were about "dynamic media" - of course live c

My reason for drawing your attention to this section of the talk is to show some of the ideas (now 40-50 year old) were about "dynamic media" - of course live computing should be part of the combined media experience on a personal computer -- and of course you should be able to do what are now called "mash ups", but to be able to combine useful things easily and at will (it's crazy that this e.g. isn't even provided for maps in a general way on smartphones, tablets and PCs). But the larger point here is that if one is dealing with dynamic objects as originally intended, the objects can help greatly and safely in coordinating them. This shouldn't be more difficult than what we do in combining ordinary materials in our physical world (it should be even simpler!). In the system used for the demo -- Smalltalk-78 -- every thing in the system is a dynamic object -- there are no "date structures". This means in part that each object, besides doing its main purpose, can also provide useful help in using it, can include general protocols for "mashing up", etc. We can do better today, but my whole point in the interview and in these comments is that once e.g. Engelbart showed us great ideas for personal computing, we should not adopt worse ideas (why would any reasonable people do this?), once dynamic media has been demonstrated in a comprehensive way, we should not go back to imitating static media in ways that preclude dynamic media (if you have dynamic media you can do static media but not vice versa!). Going back and doing Engelbart or Parc also makes no sense, because we have vastly more computing resources today than 50 years ago. We need to go forward -- and -to think things through- ! -- about what computers are, what we are, and how to use the best of both in powerful combinations. This was Licklider's dream from 1960, and some of it was built. The dream is still central to our thinking today because it was so large and good to be always beckoning us ahead.

shalabhc 9y ago
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.
- alankay1 9y ago
  Yes, you have the gist of our approach in the 60s and especially at Parc in the 70s. And the Doug McIlroy parts of Unix also got this (the "pipes" programming and other ideas). What I called "objects" ca 1966 was a takeoff from Simula and Sketchpad that was highly influenced by both biology, by the "processes" (a kind of virtual computer) that were starting to be manifested by time-sharing systems, and by my research community's discussions and goals for doing an "ARPAnet" of distributed computers. If you took the basic elements to be "computers in communication" you could easily get the semantics of everything else (even to simulate data structures if you still thought you needed them). So, yes, everything could be thought of as "servers". Smalltalk at Parc was entirely structured this way (and the demo I made from one of the Parc Smalltalks for the Ted Nelson tribute shows examples of this). It's worth noting that you then have made a "software Internet", and this can be mapped in many ways over a physical Internet. And so forth. This got quite missed. In a later interview Steve said that he missed a bunch of things from his visit to Parc in 1979. What was ironic was that the context of the interview was partly that the SW of the NEXT computer now did have these (in fact, not really). To be a bit more fair, big culprits in the miss in the 80s were Motorola and Intel for not making IC CPUs with Chuck Thacker's emulation architectures that we used at Parc to be able run ultra high level languages efficiently enough. The other big culprit was that you could do -something- and sell it for a few thousand dollars, whereas what was needed was something whose price tag in the early 80s would have been more like $10K. Note that a final culprit here is that the personal computer could not be seen for all it really was, and especially in the upcoming lives of most people. The average price of a car when the Mac came out was about $9K (that according to the web is about $20K today -- the average price of a car today is about $28K). To me a really good personal computer is worth every penny of $28K -- I'd love to be able to buy $28K of personal computer! One way to evaluate "the computer revolution" is to note not just what most people do with their computers in all forms, but what they are willing to pay. I think it will be a while before most people can see enough to put at least the value of a car on their "information and thinking amplifier vehicle"
  - shalabhc 9y ago
    > It's worth noting that you then have made a "software Internet", and this can be mapped in many ways over a physical Internet. The more interesting/optimized ways to map this would be where a single object in the software internet somehow maps to multiple computers, either doing parallel computation or partitioned computation on each. I feel the semantics of mapping the object onto a physical computer would have to be encoded in the object itself. Perhaps some other kinds of higher level semantic model (i.e. not a 'software internet') might also be easy to map onto a physical internet. This is something I am interested in actively exploring. That is, how to build semantic models that are optimized for human comprehension of a problem, but can be directly run on farms of physical computers? Today a lot of the translation is done in our heads - all the way down to a fairly low level. > big culprits in the miss in the 80s were Motorola and Intel for not making IC CPUs with Chuck Thacker's emulation architectures Maybe there is a feedback loop where the growth of Unix leads to hardware vendors thinking 'lets optimize for C', which then feeds the growth further? OTOH, even emulated machines are faster than hardware machines used to be. > I'd love to be able to buy $28K of personal computer! Well, you can already buy $28K or more of computing resources and connect it to your personal device. It's not easy to get much value from this today, though.

shalabhc 9y ago

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.

alankay1 9y ago
Yes, you have the gist of our approach in the 60s and especially at Parc in the 70s. And the Doug McIlroy parts of Unix also got this (the "pipes" programming and other ideas). What I called "objects" ca 1966 was a takeoff from Simula and Sketchpad that was highly influenced by both biology, by the "processes" (a kind of virtual computer) that were starting to be manifested by time-sharing systems, and by my research community's discussions and goals for doing an "ARPAnet" of distributed computers. If you took the basic elements to be "computers in communication" you could easily get the semantics of everything else (even to simulate data structures if you still thought you needed them). So, yes, everything could be thought of as "servers". Smalltalk at Parc was entirely structured this way (and the demo I made from one of the Parc Smalltalks for the Ted Nelson tribute shows examples of this). It's worth noting that you then have made a "software Internet", and this can be mapped in many ways over a physical Internet. And so forth. This got quite missed. In a later interview Steve said that he missed a bunch of things from his visit to Parc in 1979. What was ironic was that the context of the interview was partly that the SW of the NEXT computer now did have these (in fact, not really). To be a bit more fair, big culprits in the miss in the 80s were Motorola and Intel for not making IC CPUs with Chuck Thacker's emulation architectures that we used at Parc to be able run ultra high level languages efficiently enough. The other big culprit was that you could do -something- and sell it for a few thousand dollars, whereas what was needed was something whose price tag in the early 80s would have been more like $10K. Note that a final culprit here is that the personal computer could not be seen for all it really was, and especially in the upcoming lives of most people. The average price of a car when the Mac came out was about $9K (that according to the web is about $20K today -- the average price of a car today is about $28K). To me a really good personal computer is worth every penny of $28K -- I'd love to be able to buy $28K of personal computer! One way to evaluate "the computer revolution" is to note not just what most people do with their computers in all forms, but what they are willing to pay. I think it will be a while before most people can see enough to put at least the value of a car on their "information and thinking amplifier vehicle"
- shalabhc 9y ago
  > It's worth noting that you then have made a "software Internet", and this can be mapped in many ways over a physical Internet. The more interesting/optimized ways to map this would be where a single object in the software internet somehow maps to multiple computers, either doing parallel computation or partitioned computation on each. I feel the semantics of mapping the object onto a physical computer would have to be encoded in the object itself. Perhaps some other kinds of higher level semantic model (i.e. not a 'software internet') might also be easy to map onto a physical internet. This is something I am interested in actively exploring. That is, how to build semantic models that are optimized for human comprehension of a problem, but can be directly run on farms of physical computers? Today a lot of the translation is done in our heads - all the way down to a fairly low level. > big culprits in the miss in the 80s were Motorola and Intel for not making IC CPUs with Chuck Thacker's emulation architectures Maybe there is a feedback loop where the growth of Unix leads to hardware vendors thinking 'lets optimize for C', which then feeds the growth further? OTOH, even emulated machines are faster than hardware machines used to be. > I'd love to be able to buy $28K of personal computer! Well, you can already buy $28K or more of computing resources and connect it to your personal device. It's not easy to get much value from this today, though.