"And even COND isn't special, it's just represented as messaging in Smalltalk, right?"
Right. What I meant was that the parsing would begin with "eyeball" (ST-72 was an iconic language, so you would get a character that looked like an eye viewed sideways), and then everything after that in the line was a message to "eyeball," talking about how you wanted to parse the stream--what patterns you were looking for--and if the patterns matched, what messages you wanted to pass to other objects. That was your "selector" and method. What felt weird about it, after working in Squeak for a while, is these two concepts were combined together into "blobs" of symbolic code. You would have a series of these "messages to eyeball" inside a class. Those were your methods.
The reason I said it was similar to COND was it had a similar format: A series of expressions saying, "Conditions I'm looking for," and "actions to take if conditions are met." It was also similar in the sense that often that's all that would be in a class, in the same way that in Lisp, a function is often just made up of a COND (unless you end up using a PROG instead, which I consider rather like an abomination in the language).
In ST-72, there's one form of conditional that uses a symbol like "implies" in math (can't represent it here, I don't think), and another where you can be verbose, saying in code, "if a = b then do some stuff." But what actually happens is "if" is a class, and everything else ("a = b then do some stuff") is a message to it. Of course, you could create a conditional in any form you want.
In ST-80, they got rid of the "if" keyword altogether (at least in a "standard" system), and just started with a boolean expression, sending it a message.
a = b ifTrue: [<do-one-thing>] ifFalse: [<do-something-else>].
They introduced lambdas (the parts in []'s) as objects, which brought some of the semantics "outside of the class" (when viewed from an ST-72 perspective). It seems to me that presents some problems to its OOP concept, because the receiver is not able to have complete control over the meaning of the message. Some of that meaning is determined by partitioned "blocks" (lambdas) that the receiver can't parse (at least I don't think so). My understanding is all it can do with them is either pass parameter(s) to the blocks, executing them, or ignore them.
One of the big a-ha moments I had in Smalltalk was that you can create whatever control structures you want. The same goes for Lisp. This is something you don't get in most other languages. So, a temptation for me, working in Lisp, has been to spend time using that to work at trying to make code more expressive, rather than verbose. A positive aspect of that has been that it's gotten me to think about "meanings of meaning" in small doses. It creates the appearance to outsiders, though, that I seem to be progressing on a problem very slowly. Rather than just accepting what's there and using it to solve some end goal, which I could easily do, I try to build up from the base that's there to what I want, in terms of expression. What I have just barely scratched the surface of is I also need to do that in terms of structure--what you have been talking about here.
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.
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.
"Most of the old hands and historians of the moon shot point to the public in the 70s no longer being afraid of the Russians in the way they had been in the 50s, and the successful moon landings helped assuage their fears."
That's what I realized about 10 years ago. The primary political motivation for the space missions was to establish higher ground in a military strategic sense, and once that was accomplished, most people didn't care about it anymore. There was also an element of prestige to it, at least from Americans' perspective, that because we had reached a "higher" point in space than the Russians did, that gave us a sense of dominance over their extension of power.
You know this already, but people should keep in mind that what got the ball rolling was the launch of Sputnik in 1957. The message that most people got from that was that the Russians controlled higher ground, militarily, and that we needed to capture that pronto, or else we were going to be at a disadvantage in the nuclear arms race.
It also created a major push, as I understand, by the federal government to put more of an emphasis on math and science education, to seed the population of people who would be needed to pull that off. I've heard thinking that this created a generation of scientists and engineers who eventually came into industry, which created the technological products we eventually came to use. There's been a positive sense of that legacy from people who have reviewed it, but I've since heard from people who went through the "new math" that was taught through that push. They hated it with a passion, and said it turned them off to math for many years to come.
The more positive aspect I like to reflect on is that Sputnik inspired young people to become interested in math, science, and engineering on their own, and they really experienced those disciplines. A nice portrayal of one such person is in the movie "October Sky," based on Homer Hickam's autobiographical book, "Rocket Boys."
I can't remember if I've brought this up already in this thread, but if you want to "kick the tires" on ST-72, Dan Ingalls has an implementation of it up on the web. It's running off of a real ST-72 image. I wrote about it at https://tekkie.wordpress.com/2014/02/19/encountering-smallta...
I include a link to it, and described how you can use it (to the best of my knowledge), though my description was only current to the time that I wrote it. Looking at it again, Ingalls has obviously updated the emulation.
The nice thing about this version is it includes the original tutorial documentation, written by Kay and Adele Goldberg, so you can download that, and learn how to use it. I found that I couldn't do everything described in the documentation. Some parts of the implementation seemed broken, particularly the class editor, which was unfortunate, and some attempts to use code that detected events from the mouse didn't work. However, you can write classes from the command line (ST-72 was largely a command-line environment, on a graphical display, so it was possible to draw graphics).
If you take a look at it, you will see a strong resemblance to Lisp, if you're familiar with that, in terms of the concepts and conventions they were using. As Kay said in "The Early History of Smalltalk," he was trying to improve on Lisp's use of special forms. I found through using it that his notion of classes, from a Lisp perspective, existed in a nether world between functions and macros. A class could look just like a Lisp function, but if you add parsing behavior, it starts behaving more like a macro, parsing through its arguments, and generating new code to be executed by other classes.
The idea of selectors is still kind of there, informally. It's just that it takes a form that's more like a COND construct in Lisp. So, rather than each selector having its own scope, as in later versions, all of them exist in an environment that exists in the scope of the class/instance.
After using it for a while, I could see why they went to a selector model of message receipt, because the iconic language used in ST-72 allowed you to express a lot in a very small space, but I found that you could make the logic so complex it was hard to keep track of what was going on, especially when it got recursive.
What came to mind when I read your comments were some complaints I've had that relate to the "looking for the keys under the streetlight" fallacy. There are intuitions and anecdotes we can have about the unknowns, which is the best we can do about many things in the present, until they can be measured and tested. A problem I see often is there are people who believe that if it can't be measured, it's not part of reality. I find that the unknowns can be a very important part of working with reality successfully, and that what can be measured in the present can end up being not that significant. It depends on what you're looking for.
As Kay and I have discussed here, efficiency is not irrelevant, but we agree it's not the only significant factor in a system that we all hope will produce the wealth needed for societal progress. What seems to be needed is some knowledge and ethics re. the wealth of society, ideally enacted voluntarily, as in the philanthropic efforts of Carnegie, and similar efforts.
I happened to watch a bit of Ken Burns's doc. on the Vietnam War, and I was reminded that McNamara was a man of metrics. He wanted data on anything and everything that was happening to our forces, and that of the Viet Cong. He got reams of it, but there were people who asked, "Are we winning the hearts and minds?" There were no metrics on that. We didn't have a way to measure it, so the question was considered irrelevant. The best that could've been done was to get honest opinions from commanders in the field, who understood the war they were fighting, and were interacting with the civilian population, if people were willing to listen to that. In a guerrilla war, which is what that was, "hearts and minds" was one of the most important factors. Most of the rest could've been noise.
I dovetail with your complaint about focus on the economy in policy, but for me, it's philosophical: It's not the government's job to be worrying about that so much. If you look at the Constitution, it doesn't say a thing about "shall maintain a prosperous economy," or, "shall ensure an equitable economy," or any of that. Sure, people want enough wealth to go around, but it's up to us to negotiate how that happens, not the government. I think unfortunately, politicians and voters, no matter their political stripe, have lost track of what the government's job is. I think, broadly, we treat it like an insurer, or banker of last resort. If things don't seem to work out the way we'd like, we appeal to government to magically make us whole (including economically). That's really missing the point of it.
I could go into a whole thing about the medical system (I won't), but I'll say from the research I've done on it (which probably is not the best, but I made an effort of it), it is one of the most tragic things I've seen, because it is grossly distorted from what it could be, but this is because we're not respecting its function. As you've surmised with globalization, it's been set up this way by some interested people. It's a choice. I see a big knowledge problem with what's been done to it for decades. Doesn't it figure that people interested in healing people should be figuring out how to do it, to serve the most people who need their help, rather than people who have no idea how to do that thinking they should tell them how to do it? This relates back to your proposition about scientific research. Shouldn't research be left to people who know how to do that, rather than people who don't trying to micromanage how you do it? I think we'd be better off if people had a sense of understanding the limits of their own knowledge. I don't know what it is that has people thinking otherwise. The best term I can come up for it is "hubris." Perhaps the more accurate diagnosis, as Kay was saying, is fear. It makes sense that that can cause people to put their nose in deeper than where it should be, but it's like a horde panicking around someone who's collapsed from cardiac arrest, which doesn't have the good sense to give someone who knows CPR some room, and then to allow medical personnel in, once they show up.
It's looked to me like a feedback loop, and I shudder to think about where it will end up, but I feel pretty powerless to stop the process at the moment. I made some efforts in that direction, only to discover I have no idea what I'm really dealing with. So, with some regret, I've followed Sagan's advice ("Don't waste neurons on what doesn't work."), left it alone, and directed my energy into areas I love, where I hope to make a meaningful contribution someday. The experience of the former has given me an interest in listening to scientists who have studied people, what they're really like. It seems like something I need to get past is what Jon Haidt has called the "rationalist delusion," particularly the idea that rational thought alone can change minds. Not so.
"We are 'story creatures' and it takes a lot of training and willpower to depart from 'fond stories and beliefs' to 'actually think things through'."
What your analysis did for me was help put two and two together, but yes, it "collided" with my notions of what an accomplishment it was, and what I had been led to believe that would lead to. What you exposed was that the reality of "what that would lead to" was quite different, and it explained the reality that was unfolding.
I knew that Apollo was a big rocket (ironically, that was one thing that impressed me about it, but I thought how amazing it was that such a thing could be constructed in the first place, and work. Though, I thought many years later about just what you said, that the more fuel you add, the more the fuel is just expending energy moving itself!), and that there were only three people on it, though the "efficiency" perspective, relating that to how it did not contribute to further knowledge for space travel, didn't occur to me until you laid it out. I also knew from listening to Reagan's science advisor that NASA was heavily influenced by the goals of military contractors that had done R&D on various technologies in the '60s, and which exerted political pressure to put them to use, to get return on investment. He said something to the effect of, "People worry about the Military Industrial Complex. Well, NASA IS the Military Industrial Complex! People don't think of it that way, but it is."
Not too long after I heard you talk about this, I happened to hear about a simulator called the Kerbal Space Program (commonly referred to as KSP), and someone posted a video of a "ludicrous single-launch vehicle to Mars (and back)" in it. Even though I think I've heard that KSP does not completely use realistic physics, it drove your point home fairly well. Though, people would point out that none of the proposed missions to Mars have talked about a single-launch vehicle from surface to surface. All of the proposals I've heard about have talked about constructing the vehicle in orbit. KSP, though, assumes chemical propellant.
"the real romance and its implications didn't happen in the general public and politicians."
In hindsight, I've been struck by that. When I took the time to learn about the history of the Apollo program, I learned that Apollo 11 made a big impression on people all over the world, but that was really it. I think as far as the U.S. was concerned, people were probably more impressed that it met a political goal, JFK's bold proclamation that we would get men to the Moon and back, and that it was a historic first, but there was no sense of, "Great! Now what?" It was just, "Yay, we did it! Now onto other things." There's even been some speculation I've heard from politicos, who were in politics at the time, that we wouldn't have done any of the moon shots if Kennedy hadn't been assassinated, that it was sympathy for his legacy that drove the political will to follow through with it (if true, that's where the romance lay). Hardly anybody paid attention to it after 11, with the exception of Apollo 13, since there was the drama of a possible tragedy. Apollo 18 never got off the ground. The rocket was all set to go, but the program was scrubbed. People can look at the rocket, laid out in its segments sideways, at the Johnson Space Center in Houston.
Taking your feedback into consideration, I had the thought that it would be more accurate to talk about things like "2" in an OOP context as symbols with semantics (which provide meaning to them), not data, since "data" connotes more a collection of inputs/quantities, where we may be able to attach a meaning to it, or not, and that wasn't what I was going after. I was going after a relationship between information and semantics that can be associated with it, but trying to provide a transition point from the idea of data structures to the idea of objects, for someone just learning about OOP. Doing a sleight of hand may not do the trick.
My starting point was to use a very interesting concept, when I encountered it, in SICP, where it discussed using procedures to emulate data, and everything that can be done with it. It seemed to help explain for the first time what "code is data" meant. It illustrated the inversion I was talking about:
"In 2.1.3 it questions our notion of “data”, though it starts from a higher level than most people would. It asserts that data can be thought of as this constructor and set of selectors, so long as a governing principle is applied which says a relationship must exist between the selectors such that the abstraction operates the same way as the actual concept would." It went on to illustrate how in Lisp/Scheme you could use functions to emulate operations like "cons", "car", and "cdr", completely in procedural space, without using data structures at all.
This is what I illustrate with "2 + 2", and such, that code is doing everything in this operation, in OOP. It's not a procedure applied to two operands, even though that's how it looks on the surface.
Great description of the problem (and great description of what we could have instead)! What came to mind as I read what you said here was a bit that I caught Neil deGrasse Tyson talking about from 8 years ago. As I heard him say this, I thought he was right on point, but I also felt sad that it's pretty obvious we're not thinking like this in computing. It turns out this is not just a problem in computing, but in science funding generally. That's what he was talking about, though he was quite polite about it:
It strikes me that a very corrosive thought process in our society has been to politicize the notion of "how competitive we are" economically. Sure, that matters, but I see it more as a symptom than a cause of social problems. I hate seeing it brought up in discussions about education, because sure, competition is going to be a part of societal living, and in many educational environments, there's some aspect of competition to it (a story I heard from my grandfather from when he entered medical school was, "Look to your left. Look to your right. Only one of you will be graduating with a medical degree," because that was the intended ratio along the bell curve), but bringing economic competitiveness into education misses the point badly. I understand where the impulse to focus on that comes from, because globalization tends to produce a much more competitive economic landscape, where people feel much more uncertain about basic questions they have to answer. Part of which is creating the life they want, but often people end up missing a significant part of actually creating it (if it's even feasible. What I see more often is a compromise, because there are only so many hours in a day, and only so much effort can be put into it) in the process of trying to create it. They get caught up in "doing," as you said.
As I've thought back on the '60s, it seems like while there was still competition going on, the emphasis was on a political competition, internationally, not economic. There was a significant technological component to that, because of the Cold War/nuclear weapons. The creation of ARPA and NASA was an effect of that. My understanding is we underwent a reorientation in the 1980s, because it was realized that there was too little attention paid to the benefits that a relatively autonomous economy can produce, killing off bad ideas, where what's being offered doesn't match with what people need or want, and allowing better ones to replace them. That's definitely needed, but I'm in agreement with Kay that what education should be about is helping people understand what they need. Perhaps we could start by telling today's students that if and when they have children, what their children need is to understand the basic thought-inventions of our society in an environment where they're more likely to get that. Instead, what we've been doing is treating schools like glorified daycare centers. Undergraduate education has been turned into much the same thing.
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."
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!
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.
"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
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.
"In fact a person would be labelled "elitist" to dare suggest anything else -- e.g. that universities are not just vocational schools for getting the skills for one's future job, or that technology should not just be about what Joe Public is capable of mastering, but about advancing Joe and Jane public."
I've run into this very thing. The ironic thing about it is advocating for literacy, and understanding the abstract inventions of our civilization is the antithesis of elitism, because think about what would take place in a society where nobody who has the ability to influence events knows these things; where people do not know how to create their own analysis of events, to argue well, or to invent new social structures that benefit communities; to be active agents in negotiating their society's political destiny, keeping in mind the invented conceptual "guardrails" that maintain things like rule through law, and equal rights. In a society like that, elitism is all you have! Where the thought-inventions of our modern civilization are maintained, there is more possibility for creating an egalitarian society, in certain contexts, more power-sharing, and I think the evidence suggests more social progress.
This doesn't get enough credit these days, but I think the historical evidence suggests certain forms of religion have helped promote some of these civilizational inventions as virtues, on a widespread basis, supporting the secular education that spread them.
My experience has been that the reason people may put the label "elitist" on it is that learning these ideas is hard, and everybody knows that. So, there's been an understood implication that only a small number of people will be able to know most of them, and if most of the attention is devoted to inculcating these inventions in a relatively small number of people, then that will create an elite who will use their skills to the disadvantage of everyone else, who did not receive this education. What these people prefer to use instead is a lowest-common-denominator notion of egalitarianism, which doesn't promote egalitarian virtues in the long run, because it attenuates the possibility of maintaining a society where people can enact them. If we forget the hard stuff, because it's hard, we won't get the benefits they offer, over time. We will revert to a pre-modern state, because all the power to maintain our civilization is in these ideas. Keeping them as conventions/traditions is not good enough, because as we see, conventions get challenged via. a pragmatic, anti-tradition impulse with each new generation.
I think your analogy is going in a better direction. I had the same idea after taking a look at Squeak for a while. What would need to be added to your analogy is a notion of design. You see, in Smalltalk, for example, your programming takes place in the messages. So, even the daemons (which, for the sake of argument, we could think of as analogies to objects), which would be the senders and receivers of messages would be made out of the same stuff, not C/C++. So, this is a pretty dramatic departure from the way Unix operates. What this should suggest is that the semantic connection between objects is late-bound. Think of them as servers.
Secondly, in the typical Smalltalk implementation, there is still compilation, but it's incremental. You compile expressions and methods, not the whole body of source code for the whole system. What's really different about it is since the semantic actions are late-bound, you can even compile something while a thread is executing through the code you're compiling. So, you get nearly instant feedback on changes for free. Bret Victor's notion of programming environments blurs the axes you're talking about even more, so that you don't have to do two steps to see your change, while a thread is running (edit, then compile). You can see the effect of the change the moment you change an element, such as the upper bound of an iterative loop. To make it even more dynamic, he tied GUI elements (sliders) to such things as the loop parameters, so that you don't have to laboriously type the values to try them out. You can just change the slider, and see the effects of the change in a loop's range very quickly, such that it almost feels like you're using a tool-based design space, rather than programming.
I don't know how this was done in ST-78, but in ST-80, at least in accounts I've heard from people who've used versions of it, and in the version of Squeak I've used from time to time, the source code is not technically stored with the class object, though the system keeps references to the appropriate pieces of source code, and their revisions, mapping them to the classes in the system, so that when you tell the system you want to look at the source code for a class, it pulls up the appropriate version of the code in an editor.
Source code is stored in a separate file, and Smalltalk has a version control system that allows reviewing of source code edits, and reversion of changes (undo). The class object typically exists in the Smalltalk image as compiled code.
There are many things that are different about this vs. what you typically practice in CS, but addressing your point about data, in OOP, objects are supposed to take the place of data. In OOP, data contains its own semantics. It inverts the typical notion of procedures acting on data. Instead, data contains procedures. It's an active "live" part of the programming that you do. So, yes, data is persisted, along with its procedures.
A simple example in Smalltalk is: 2 + 2. If we analyze what's going on, the "2"'s are the pieces of data, the objects/servers, and "+" is used to reference a method in one of the data instances, but it doesn't stop there. The "2" objects communicate with each other to do the addition, getting the result: 4. As you can tell implicitly, "2 + 2" is also source code, to generate the semantic actions that generate the result.
"There aren't any parents around to take care of childish adults. We are it. So we need to grow up and take responsibility for our world, and the first actions should be to try to understand our actual situations."
I am seeing the expectation that there will be parents around to take care of childish adults, though this has really come into prominence in the last 10 years, the last 3 years, in particular. For me, it's evoked notions of H. G. Wells's "Eloi." If that sentiment moves forward unchanged, we won't get "parents" in reality, of course, but some perverted in loco parentis in society. I've heard hope expressed in some quarters that reality will provide some needed blows from some 2x4's across the head, once the young venture out into the world, but I wonder whether sheer numbers will decide this; whether the young will choose to reorient our society, in an attempt to please themselves, rather than being influenced by its experience.
Re. "most people are not interested in this"
From what I've seen, this excuse came out of a combination of the technical side of the "two cultures," and the distraction of a lot of people becoming excited by some perceived new possibilities. More recently, my perspective has shifted to it coming out of a perverted notion of "self-esteem," that challenge is "harmful," because being contradicted creates a sense of limits, isolation or shame, or more materialistically, the fear of economic isolation, thereby reducing career prospects for something original.
What's emerged is a desire to affirm one's self-image as "good," regardless of notions of good works. This is where the "legal drugs" come in, reinforcing this. Neil Postman was right to fear this dynamic.
Diverting off of what I'm saying here (though staying on your topic), have you looked at William Easterly's critique of how foreign aid is conducted? I think it dovetails nicely with what you're talking about, here. The short of it is that most aid efforts to the undeveloped world offer some form of short-term relief, but they don't address at all the political and economic issues that cause the problems the aid is trying to address in the first place. Secondly, when he's tried to confront the aid organizations about this, there is no interest in pursuing these matters, a version of "most people aren't interested in stuff like this." Whether there's a sincere desire to solve problems, or just go through the motions to "help," to make it appear like something is happening (ie. putting on a kind of show of compassion for public relations, and satisfying certain political goals), I don't know. It seems like the latter.
Do you have any insight on what's causing the reticence to get into these matters? Easterly didn't seem to have answers for that, as I recall.
This kind of gets into philosophy, but a metaphor I came up with for thinking about this (another phrase for it is "thought experiment") is:
If I speak something to a rock, what is it to the rock? Is it "signal," or "data"?
Making the concept a little more interesting, what if I resonate the rock with a sound frequency? What is that to the rock? Is that "signal," or "data"?
Up until the Rosetta Stone was found, Egyptian hieroglyphs were indecipherable. Could data be gathered from them, nevertheless? Sure. Researchers could determine what pigments were used, and/or what tools were used to create them, but they couldn't understand the messages. It wasn't "data" up to that point. It was "noise."
I hope I am not giving the impression that I am a postmodernist who is out here saying, "Data is meaningless." That's not what I'm saying. I am saying meaning is not self-evident from signal. The concept of data requires the ability to interpret signal for meaning to be acquired.
Right. What I meant was that the parsing would begin with "eyeball" (ST-72 was an iconic language, so you would get a character that looked like an eye viewed sideways), and then everything after that in the line was a message to "eyeball," talking about how you wanted to parse the stream--what patterns you were looking for--and if the patterns matched, what messages you wanted to pass to other objects. That was your "selector" and method. What felt weird about it, after working in Squeak for a while, is these two concepts were combined together into "blobs" of symbolic code. You would have a series of these "messages to eyeball" inside a class. Those were your methods.
The reason I said it was similar to COND was it had a similar format: A series of expressions saying, "Conditions I'm looking for," and "actions to take if conditions are met." It was also similar in the sense that often that's all that would be in a class, in the same way that in Lisp, a function is often just made up of a COND (unless you end up using a PROG instead, which I consider rather like an abomination in the language).
In ST-72, there's one form of conditional that uses a symbol like "implies" in math (can't represent it here, I don't think), and another where you can be verbose, saying in code, "if a = b then do some stuff." But what actually happens is "if" is a class, and everything else ("a = b then do some stuff") is a message to it. Of course, you could create a conditional in any form you want.
In ST-80, they got rid of the "if" keyword altogether (at least in a "standard" system), and just started with a boolean expression, sending it a message.
a = b ifTrue: [<do-one-thing>] ifFalse: [<do-something-else>].
They introduced lambdas (the parts in []'s) as objects, which brought some of the semantics "outside of the class" (when viewed from an ST-72 perspective). It seems to me that presents some problems to its OOP concept, because the receiver is not able to have complete control over the meaning of the message. Some of that meaning is determined by partitioned "blocks" (lambdas) that the receiver can't parse (at least I don't think so). My understanding is all it can do with them is either pass parameter(s) to the blocks, executing them, or ignore them.
One of the big a-ha moments I had in Smalltalk was that you can create whatever control structures you want. The same goes for Lisp. This is something you don't get in most other languages. So, a temptation for me, working in Lisp, has been to spend time using that to work at trying to make code more expressive, rather than verbose. A positive aspect of that has been that it's gotten me to think about "meanings of meaning" in small doses. It creates the appearance to outsiders, though, that I seem to be progressing on a problem very slowly. Rather than just accepting what's there and using it to solve some end goal, which I could easily do, I try to build up from the base that's there to what I want, in terms of expression. What I have just barely scratched the surface of is I also need to do that in terms of structure--what you have been talking about here.