> 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.
"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."
You might be interested in Alan Kay's '97 OOPSLA presentation. He talked in a similar vein to what you're talking about: https://youtu.be/oKg1hTOQXoY?t=26m45s
I only got that far with it, because I realized once I did it that I had more work to do in understanding what to do with what I got back (mainly translating it into something that would keep with the beauty of what I had started)...
"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."
There is a feedback loop to it, though as development platforms change, that feedback gets somewhat attenuated.
As I recall, what you describe with C happened, but it began in the late '90s, and into the 2000s. I started hearing about CPUs being optimized to run C faster at that point.
I once got into an argument with someone on Quora about this re. "If Lisp is so great, why aren't more people using it?" I used Kay's point about how bad processor designs were partly to blame for that, because a large part of why programmers make their choices has to do with tradition (this gets translated to "familiarity"). Lisp and Smalltalk did not run well on the early microprocessors produced by these companies in the 1970s. As a consequence, programmers did not see them as viable for anything other than CS research, and higher-end computing (minicomputers).
A counter to this was the invention of Lisp machines, with processors designed to run Lisp more optimally. A couple companies got started in the '70s to produce them, and they lasted into the early '90s. One of these companies, Symbolics, found a niche in producing high-end computer graphics systems. The catch, as far as developer adoption went, was these systems were more expensive than your typical microcomputer, and their system stuff (the design of their processors, and system software) was not "free as in beer." Unix was distributed for free by AT&T for about 12 years. Once AT&T's long-distance monopoly was broken up, they started charging a licensing fee for it. Unix eventually ran reasonably well on the more popular microprocessors, but I think it's safe to say this was because the processors got faster at what they did, not that they were optimized for C. This effect eventually occurred for Lisp as well by the early '90s, which is one reason the Lisp machines died out. A second cause for their demise was the "AI winter" that started in the late '80s. However, by then, the "tradition" of using C, and later C++ for programming most commercial systems had been set in the marketplace.
The pattern that seems to repeat is that languages become popular because of the platforms they "rode in on," or at least that's the perception. C came on the coattails of Unix. C++ seems to have done this as well. This is the reason Java looks the way it does. It came out of this mindset. It was marketed as "the language for the internet," and it's piggybacked on C++ for its syntax and language features. At the time the internet started becoming popular, Unix was seen as the OS platform on which it ran (which had a lot of truth to it). However, a factor that had to be considered when running software for Unix was portability, since even though there were Unix standards, every Unix system had some differences. C was reasonably portable between them, if you were careful in your implementation, basically sticking to POSIX-compliant libraries. C++ was not so much, because different systems had C++ compilers that only implemented different subsets of the language specification well, and didn't implement some features at all. C++ was used for a time in building early internet services (combined with Perl, which also "rode in" on Unix). Java was seen as a pragmatic improvement on C++ among software engineers, because, "It has one implementation, but it runs on multiple OSes. It has all of the familiarity, better portability, better security features, with none of the hassles." However, it completely gave up on the purpose of C++ (at the time), which was to be a macro language on top of C in a similar way to how Simula was a macro language on top of Algol. Despite this, it kept C++'s overall architectural scheme, because that's what programmers thought was what you used for "serious work."
From a "power" perspective, one has to wonder why programmers, when looking at the prospect of putting services online, didn't look at the programming architecture, since they could see some problems with it pretty early, and say to themselves, "We need something a lot better"? Well, this is because most programmers don't think about what they're really dealing with, and modeling it in the most comprehensive way they can, because that's not a concept in their heads. Going back to my first point about hardware, for many years, the hardware they chose didn't give them the power so they could have the possibility to think about that. As a result, programmers mostly think about traits, and the community that binds them together. That gives them a sense of feeling supported in their endeavors, scaling out the pragmatic implementation details, because they at least know they can't deal with that on their own. Most didn't think to ask (including myself at the time), "Well, gee. We have these systems on the internet. They all have different implementation details, yet it all works the same between systems, even as the systems change... Why don't we model that, if for no other reason than we're targeting the internet, anyway? Why not try to make our software work like that?"
On one level, the way developers behave is tribal. Looked at another way, it's mercantilistic. If there's a feedback loop, that's it.
"OTOH, even emulated machines are faster than hardware machines used to be."
What Kay is talking about is that the Alto didn't implement a hard-coded processor. It was soft-microcoded. You could load instructions for the processor itself to run on, and then load your system software on top of that. This enabled them to make decisions like, "My process runs less efficiently when the processor runs my code this way. I can change it to this, and make it run faster."
This will explain Kay's use of the term "emulated." I didn't know this until a couple years ago, but at first, they programmed Smalltalk on a Data General Nova minicomputer. When they brought Smalltalk to the Alto, they microcoded the Alto so that it could run Nova machine code. So, it sounds like they could just transfer the Smalltalk VM binary to the Alto, and run it. Presumably, they could even transfer the BCPL compiler they were using to the Alto, and compile versions of Smalltalk with that. The point being, though, that they could optimize performance of their software by tuning the Alto's processor to what they needed. That's what he said was missing from the early microprocessors. You couldn't add or change operators, and you couldn't change how they were implemented.
Actually ... only the first version of Smalltalk was done in terms of the NOVA (and not using BCPL). The subsequent versions (Smalltalk-76 on) were done by making a custom virtual machine in the Alto's microcode that could run Smalltalk's byte codes efficiently.
The basic idea is that you can win if the microcode cycles are enough faster than the main memory cycles so that the emulations are always waiting on main memory. This was generally the case on the Alto and Dorado. Intel could have made the "Harvard" 1st level caches large enough to accommodate an emulator -- that would have made a big difference. (This was a moot point in the 80s)
I know this is getting nit-picky, but I think people might be interested in getting some of the details in the history of how Smalltalk developed. Dan Ingalls said in "Smalltalk-80: Bits of History":
"The very first Smalltalk evaluator was a thousand-line BASIC program which first evaluated 3 + 4 in October 1972. It was followed in two months by a Nova assembly code implementation which became known as the Smalltalk-72 system."
The first Altos were produced, if I have this right, in 1973.
I was surprised when I first encountered Ingalls's implementation of an Alto on the web, running Smalltalk-72, because the first thing I was presented with was, "Lively Web Nova emulator", and I had to hit a button labeled "Show Smalltalk" to see the environment. He said what I saw was Nova machine code from a genuine ST-72 image, from an original disk platter.
I take it from your comment that you're saying by the time ST-76 was developed, the Alto hardware had become fast enough that you were able to significantly reduce your use of machine code, and run bytecode directly at the hardware level.
I could've sworn Ingalls said something about using BCPL for earlier versions of Smalltalk, but quoting out of "Bits of History" again, Ingalls, when writing about the Dorado and Smalltalk-80, said of BCPL that the compiler you were using compiled to Alto code, but ...
"As it turned out, we only used Bcpl for initialization, since it could not generate our extended Alto instructions and since its subroutine calling sequence is less efficient than a hand-coded one by a factor of about 3."
The Alto didn't get any faster, and there was not a lot of superfast microcode RAM (if we'd had more it would have made a huge difference). In the beginning we just got Smalltalk-72 going in the NOVA emulator. Then we used the microcode for a variety of real-time graphics and music (2.5 D halftone animation, and several kinds of polytimbral timbre synthesis including 2 keyboards and pedal organ). These were separate demos because both wouldn't fit in the microcode. Then Dan did "Bitblt" in microcode which was a universal screen painting primitive (the ancestor of all others). Then we finally did the byte-code emulator for Smalltalk-76. The last two fit in microcode, but the music and the 2.5 D real-time graphics didn't.
The Notetaker Smalltalk (-78) was a kind of sweet spot in that it was completely in Smalltalk except for 6K bytes of machine code. This was the one we brought to life for the Ted Nelson tribute.
Thanks for the long write up. I found it very interesting.
> You might be interested in Alan Kay's '97 OOPSLA presentation
Oh yeah I have actually seen that - probably time to watch it again.
> Well, this is because most programmers don't think about what they're really dealing with
Agree with that. Most people are working on the 'problem at hand' using the current frame of context and ideas and focus on cleverness, optimization or throughput within this framework. When changing the frame of context may in fact be much better.
> What Kay is talking about is that the Alto didn't implement a hard-coded processor. It was soft-microcoded.
Interesting. I wonder if FPGAs could be used for something similar - i.e. program the FPGAs to run your bytecode directly. But I'm speculating because I don't know too much about FPGAs.
Yes re: FPGAs -- they are definitely the modern placeholder of microcode (and better because you can organize how the computation and state are hooked together). The old culprit -- Intel -- is now offering hybrid chips with both an ARM and a good size patch of FPGA -- combine this with a decent memory architecture (in many ways the hidden barrier these days) and this is a pretty good basis for comprehensive new designs.
> The more interesting/optimized ways to map this would be where a single object in the software internet somehow maps to multiple computers ...
Yes, this is the essence of Dave Reed's 1978 MIT thesis on the design of a distributed OS for the Internet of "consistent" objects mapped to multiple computers. In the early 2000s we had the opportunity to test this design by implementing it. This led to a series of systems called "Croquet" and an open source system and foundation called "Open Cobalt".
> how to build semantic models that are optimized for human comprehension of a problem, but can be directly run on farms of physical computers?
This is still kind of a mishmash of early thoughts and I have a couple of different lines of thought, which I hope will come together. I'll start with a couple of observations:
1. Most programming languages and DSLs are uni-directional - the computer doesn't talk back to the human in the same language.
2. The mental models (not the language) humans use to communicate to each other, even when using a lot of rigor and few ambiguities, is often different than the languages and models used for computation.
The first idea is: there are some repeating structures in mental models. We think new concepts in terms of old by first thinking the structures (which are few and axiomatic, like the structure/function words in English) and then materializing the content, as well as refining the structures. E.g. I can say to a non-programmer that 'classes contain methods' and they kind of get the structure without knowing the content. In my mind this is represented as a graph, where the 'contains' relationship is an edge that connects two 'content nodes'.
[something called class] --(contains)-> [something called method]
If I follow up with 'methods contain code', they can reason that classes indirectly contain code, without even knowing what these things actually mean! So 'contains' is kind of a universal concept - it applies to abstract content and physical content in a similar way. Another universal connection is 'abstraction of', this implies one node (the abstract thing) is related to other nodes (the concrete things) in a specific way.
Maybe structures can be made composable, and we can operate on graphs structurally, without knowing what the content means? While another operation might eventually figure out what the content means. The main assumption here is my thoughts are organized as graphs, where connections are both universal also domain specific but of few kinds. Can I talk to the computer in terms of such graphs?
The second idea is: I want to combine high level concepts and strategies from from somewhat different domains. E.g. if I know different strategies for 'distributing things into bins' (consistent hashing, sharding, etc.), I invoke this 'idea' manually whenever I have see a situation which looks like 'distribute things into bins' and make a choice - irrespective of scale. Can I get the computer to do this for me instead?
So the final thing here is to get to something like this: I take an idea (i.e. a node in a graph) from the distributed computing domain, merge it with a definition (another node) of a computation I created (e.g. persistence strategies), and have the computer offer options on how to distribute that computation (i.e. 'distributed persistence strategies'). Then I can make choices and combine it with a 'convert idea to machine code' strategy and generate a program. This is all a bit abstract at this point, but I'm also trying to find where this overlaps with prior art.
A clarifying comment here. When one thinks in terms of what I called objects ca 1966, one is talking about entities that from the outside are identical to what we think of as computers (and this means not just sending messages and getting outputs, but that we don't get to look inside with our messages, and our messages don't get to command, unless whatever is going on in the interior of the computer has decided to allow.
So from the outside, there are no imperatives, only requests and questions. Another way to look at this is that an object/computer is a kind of "server" (I worry to use this term because it also has "pop" meanings, but it's a good term.)
This is sometimes called "total encapsulation".
From this standpoint, we don't know what's inside. Could be just hardware. Could be variables and methods. Could be some form of ontology. Or mix and match.
This is the meaning of computers on a network, especially large worldwide ones.
The basic idea of "objects" is that what is absolutely needed for doing things at large scale, can be supplied in non-complex terms for also doing the small scale things that used to be done with data structures and procedures. Secondarily, some of the problems of data structures and procedures at any scale can be done away with by going to the "universal servers in systems" ideas.
Similarly, what we have to do for critical "data structures" -- such as large scalings, "atomic transactions", versions, redundancy, distribution, backup, and "procedural fields" (such as the attribute "age") are all more easily and cleanly dealt with using the idea of "objects".
One of the ways of looking at what happened in programming is that many if not most of the naive ways to deal with things when computers were really small did not scale up, but most programmers wanted to stay with the original methods, and they taught next gen programmers the original methods, and created large fragile bodies of legacy code that requires experts in the old methods to maintain, fix, extend ...
> So from the outside, there are no imperatives, only requests and questions.
This threw me off a bit as Smalltalk collections have imperative style messages for instance.
> Could be some form of ontology.
This remark helped me find some clarity.
I want the computer to help me do cross ontological reasoning and mapping. For instance, if I want to compute geometry, how do I map the ontology of 'geometry' onto the ontology of 'smalltalk'? I 'think up' the mapping, but it would be great if the computer helps me here too. Mapping 'smalltalk' onto 'physical machines' is another ontological mapping. The 'mapping of ontologies' is itself an ontology.
In large systems there are a lot of ontological 'views' and 'mappings' at play. I want to inspect and tweak each independently using the language on the ontology, and have the computers automatically map my requests to the physical layer in an efficient way. This is not possible in systems today because there an incredible amount of pre-translation that happens so a high level questions cannot be directly answered by the system - I have to track it down manually to a different level.
Maybe the answer is to define the ontologies as object collections and have them talk to each other and figure it out. I want to tweak things after the system is up, of course, so I could send an appropriate message (e.g. 'change the bit representation of integers' or 'change the strategy used in mapping virtual objects to physical') and everything affected would be updated automatically (is this 'extreme late binding'?).
Yes, "collections" and other such things in Smalltalk are "the Christian Scientists with appendicitis". Our implementations were definitely compromises between seeing how to be non-imperative vs already having the "devil's knowledge" of imperative programming. One of the notions we had about objects is that if we had to do something ugly because we didn't have a better idea, then we could at least hide it behind the encapsulation and the fact that message sending in the Smalltalks really is a request.
Another way of looking at this is if an "object" has a "setter" that directly affects a variable inside then you don't have a real object! You've got a data structure however much in disguise.
Another place where the "sweet theory" was not carried into reality was in dependencies of various kinds. Only some important dependencies were mitigated by the actual Smalltalks.
Two things that helped us were that we did many on the fly changes to the system over 8-10 years -- about 80 system releases -- and including a new language every two years. This allowed to avoid getting completely gobbed up.
The best and largest practical attempt at an ontology is in Doug Lenat's CYC. The history of this is interesting and required a number of quite different designs and implementations to gather understanding.
One of the things I've realized is that using names for locating what's needed (I assume we're talking about the same idea) is part of the problem. At small scales it's fine. As systems get bigger, it becomes a problem. The internet went through this. When it started as the Arpanet, there was (if I remember correctly) one guy who kept the directory of names for each system on the network. The network started small, so this could work. As it grew into the thousands of nodes, this became less manageable, partly because there started to be duplicate requests for the same name for different nodes--naming conflicts, which is why DNS was created, and why ICANN was ultimately created, to settle who got to use which names. I doubt something like that, though, would scale properly for code, though many organizations have tried that, by having software architects in charge of assigning names to entities within programs. The problem then comes when companies/organizations try to link their systems together to work more or less cooperatively. I heard despondent software engineers talk about this 15 years ago, saying, "This is our generation's Vietnam." (They didn't lack for the ability to exaggerate, but the point was they could not "win" with this strategy.) They were hoping to build this idea of the semantic web, but different orgs. couldn't agree on what terms meant. They'd use the same terms, but they would mean different things, and they couldn't make naming things work across domains ("domains" in more than one dimension). So, we need something different for locating things. Names are fine for humans. We could even have names in code, but they wouldn't be used for computers to find things, just for us. If we need to disambiguate, we can find other features to help, but computing needs something, I think, that identifies things by semantic signifiers, so that even though we use the same names to talk about them, computers can disambiguate by what they actually need by function. It wouldn't get rid of all redundancy, because humans being humans, economics and competition are going to promote some of that, but it would help create a lot more cooperation between systems.
The thing about DNS and naming is that there were a lot of ideas flying around, some of them in the big standards committees. X.400 and X.500 were the OSI standards for messaging and directory services that were going to handle finding entities using specific attributes rather than with direct names or even straight hierarchical naming (like DNS finally used). It's interesting to read all the old stuff -- I had to sift through much of it a few years back when I wrote my dissertation on the early history of DNS (a cure for insomnia).
I wonder with the Internet now if anything effectively different is even possible, considering that it's no longer a small network but everywhere like the air we breathe.
> I wonder with the Internet now if anything effectively different is even possible, considering that it's no longer a small network but everywhere like the air we breathe.
You could slowly bootstrap a new system on the existing one, but you'd need a fleshed out design first :) Everything is replaceable, IMO, even well established conventions and standards, if something compelling comes along.
The CCN ideas are related to naming as well. Maybe the ideas could be extended to handle 'objects' rather than just 'content'.
Hardware architecture is the horizon of my knowledge. But one thing I've always wondered is this: why not just have memory addresses inside a computer map to local IPv6 addresses, then have some other "chip" that can distinguish between non local IP addresses that would, in a perfect object world, point to places in memory on another remote machine?
Obviously there would need to be some kind of virtualization of the memory but hopefully you get the idea. Not exactly related to naming but whatever.
Interesting - is the broader idea here that there is a virtual machine that spans multiple physical machines? Instead of virtual 'memory access', why not model this as a virtual 'software internet'?
I don't even think you need a VM, really. Just have this particular computer equipped with some soft-core that handles IP from the outside. The memory mapping, since it's just IPv6, can determine whether you are dealing with information from the outside world (non-localhost ips) or your own system (local ips). Because logically they are already different blocks in memory, they're already isolated.
With something like that you might be able to have "pure objects" floating around the internet. Of course your computer's interpretation of a network object is something it has to realize inside of itself (kind of like the way you interpret the words coming from someone else's mouth in your own head, realizing them internally), but you will always be able to tell that "this object inside my system came from elsewhere" for its whole lifecycle.
Maybe you could even have another soft-core (FPGA like) that deals with brokering these remote objects, so you can communicate changes to an incoming object that you want to send a message to. This is much more like communication between people, I think.
I mean a VM as in the idea that you are programming an abstract thing, not a physical thing. Not a VM as in a running program. You could emulate the memory mapper in software first - hardware would be an optimization.
The important point is 'memory mapper' sounds like the semantics would be `write(object_ip, at_this_offset, these_bytes)`, but what you really want IMO is `send(object_ip, this_message)`. That is, the memory is private and the pure message is constructed outside the object.
You still need the mapping system to map the object's unique virtual id to a physical machine, physical object. So having one IP for each of these objects could be one way.
Alan Kay mentioned David Reed's 1978 thesis (http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-20...) which develops these ideas (still reading). In fact, a lot of 'recently' popular ideas seem to be related to the stuff in that thesis (e.g. 'psuedo-time')
> One of the things I've realized is that using names for locating what's needed (I assume we're talking about the same idea) is part of the problem.
I don't think naming itself a problem if you have a fully decentralized system. E.g., each agent (org or person) can manage their namespace any way they choose in a single global virtual namespace. I'm imagining something like ipfs/keybasefs/upspin, but for objects, not files, and with some immutability and availability guarantees.
But yes, there should probably be other ways to find these things, using some kind of semantic lookup/negotiation.
What he means is that names are a local convention, and scaling soon obliterates the conventions. Then you need to go to descriptions that use a much smaller set of agreed on things (and you can use the "ambassador" idea from the 70s as well).
A few year ago when I was doing some historical research about DNS, I came across quite a few interesting papers that all discussed "agents" in a way that seemed based on some shared knowledge/assumptions people had at the time. In particular, these would be agents for locating things in the "future internetwork". There's a paper by Postel and Mockapetris that comes to mind. Is this an example of "ambassadors"?
Ah I see, we're taking about interoperability, not just naming.
This is related to my original interest in language structure words and ontologies. The idea there is that the set of 'relationships' between things is small and universal (X 'contains' Y, A 'is an abstraction of' B) and perhaps can be used to discover and 'hook up' two object worlds that are from different domains.
> Could be just hardware. Could be variables and methods. Could be some form of ontology.
...
> more easily and cleanly dealt with using the idea of "objects".
OK after this sitting in my mind for a bit longer something 'clicked'. What I'm thinking now is that there are many types of 'computer algebra' that can be designed. Data structures and procedures are only one such algebra - but they have taken over almost all of our mainstream thinking. So instead of designing systems with better suited algebra, we tend to map problems back to the DS+procedures algebra quickly. Smalltalk is well suited to represent any computer algebra (given the DS/procedure algebra is implemented in some 'objects', not the core language).
> created large fragile bodies of legacy code that requires experts in the old methods to maintain, fix, extend
If I understand correctly you are saying that better methods would involve objects and 'algebra' that perhaps don't involve data structures and procedures at all, even all the way down for some systems.
Mathematics is a plural for a reason. The idea is to invent ways to represent and infer that are not just effective but help thinking.
I don't think Smalltalk is well suited to represent any algebra (the earliest version (-72) was closer, and the next phase of this would have been much closer as a "deep" extensible language.
A data structure is something that allows fields to be "set" from the outside. This is not a good idea. My original approach was to try to tame this, but I then realized that you could replace "commands" with "requests" and imperatives with setting goals.
> and the next phase of this would have been much closer as a "deep" extensible language.
Are these ideas (and the 'address space of objects') elaborated on somewhere?
> A data structure is something that allows fields to be "set" from the outside. This is not a good idea. My original approach was to try to tame this, but I then realized that you could replace "commands" with "requests" and imperatives with setting goals.
I agree with in principle - but I'm having trouble imagining computing completely without data structures though (and am reading 'Early History of Smalltalk' to see if it clicks.)
You need to have "things that can answer questions". I'd like to get the "right answer" when I ask a machine for someone's date of birth, and similarly I'd like to get the right answer when I ask for their age. It's quite reasonable that the syntax in English is the same.
? Alan's DOB
? Alan's age
Here "?" is a whole computer. We don't know what it will do to answer these questions. One thing is for sure: we are talking to a -process- not a data structure! And we can also be sure that to answer the second it will have to do the first, it will have to ask another process for the current date and time, and it will have to do a computation to provide the correct answer.
The form of the result could be something static, but possibly something more useful would to have the result also be a process that will always tell me "Alan's age" (in other words more like a spreadsheet cell (which is also not "data" but a process)).
If you work through a variety of examples, you will (a) discover that questions are quite independent of the idea of data, and (b) that processes are the big idea -- its just that some of them change faster or slower than others.
Add in a tidy mind, and you start wanting languages and computing to deal with processes, consistency, inter-relations, and a whole host of things that are far beyond data (yet can trivially simulate the idea in the few cases its useful).
On the flip side, you don't want to let just anybody change my date of birth willy nilly with the equivalent of a stroke of a pen. And that goes for most answers to most questions. Changes need to be surrounded by processes that protect them, allow them to be rolled back, prevent them from being ambiguous, etc.
This is quite easy stuff, but you have to start with the larger ideas, not with weak religious holdovers from the 50s (or even from the way extensional way math thinks via set theory).
I'm thinking along these lines now: decompose systems along lines of 'meaning', not data structures (data structures add zero meaning and are a kind of 'premature materialization'), design messages first, late bind everything so you have the most options available for implementation details, etc.
The other thing I'm thinking is why have only one way to implement the internal process of an object/process? There are often multiple ways to accomplish goals, so allow multiple alternative strategies for responding to the same message and let objects choose one eventually.
Edit: wanted to add that IIUC, 'messages' doesn't imply an implementation strategy - i.e. they are messages in the world of 'meaning'. In the world of implementation, they may just disappear (inlined/fused) or not (physical messages across a network), depending on how the objects have materialize at a specific point in time.
You've got the right idea. If you think about how services on the internet operate, they don't have one way of implementing their internal processes, either.
I finally got the idea, after listening to Kay for a while, that even what we call operating systems should be objects (though, as Xerox PARC demonstrated many years ago, there is a good argument to be made that what we call operating systems need a lot of rethinking in this same regard, ie. "What we call X should be objects."). It occurred to me recently that we already have been doing that via. VMs (through packages such as VMWare and VirtualBox), though in pretty limited ways.
Incidentally, just yesterday, I answered a question from a teacher on Quora who wanted advice on how to teach classes and methods to a student in Python, basically saying that, "The student is having trouble with the concepts of classes and methods. How can I teach those ideas without the other OOP concepts?" (https://www.quora.com/Can-I-explain-classes-and-objects-with...) It prompted me to turn the question around, and really try to communicate, "You can teach OOP by talking about relationships between systems, and semantic messaging." If they want to get into classes and methods later, as a way of representing those concepts, they can. What came to mind as a way around the class/method construct was a visual environment in which the student could experience the idea of different systems communicating through common interfaces, and so I proposed EToys as an alternative to teaching these ideas in Python. I also put up one of Kay's presentations on Sketchpad, demonstrating the idea of masters and instances (which you could analogize to classes and object instances).
I felt an urge, though, to say something much more, to say, "You know what? Don't worry about classes and methods. That's such a tiny concept. Get the student studying different kinds of systems, and the ways they interact, and make larger things happen," but I could tell by the question that, dealing with the situation at hand, the class was nothing close to being about that. It was a programming class, and the task was to teach the student OOP as it's been conceived in Python (or perhaps so-called "OOP". I don't know how it conceives of the concept. I haven't worked in it), and to do it quickly (the teacher said they were running out of time).
The question has gotten me thinking for the first time that introducing people to abstract concepts first is not the right way to go, because by going that route, one's conceptions of what's possible with the idea become so small that it's no wonder it becomes a religion, and it's no wonder our systems don't scale. As Kay keeps saying, you can't scale with a small conception of things, because you end up assuming (locking down) so much, it's impossible for its morphology to expand as you realize new system needs and ways of interacting. The reason for this is that programming is really about, in its strongest conception, modeling what we know and understand about systems. If we know very little about systems that already exist, their strengths and weaknesses, our conception of how semantic connections are made between things is going to be very limited as well, because we don't know what we don't know about systems, if we haven't examined them (and most people haven't). The process of programming, and mastering it, makes it easy enough to tempt us to think we know it, because look, once we get good enough to make some interesting things happen (to us), we realize it offers us facilities for making semantic connections between things all day long. And look, we can impress people with that ability, and be rewarded for it, because look, I used it to solve a problem that someone had today. That's all one needs, right?...
Kay has said this a couple different ways. One was in "The Early History of Smalltalk". He asked the question, "Should we even teach programming?" Another is an argument he's made in a few of his presentations: Mathematics without science is dangerous.
> The main assumption here is my thoughts are organized as graphs
Herbert Simon talks a lot about this in Sciences of the Artificial. It turns out most of human thinking is just lists. I'm not sure if that still stands in the field of psychology (my version of the book is pretty old, from the 80s).
There's a good book (a little dense though) that might help with the more abstract thinking in the direction you're going. It's called "Human Machine Reconfigurations" and it's one of the more clever books I've come across on human machine interaction, written by an anthropologist/sociologist who also worked at PARC. So often the human part is what gets lost here.
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.