Alan Kay is still waiting for his dream to come true

> (except during the build process)

That's the key point though. In a large scale system (think multiple systems written by multiple groups running on multiple machines) when you modify a shared data type, how do you update the systems?

I've seen some of Bret Victor's talks but your description made it click!

> the source code is not technically stored with the class object

This is more of an optimization choice, perhaps? Given the link is maintained, it might be OK to say the source code and the bytecode form are two forms representing the same object?

"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

Inspired by what he said there, I tried a little experiment in Squeak, which worked, as far as it went (scroll down the answer a bit, to see what I'm talking about, here): https://www.quora.com/What-features-of-Smalltalk-are-importa...

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.

I was using "data" in the spirit of a saying I heard many years ago in CS, that, "Data is code, and code is data." It seems that people in CS are still familiar with this phrase. I was focusing on the latter part of that phrase. I was trying to answer the question that I think is often implied once you start talking to people about real OOP, "What about data?" I almost don't like the term "data" when talking about this, because as you say, it gets one away from the focus on semantics, but whenever you're talking to people in the computing field, such as it is, I think this question is unavoidable, because people are used to thinking of code and information as separate, hence the notion of data structures. People need a way to translate in their minds between what they've done with information before, and what it can be. So, I used the term "data" to talk about "literal objects" (like "2", or other kinds of input), but I was using the description of "processors" (ie. computers), "containing procedures," which can also be thought of as "operators."

I think the idea of an "inversion" is quite apt, because as you've said before, the idea of data structures is that you have procedures acting on data. With real objects, you still have the same essential elements in programming, the same stuff to deal with, but the kinds of things programmers typically think about as "data" are objects/computers in OOP, with intrinsic semantics. So, you're still dealing with things like "2", just as procedures acting on data do, but instead of it being just a "dead" symbol, that can't do anything, "2" has semantics associated with an interface. It's a computer.

Hmm. So, it sounds like the same "keyhole" problem I've seen you talk about before (you used an AIDS epidemic as an example with this). What's seen is taken as "good enough," because the small perspective seems large enough. If there are any frustrations or tragedies, they're taken as, "It goes with the territory. Just keep plugging away."

There's a parable I used to hear that I think plays right into this:

Two people are walking along a beach, and they see an enormous field of starfish stranded ashore, and one of them starts throwing them, one by one, back into the sea. The other is watching, and says, "What's the point? You're not going to be able to save all of them." The person doing the throwing holds up a starfish, and says, "I can save this one."

It's a nice thought, talking about good will and perseverance, and certainly the message shouldn't be, "Give up," but I think it nicely illustrates the "keyhole" problem, because ideas like this lead people to believe that because they can see people who need help, even if the number is more than they can handle, and they're trying to help those people in the moment, that they're improving their lives in the long-term. That may not be true.

I've seen you talk about the "MacCready Sweet Spot" in relation to the Apollo program. BTW, I first heard you talk about that in a web video from some congressional testimony you gave back in 1982, when Al Gore was Chairman of the Science and Technology Committee. When you said that the Apollo rockets were below threshold, not nearly good enough to advance space travel, and that the rockets were a kind of kludge, the camera was panning around the room, showing large posters of different NASA missions that had been hung up around the chamber. Gore said in jest, "The walls in this room are shaking!" I can imagine! When I first heard you say that, it struck me as so contrary to the emotional impact I had from understanding what was accomplished (I do think that landing on the Moon and returning safely to Earth was a mean feat, particularly when the U.S. couldn't get a rocket into space to save our lives 12 years earlier (I don't mean that literally)), but as I listened to you explain how the rocket was designed (450 ft., mostly high explosives, with room for only 3 astronauts, not to mention that the missions were for something like 9 days at a time. Three days to get there. Two, sometimes more days, on the surface, and then three days to get home), it occurred to me for the first time, "My gosh! He's right!" It really helped explain my disappointment at seeing us not get beyond low-Earth orbit for decades. For years, I thought it was just a lack of will.

I've explained to people that when I was growing up in the '80s, I had this expectation drummed into me (willingly), as many people in my generation did, that we would see interplanetary travel, probably within our lifetimes, and in several generations, interstellar travel. It was very disappointing to see the Space Shuttle program cancelled with seemingly nothing beyond it on the horizon, and I think more importantly, no goals for anything beyond it that have been compelling. I heard you explain in a more recent presentation that this was a natural outcome of Apollo, that it set in motion something that had its own inertia to play out, but the end result is no one has any enthusiasm for space travel anymore, because the expectations have been set so low. The message being, "Beware of large efforts below threshold." Indeed!