Data and Procedures together

Transcript

Real Objects

Dr. Alan Kay explains when "object-oriented" was first used and what it means. [] (Meaning of "Object-Oriented Programming" According to Dr. Alan Kay (meaning of OOP objectoriented definition term notion meaning explanation what is)), document, page 721691 https://www.purl.org/stefan_ram/pub/doc_kay_oop_en (permalink) is the canonical URI of this page. Stefan Ram Dr. Alan Kay on the Meaning of “Object-Oriented Programming” E-Mail of 2003-07-23 Clarification of "object-oriented" [E-Mail] At 6:27 PM +0200 7/17/03, Stefan Ram wrote: I'm pretty sure I did. At Utah sometime after Nov 66 when, influenced by Sketchpad, Simula, the design for the ARPAnet, the Burroughs B5000, and my background in Biology and Mathematics, I thought of an architecture for programming. It was probably in 1967 when someone asked me what I was doing, and I said: "It's object-oriented programming". The original conception of it had the following parts. My original experiments with this architecture were done using a model I adapted from van Wijngaarten's and Wirth's "Generalization of Algol" and Wirth's Euler. Both of these were rather LISP-like but with a more conventional readable syntax. I didn't understand the monster LISP idea of tangible metalanguage then, but got kind of close with ideas about extensible languages draw from various sources, including Irons' IMP. The second phase of this was to finally understand LISP and then using this understanding to make much nicer and smaller and more powerful and more late bound understructures. Dave Fisher's thesis was done in "McCarthy" style and his ideas about extensible control structures were very helpful. Another big influence at this time was Carl Hewitt's PLANNER (which has never gotten the recognition it deserves, given how well and how earlier it was able to anticipate Prolog). The original Smalltalk at Xerox PARC came out of the above. The subsequent Smalltalk's are complained about in the end of the History chapter: they backslid towards Simula and did not replace the extension mechanisms with safer ones that were anywhere near as useful. What does "object-oriented [programming]" mean to you? (No tutorial-like introduction is needed, just a short explanation [like "programming with inheritance, polymorphism and encapsulation"] in terms of other concepts for a reader familiar with them, if possible. Also, it is not neccessary to explain "object", because I already have sources with your explanation of "object" from "Early History of Smalltalk".) (I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.) OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. Cheers, Alan E-Mail of 2003-07-26 Clarification of "object-oriented", 1 [E-Mail] Date: Sat, 26 Jul 2003 13:47:59 -0800 To: Stefan Ram [removed for privacy] From: Alan Kay [removed for privacy] Subject: Re: Clarification of "object-oriented" [some header lines removed for privacy] Content-Type: text/plain; charset="us-ascii" ; format="flowed" Content-Length: 3145 Lines: 68 One of the things I should have mentioned is that there were two main paths that were catalysed by Simula. The early one (just by accident) was the bio/net non-data-procedure route that I took. The other one, which came a little later as an object of study was abstract data types, and this got much more play. If we look at the whole history, we see that the proto-OOP stuff started with ADT, had a little fork towards what I called "objects" -- that led to Smalltalk, etc.,-- but after the little fork, the CS establishment pretty much did ADT and wanted to stick with the data-procedure paradigm. Historically, it's worth looking at the USAF Burroughs 220 file system (that I described in the Smalltalk history), the early work of Doug Ross at MIT (AED and earlier) in which he advocated embedding procedure pointers in data structures, Sketchpad (which had full polymorphism -- where e.g. the same offset in its data structure meant "display" and there would be a pointer to the appropriate routine for the type of object that structure represented, etc., and the Burroughs B5000, whose program reference tables were true "big objects" and contained pointers to both "data" and "procedures" but could often do the right thing if it was trying to go after data and found a procedure pointer. And the very first problems I solved with my early Utah stuff was the "disappearing of data" using only methods and objects. At the end of the 60s (I think) Bob Balzer wrote a pretty nifty paper called "Dataless Programming", and shortly thereafter John Reynolds wrote an equally nifty paper "Gedanken" (in 1970 I think) in which he showed that using the lamda expressions the right way would allow data to be abstracted by procedures. The people who liked objects as non-data were smaller in number, and included myself, Carl Hewitt, Dave Reed and a few others -- pretty much all of this group were from the ARPA community and were involved in one way or another with the design of ARPAnet->Internet in which the basic unit of computation was a whole computer. But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with "Remote Procedure Call" instead of thinking about objects and messages. Sic transit gloria mundi. Cheers, Alan At 10:05 PM +0200 7/26/03, Stefan Ram wrote: Remarks A memorandum on dataless programming: http://www.rand.org/pubs/research_memoranda/2007/RM5290.pdf Other Pages of this Site About this page Impressum | Form for messages to the publisher regarding this page | "ram@zedat.fu-berlin.de" (without the quotation marks) is the email-address of Stefan Ram. | Beginning at the start page often more information about the topics of this page can be found. (A link to the start page appears at the very top of this page.) Copyright 2004 Stefan Ram, Berlin. All rights reserved. This page is a publication by Stefan Ram. Stefan Ram Berlin slrprd slrprd stefanramberlin spellched stefanram721691 stefan_ram:721691 slrprd, slrprdqxx, slrprddoc, slrprd721691, slrprddef721691, PbclevtugFgrsnaEnz

What is OOP for Alan Kay

Object-oriented program and it's going to be the Paradigm of the future so what do I mean by objectorian program as I said before: I mean a brand new paradigm which is more in line with the Allen cave Vision so the first question in your mind who's Alan K and again I could bring this up in chat GPT and it come back with an answer but Alan K is the guy that invented the term object morning program and he and he he created the language called Small Talk he created another language called flax he worked for Atari Apple Walt Disney he was an imagineer at Walt Disney he was a fellow at Apple. I mean if I I couldn't feel smaller if I tried so this guy is a legend in Computing so what did Alan K mean by objectory program and he actually clarify that later on and I haven't got the exact date when he clarified it but he came back and I think it was in a mailing list that he said this he says object terminal programming means to me only messaging local retention protection hiding of State process and extreme late binding of all things and this is what we're gonna unpack because if we unpack this statement then it's got nothing to do with classes it's got certainly nothing to do with polymorphism it's certainly got nothing to do with abstraction it's certainly got nothing to do with inheritance and it's certainly got nothing to do with object-oriented programming is how we see it today and actually Alan K apologized in one of these uh mailing lists and he says I'm sorry that I long ago coined the term objects for this topic because it gets many people to focus on the Lesser idea big idea is messaging that is what the kernel of small talk squeak is all about and it was something that was never quite completed in our Xerox Park phase the Japanese have a small word ma for that which is in between perhaps the nearest English equivalent is interstitial key isn't making great and Global Systems is much more to design how its modules communicate rather than what their internal properties and behavior should be think of the internet to live it a has to allow many different kinds of ideas and realizations that are Beyond any single standard and B to allow varying degrees of safe interoperability between these ideas if you focus just on messaging and realize that a good meta system can late behind the various second level architectures used in objects then much of the

The big idea is "Messaging"

Folks -- Just a gentle reminder that I took some pains at the last OOPSLA to try to remind everyone that Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word -- ma -- for "that which is in between" -- perhaps the nearest English equivalent is "interstitial". The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas. If you focus on just messaging -- and realize that a good metasystem can late bind the various 2nd level architectures used in objects -- then much of the language-, UI-, and OS based discussions on this thread are really quite moot. This was why I complained at the last OOPSLA that -- whereas PARC we changed Smalltalk constantly, treating it always as a work in progress -- when ST hit the larger world, it was pretty much taken as "something just to be learned", as though it were Pascal or Algol. Smalltalk-80 never really was mutated into the next better versions of OO. Given the current low state of programming in general, I think this is a real mistake.

A Computer is a "Universal Atom of Meaning"

Source Master and Instances to Activities and Processes Alan Kay was a Mathematician and Microbiologist. He got inspired how Biologic Cells to make scalable systems: Multi-Processing and Scaling mean messaging! Concepts I got inspired with You can't go lower from a computer if you

Dynamic meanings, not static meanings

Source References AI people were the only ones thinking about Meaning. How to hold and reflect the larger meaning.

Semantic Negotiation

Thing that was going on in many different ways was trying to make things happen by matching patterns and doing transitions. So I'll just mention in 1958 system called comet for doing natural language parsing. One of my favorite Have you seen that? I was going to ask you a question about this paper. Well, yeah, I love this. Dan Engel said if you read that paper, it's a month of your life will vanish and it did. It's Yeah. because I implemented that. Yeah, everybody does. It's a test. Did I pass or fail? Yeah, you passed. No, but this is this is kind of a test for graduates. I was looking at that 10 minutes ago. I love this. This is just and it was done on an 8k byte, six bit bytes 1401. Yeah. So, I could ask about omea and meta too. Yes. Yes. So, so this is just a beautiful thing. It's basically uh you know the earliest thing of what is called uh pegs today programmable grammarss and there's just a lot of this is it in its own language that is all there is read to make itself it's so freaking cool isn't it it is it's Dan told me about it yeah so he told me not to read it because if I read because if I read it I would stop what I was working on and a light would vanish and it was completely What what's cool about this is besides this in here, he he also has the definitions of two other languages. He has a small alol and a fairly large alol. This paper is only about eight pages long with a couple of it's just the greatest little thing. And the thing that's great about this is it gets this is where the rubber hits the road because it is kind of the perfect compromise between all the theoretical stuff you might want to think about and what it actually means in some pragmatic thing. Hey, all I want to do is write a translator. I loved it because it was so efficient that you could think of it as an active interface language on objects. That isn't the way Val uh thought about it. Then I imp was is worthwhile looking at January 1970 of the communications of a ACM because irons was the guy who invented the syntax directed compiler and his interest was in doing languages where the procedural headers were actually the grammar of the of the syntax for that particular procedure. So you extended when you wrote a procedure you got to decide whether to use some standard way of doing it or or extending the language adding a new kind of control structure in there. uh that that work was mainly done in 1968. And then the amazing planner language which was really the uh affected uh prologue even though the prologue people say no but it did. Um and so two big hits out of the many here shows how messages can be parsed on the fly. just so cool and planner was powerful enough so its matching and the way you did matching could actually do negotiation and to me as a biologist doing something the size of the internet was going to be you can't you can't know exactly what you're going to call something at the other end of the internet. So there's going to have to be a looser binding that where meanings are negotiated just the way programmers would negotiate.

Biological Information Processing

Source

The Art of the Metaobject Protocol

Gregor Kiczales, Jim des Rivieres, and Daniel G. Bobrow The MIT Press Cambridge, Massachusetts London, England Acknowledgments Introduction The Problems We Faced Structure of the Book I Bibliography

Ideas on Systems

We want to control time We don't want a preferred center We want loose-coupled. I wanted to say something about systems, and three of the ideas here are that we want to control time. I mentioned this a little bit before: we do not want the CPU to control time. First, we want to control time, and we’ll do it by simulating our own time. We don’t want to have any preferred center, so we want to have something like the internet all the way down, and we want loose coupling. Now, of course, this has all been done before, again with networks, and here now we’re looking at physical computers on the internet or Ethernet. Ideally, we’d like our computations to be software versions of these hardware networks. Why? Because in most cases we will need to do load balancing. Sometimes we’ll be able to run all of these on a single machine, in which case we just have increased integrity and ability to design quickly, but a lot of the time—especially now with mobile—we want to have the same computations able to drift around the network to different kinds of devices. In some cases, not all of the computation is going to want to be in the machine that is next to the user interface. So if you think of the user interface here, it’s basically a set of views of processes that are giving it images to integrate up on the surface. Here’s a great thing: if you’re interested, read Dave Reed’s 1978 PhD thesis at MIT, The Design of an Operating System for the Internet. It was never done, but we validated it a few years ago at Viewpoints. So this is: if you want to make a system that is the size of the internet—a software system—what is it that you have to do to absolutely ensure that you’re going to have what people like to call data integrity always, so that no matter where you ask a question anywhere on the network about anything anywhere on the network, you will get the same answer for the pseudo-time referent of that question. A working version of a migratory system was done by Jerry Popek. I put this up here because this book was written in the 80s—you can still get it from MIT Press, The LOCUS Distributed System Architecture. You’ll find the entire book interesting—just a thin little volume—but the first two chapters are still a classic of the issues you have to think about and solve in order to do this. But again, this has all been done—this is almost 30 years old now—but nobody uses it. If you were to use it, all applications are now just mashups. We don’t want applications as smokestacks because we want to integrate. At Xerox PARC we didn’t have applications, and we did not have operating systems. The current web, which is getting more and more complicated, could immediately get simple—except for all the legacy stuff that has been done so far. Here’s something that Viewpoints has on its list, but we expect not to be able to solve this—at least in this path of doing things—and it may require a much larger effort than a small nonprofit can do. But if you think about analogies to what’s happening with the scaling that’s going on here, it basically starts looking like a biological ecology. These have their own dynamics, and they need to be thought about in special ways. So the ability for us to scale to what Moore’s Law is allowing right now is going to require us to start thinking more and more like this. We did this to some extent when we did the internet. I have a degree in molecular biology in my misspent youth, and a lot of the ways I think about this stuff is through tissue biology and how the hundred trillion cells in our body work without having a dedicated center and so forth. But in computing we have problems of our own that are special. The next step beyond this—the best book I’ve ever seen about it—is Minsky’s Society of Mind, which is actually about a model for human psychology, but in fact it is a very good model for what the internet is going to turn into. So the punchline here: we’ve got three main operating systems—I won’t say which one is the lemon—and down on the bottom here, our little Frankenstein monster that I’ve been showing you today is less than 20,000 lines of code. It’s worth pondering: we are not using any of the Macintosh software in order to do this demo. And here’s just to kick off—I think I’ll just show this thought and then quit. I organized the talk so I can stop at any place, but I’ll leave this one thought with you. Let’s think about this idea: something appears, and we’ve got two things about it that are very different—news and new. News is the stuff that is incremental to the categories that we already know. Almost every bit of news is a specific parameter into some category that we already understand. So it’s this war, that killing, this marriage, that—right? You can get quite a bit of this out in a few minutes. There’s almost no context to news that is not already inside our own head. “New,” on the other hand—real new—is invisible. We don’t have a category. McLuhan said, “Until I believe it, I can’t see it.” That’s the way it works in the human nervous system. So news is something that’s been going on for the entire existence of the human race—basically campfires. This is what we’re doing right now: a campfire. I’m doing the best I can in an hour of telling stories in a campfire. But the problem is, new can take two to five years to get the new categories that you need in order to actually see it. One of the unfortunate things that happens is that new, when you try to talk about it and people make an effort on it, usually gets transformed back into news. For instance, we did this as a way of boosting mankind—it was all about learning by doing—but in fact almost everybody in the world uses it only as a consumable device for their own convenience. I would spend twenty-eight thousand five hundred dollars, which is the price of an average American car, for a laptop if I could, because I know what computers are good for. But in fact people only value them about as much as they value their television sets, and they use them roughly the same way. So the big problem whenever something new comes along—like personal computing and the internet—is that when people see a convenience to themselves, they recast it back into the forms they already know. For instance, object-oriented programming never made it outside of Xerox PARC—only the term did. We got designer jeans, but designer jeans are just dungarees with a fancy label on them.

Alan Kay on Agents

How would this work? You feel that the computers of the next 10, 20 years, in addition to having the rich interfaces we have, will have personal agents as well? One of the ways I think about looking ahead into the future is to try and find analogies that might actually make some sense, and also to look for driving forces. One of the driving forces for the PARC-type user interface came just from there being inexpensive integrated circuits around. You start getting a proliferation of computers that are inexpensive enough for people to buy, and all of a sudden the kinds of people who might want to use computers changes completely. So all of a sudden you need a much easier-to-use user interface. There is a driving force now to do something, because it isn't just graduate students any more. To me, the driving force for agents is pervasive networking, because the techniques used on the Macintosh don't work well when you're connected up to a trillion objects scattered all over the world. You need something looking for potential objects that will further your own goals. And you need that something to be looking 24 hours a day. We think that what we'll have is 10, 15, 20 or more little agents, many of them not particularly intelligent, but able to flexibly take on a goal that we have. An example of one is an agent that goes out and finds you the newspaper you'd most like to read at breakfast every morning. All night long it works. It can touch dozens of different news sources, the Associated Press, New York Times and so forth, looking for things that are relevant to you. It can go to other sources for getting photographs and so forth. It can do the news gathering with a particular interest in the kinds of things that you have been involved in. A headline could say, "New fighting in Afghanistan," or it might say, "Your 3 o'clock meeting was cancelled today," because news now could involve your own electronic mail. The sidebar might say, "Your children slept well last night." This is an interesting example of an agent, because it's one that was built about ten years ago. It did not require a large amount of intelligence in order to work. Its major strength was its ability to work 24 hours a day while you weren't there. With a limited ability of doing matching against what you said you wanted and what it thought you wanted, it could do a great deal of useful work for you. [END OF TAPE F189] There have been a number of revolutions in the history of computers so far, but most people think of the computer as a standalone desktop object, right? Tying this in with your Dynabook concept, what you've been saying about networking and agents, where do you see the next thing taking us? The way I think about that is these three very different ways of relating the human to the computer. One is the institutional way of the time-sharing mainframe. One is the desktop way where you control all the stuff. The third way is the intimate way, which is the Dynabook way, which is continuously connected into the worldwide informational network.

Distributed Objects versus REST

source Alan Kay, Roy Fielding, and Growable Systems that Last for Decades Mike Amundsen, Director of Architecture - API Academy, CA Technologies <mca@amundsen.com> Tip This is a late draft of an article published by DevX in 2015. Introduction The Message Model of the WWW Distributing Objects Misses the Mark Passing Messages Scales the Web ‘OK, I Get the Message!’ 1. http://en.wikipedia.org/wiki/Object-oriented_programming 2. http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm 3. http://en.wikipedia.org/wiki/Alan_Kay 4. http://roy.gbiv.com/ 5. http://www.parc.com/about/ 6. http://isr.uci.edu/architecture/ 7. http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html 8. https://www.tele-task.de/archive/lecture/overview/5819/ 9. http://www.w3.org/History/1989/proposal.html 10. http://tools.ietf.org/html/rfc1945 11. http://en.wikipedia.org/wiki/Library_for_WWW_in_Perl 12. http://inkdroid.org/journal/2013/01/05/fielding-notes/ 13. http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_1 14. http://www.w3.org/History/1989/proposal.html 15. http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-742 16. http://c2.com/cgi/wiki?AlanKayOnMessaging 17. http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724 Last updated 2022-07-22 10:19:29 EDT

Constraint Programming

Source: Seminar with Alan Kay on Object Oriented Programming (VPRI 0246) We are going from a procedural style, which controls past explicitly around, to a declarative style in which we are simply indicating needs, and the system, without having to do any problem solving, is picking up the slack by providing the actual information in the form of a message. Hypercard has this about halfway. It's a technique that we have been experimenting with at Apple. What it looks like it's able to do is to completely remove the necessity for actually being able to follow a control flow. What does it mean when we move an object from one place to another? When you move an object from some place into this kind of situation, nothing is going to happen to the object unless you recode some other object. The modularity of being able to move an object from one place to another depends on me being able to do some kind of modification and the system is already there that's not so good it's good in the sense that this object is guaranteed not to hurt anybody and it's going to protect its own self from being moving moved around but in fact I still to go in and make some sort of modification to control the flow. When I put a new blue guy here and he has all his need specified is he going to be able to run? Yes because he is not intertwined with anybody else's control. He's simply saying I know what I need! God damn it! The question is if the system is able to deliver those needs just because he is a new thing and the answer seems to be yes.

Multi-agent is actor model

Forwarded this email? Subscribe here for more Agents are actors Multi-agent is actor model Gordon Brander Apr 20 How should AI agents cooperate? What should a multi-agent system look like? Everyone is trying to figure this out right now. Should our agents be thought of as a team that coordinates over an issue tracker? Are they more like a swarm of bees or ants? Should they be arranged into command-and-control hierarchies of agent and sub-agent? Or should we trust the bitter lesson and bet on one big model? Here’s my take: Agents are actors. Multi-agent is just the actor model. An actor… That sounds a lot like an agent! An agent receives a user message, it updates its context, it may spawn other agents, and generate messages in response. It also sounds a lot like Von Foerster’s non-trivial machine, a cybernetic model of the minimal system that can generate agentic behavior: a function that accumulates state through feedback (aka, a reducer). The Non-Trivial Machine, a function with feedback. The minimal definition of agency. Source: Heinz von Foerster, “Understanding Understanding: Essays on Cybernetics and Cognition”. Wassily Kandinsky, 1938, “Entassement réglé” If each agent is a cell, how can we make the jump to multicellularity? OOP never properly made this jump, and it never attained the sublime levels of biological complexity that Kay envisioned. This is because mainstream OOP languages had fatal design mistakes that broke compositionality. Actors fix this. There are multiple formal mathematical models that let us reason about actor composition at scale. To scale up our multi-agent systems, we could borrow some ground rules from actors: These qualities make it very easy to parallelize actors. You don’t have any of the problems of shared mutable state, because there is no shared mutable state. The system can scale horizontally, from one process to many, and from one computer to many. Designing our agents as actors lets us spin up lots of parallel agents. Now what? How should these swarms of agents interact and be structured? Here too, the actor model offers useful patterns: This is just a sample of the patterns that emerge naturally from the actor model. It is pretty easy to imagine how they might be useful in a multi-agent system. Some of them are already common: scatter-gather is used for Claude Code’s Explore agents, and prompt resolvers are a riff on the become pattern. Actor agents could allow us to run hundreds of parallel agents on a computer, or thousands across load-balanced servers, or even millions of agents across the whole internet. With location transparency, “Have your agent call my agent” and “have your factory call my factory” become essentially the same move. Furthermore, if every agent signs its messages with a public key, we get a decentralized protocol for massively multi-agent systems. Signed messages give us the basis for untrusted coordination between agents. Because signed messages are non-repudiable, we can begin to accrue cryptographically-verifiable reputations for specific agents, and distribute those reputations through webs of trust. Our agents can decide whether to interact with another agent based on the agent’s reputation. It is also pretty easy to imagine how we might extend such a decentralized agent protocol to enable end-to-end encrypted communication between agents. In the actor model, actors send messages directly to other actors using an address, so just encrypt the message, and send directly to the other agent’s address. The implementation for such a protocol could be very simple. Sign JSON with an agent-controlled key, send it over the wire. For the details, I would be inclined to borrow from Nostr for message signing, ATProto for DID-based signing and key rotation, and UCAN for delegating authority from user to agent to sub-agent. But in many ways, this protocol problem is simpler than the problem of decentralizing social media. Actor communication is point-to-point, rather than broadcast, so it’s a good fit for HTTP. In its most basic incarnation, an agent could be a URL, its address could be a POST request to that URL, and messages could be signed with a JWT. Reflecting on this, I feel like I can begin to see the shape of a new internet, something that may supersede the web: the internet of agents.

A Sea of Messages

A scalable Internet of Distributed Objects

Internalize its own local pointers to any object in the world

Source What that means is they're going to be dozens and dozens they're almost already are dozens and dozens of different object systems all with very similar semantics but with very different pragmatic details and if you think of what a URL actually is and you think of what an HTTP message actually is and if you think of what an object actually is and if you think of what an object-oriented pointer actually is I think it should be pretty clear that any object-oriented language can internalize its own local pointers to any object in the world regardless of where it was made that's the whole point of not being able to see inside and so a semantic interoperability is possible almost immediately by simply taking that stance so this is gonna change really everything and things like Java beans and CORBA are not going to are not going to suffice because at some point one is going to have to start really discovering what objects think they can do and this is going to lead to a universal interface language which is not a programming language per se it's more like a prototyping language but that allows an interchange of deep information about what objects think they can do allows objects to make experiments with other objects in a safe way to see how they respond to various messages this is going to be a critical thing to automate in the next 10 years.

An Integrated Experimental Environment for Distributed Systems and Networks

The 2002 Netbed/Emulab paper presenting an integrated virtual-machine-like testbed for simulation, emulation, and live distributed-systems experimentation.