Data and Procedures together

Transcript

Real Objects

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

What is OOP for Alan Kay

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

The big idea is "Messaging"

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

Dynamic meanings, not static meanings

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

Semantic Negotiation

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

The Art of the Metaobject Protocol

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

Ideas on Systems

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

Alan Kay on Agents

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

Distributed Objects versus REST

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