how conditional statements are implemented with messages:


" As we learned more and got more ambitious about what we wanted to do, we realized that there are all kinds of things in Smalltalk that don’t scale the way they should—for instance, the reflection stuff that we had in there. It was one of the first languages to really be able to see itself, but now it is known how to do all levels of reflection much better—so we should implement that.

We saw after a couple of years that this could be done much better. The object model we saw after a couple of years could be done much better, etc. So the problem is—I’ve said this about both Smalltalk and Lisp—they tend to eat their young. What I mean is that both Lisp and Smalltalk are really fabulous vehicles, because they have a meta-system. They have so many ways of dealing with problems that the early-binding languages don’t have, that it’s very, very difficult for people who like Lisp or Smalltalk to imagine anything else." -- alan kay,



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 (permalink) is the canonical URI of this page. Stefan Ram Dr. Alan Kay on the Meaning of “Object-Oriented Programming”

(To link to this page, please use the canonical URI "" only, because any other URI is valid only temporarily.) E-Mail of 2003-07-23

Dr. Alan Kay was so kind as to answer my questions about the term “object-oriented programming”.

Clarification of "object-oriented" [E-Mail]

    Date: Wed, 23 Jul 2003 09:33:31 -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: 4965
    Lines: 117
    Hi Stefan --
    Sorry for the delay but I was on vacation.
    At 6:27 PM +0200 7/17/03, Stefan Ram wrote:
    >   Dear Dr. Kay,
    >   I would like to have some authoritative word on the term
    >   "object-oriented programming" for my tutorial page on the
    >   subject. The only two sources I consider to be "authoritative"
    >   are the International Standards Organization, which defines
    >   "object-oriented" in "ISO/IEC 2382-15", and you, because,
    >   as they say, you have coined that term.
    I'm pretty sure I did.
    >   Unfortunately, it is difficult to find a web page or source
    >   with your definition or description of that term. There are
    >   several reports about what you might have said in this regard
    >   (like "inheritance, polymorphism and encapsulation"), but
    >   these are not first-hand sources. I am also aware that later
    >   you put more emphasis on "messaging" - but I still would like
    >   to know about "object oriented".
    >   For the records, my tutorial page, and further distribution
    >   and publication could you please explain:
    >     When and where was the term "object-oriented" used first?
    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.
    computers on a network, only able to communicate with messages (so 
    messaging came at the very beginning -- it took a while to see how to 
    do messaging in a programming language efficiently enough to be 
    almost unbelievable HW architecture. I realized that the 
    cell/whole-computer metaphor would get rid of data, and that "<-" 
    would be just another message token (it took me quite a while to 
    think this out because I really thought of all these symbols as names 
    for functions and procedures.
    several algebras associated with it, and there could be families of 
    these, and that these would be very very useful. The term 
    "polymorphism" was imposed much later (I think by Peter Wegner) and 
    it isn't quite valid, since it really comes from the nomenclature of 
    functions, and I wanted quite a bit more than functions. I made up a 
    term "genericity" for dealing with generic behaviors in a 
    quasi-algebraic form.
    (though I thought Nygaard and Dahl were just tremendous thinkers and 
    designers). So I decided to leave out inheritance as a built-in 
    feature until I understood it better.
    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 
    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 
    >     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.
    >   Thank you,
    >   Stefan Ram

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 
    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.
    At 10:05 PM +0200 7/26/03, Stefan Ram wrote:
    >On Wed, Jul 23, 2003 at 09:33:31AM -0800, Alan Kay wrote:
    >>  OOP to me means only messaging, local retention and protection and
    >>  hiding of state-process, and extreme late-binding of all things.
    >   Hi Alan,
    >   I just want to say "thank you" for your explanations
    >   (including the parts not quoted above)!
    >   "local retention" is a new notion to me in the context
    >   of OOP, and I assume it refers to state-process and
    >   means that an object is in possession of its state-process,
    >   so that the state of an object is kept locally with the
    >   object and not elsewhere.
    >   I have published your reply on the web, but have removed
    >   the E-Mail addresses and similar header lines for privacy.
    >   Thanks again,
    >   Stefan


A memorandum on dataless programming: "


some good concise notes on various things that Alan Kay has said:


" He had this to say of the Internet - which he considers is “possibly the only real object-oriented system in working order”:

    To me, one of the nice things about the semantics of real objects is that they are “real computers all the way down (RCATWD)” – this always retains the full ability to represent anything. The old way quickly gets to two things that aren’t computers – data and procedures – and all of a sudden the ability to defer optimizations and particular decisions in favour of behaviours has been lost. In other words, always having real objects always retains the ability to simulate anything you want, and to send it around the planet. … And RCATWD also provides perfect protection in both directions. We can see this in the hardware model of the Internet (possibly the only real object-oriented system in working order). You get language extensibility almost for free by simply agreeing on conventions for the message forms. My thought in the 70s was that the Internet we were all working on alongside personal computing was a really good scalable design, and that we should make a virtual internet of virtual machines that could be cached by the hardware machines. It’s really too bad that this didn’t happen. If ‘real objects’ are RCATWD, then each object could be implemented using the programming language most appropriate for its intrinsic nature, which would give new meaning to the phrase ‘polyglot programming.’"


" If a language cannot define lazy function it simply lacks in abstraction power. I think any kind of fragment of the language should be nameable and reusable. (Haskell lacks this ability for patterns and contexts; a wart in the design.) So if you notice a repeated expression pattern, like

    if c then t else False

and cannot give this a name, like

    and c t = if c then t else False

and then use it with the same effect as the orginal expression, well, then your language is lacking.

For some language constructs the solution adopted by Smalltalk (and later Ruby), i.e., a very lightweight way on constructing closures is acceptable. So, for instance, I could accept writing

    ... myAnd x {y} ...

(In SML you could make something using functors, but it's just too ugly to contemplate.)



" So, why don’t people use Smalltalk? I was talking with my friend Jeffrey, since he and I share an interest in OO-architecture, and I think he said something along the lines of “it just feels odd.” There is something about the Smalltalk environment, more than the language itself, that makes people a bit uncomfortable. I grew up on Lisp machines, and so it doesn’t really have that impact on me.

That environment—-the “image”—-is very different conceptually from how most people program. Most people see programs as a series of files that are compiled and “run.” There is, underneath even the most “extreme” of the XP ideas as implemented in Java, etc., the write-compile-run-debug loop that has been inescapably etched onto people’s minds.

Smalltalk isn’t like that. Code is effectively always compiled, always ready to run, and the debug/run/edit cycles are all blurred together. You can make changes in the editor and continue on from where you are, without having to restart and get back to your original location....Also, it reminds me a bit of what happened when I worked on Zope and the ZODB (Zope Object Database), which contained almost everything originally for the system. People wanted to work on things as though they were files. There were two reasons for this.

First, the tools sucked in Zope. A HTML textarea is not an acceptable editor. This was eventually resolved with FTP and WebDAV? support. The second, though, was an innate distrust of the object database for some reason. Even though it was an append-only, transactional, recoverable, storage system, people would rather store it in a brain-dead file system because they felt it was “safer.” Irrational, completely and totally, and much of the same criticism is launched at the concept of system “images” in Smalltalk.

The last bit, is just the standard “statically typed” versus “dynamically typed” argument, or whatever you want to call it. In Smalltalk, the objects have types (i.e. Classes), but the variables that point to them do not.

" --


Well, starting from causes, I think Smalltalk's insularity is its greatest flaw. This is in part because Everything Is An Object, and objects have fairly specific conventions. There's a considerable barrier between The Rest Of The World and Smalltalk. It's not just that the syntax looks weird to people -- though that doesn't help -- but it also looks weird to other programming languages. You can't easily map C or other libraries into Smalltalk. You can't make analogous interfaces to the interfaces found in other languages -- you can't even make a freakin' function! " --

" You can't write scripts for Smalltalk, except for scripts that work in the Smalltalk environment (doIt kind of scripts). You can't run Smalltalk from the command line or as a CGI script. (This is true of Java too, but Java succeded despite this due to extreme effort on Sun's part.) It's also hard to isolate a "program" in Smalltalk -- it's all one big heap of code, you may have added methods to Object, who knows what. This customization/localization of the environment is something where Python has successfully resisted, Ruby is backtracking on, while Perl is commiting suicide to allow total customization based on Wall's personal philosophy and that language's bizarre community. " --

" .. But I think those tools are basic prerequesites to a successful language, and I don't know if the Smalltalk community has treated them as such. Many of Smalltalk's tools seem to be so commercialized that it doesn't seem like it matters much. Some happy Smalltalkers in the financial community get to try all this stuff out, while the larger world doesn't have access -- and so the rest of the world stopped caring. At least the part of the world that was willing to pay attention to cool technical stuff. The corporations that could shell out the cash aren't what drives technology advancements, because they are too concerned about risk, and anyway, corporations don't create things, only people do. " --

" This is some of what I was referring to when I said that Smalltalk programming styles led to too many frameworks and not enough libraries -- a framework requires you to take on a certain metaphor of execution, to adapt your thought process to the framework instead of adapting the program to your thoughts. Frameworks can be worth it, but they always exact a significant cost. "

"Smalltalk devalues the idea of a "program". The Smalltalk image is a lively set of interacting objects, like agents in a community. It often seems almost spontaneous the way they interact, and it's like they are all peers with no center. Ravioli code is often the result.

"There's also the syntax -- it's not a bad syntax, but it's not the dominant syntax, and it clashes badly with the dominant syntax. It's hard to phrase one in terms of the other (i.e., they do not map to each other)."

" The lack of decent syntactic support for simple imperative programming (i.e., functions) also doesn't help Smalltalk be any simpler or more accessible.

I've become distracted from my main point here: Smalltalk code feels organic and extensible, but it's not well congealed into something as distinct as a "program". The current computing world is a world of programs, not objects. Maybe we'll get to that world of objects, but there needs to be a path leading there that starts here. "


" What do you mean specifically by "the dominant syntax"? I mean function(args...) or object.function(args...). Mapping, say, Objective C into another syntax looks funny, you get stuff like obj.setX_y_(x, y) or much worse (usually much worse). Mapping the other way turns into object methodWith: arg1 with: arg2 with: arg3. I think other languages have been successful when they've been able to adopt foreign interfaces and APIs -- it allows them to quickly leverage other work (either porting code or using external code directly), and leverage not just the code but the documentation and skills around that interface. Smalltalk's syntax hinders that. " --

" Sorry, but I think the comments on your last posting still stand: you never really lived in Smalltalk. Programming in Smalltalk isn't enough: you need to really dive into the interactive system. Maybe it's the fact that I love Lisp Machines and their highly integrated world view that I am rather fond of Smalltalk systems. The first problem you have is what people often have: there is no program. Yep, that's right in a weird way: you usually don't build standalone programs (although there are options on how to do this - Cincom has it, or use Smalltalk/X if you want a classic standalone batch compiler), but work in the interactive environment. For me the Smalltalk environment became my desktop. Everything I wrote lived there, everything I wrote was instantly reachable from there and so it was very easy to integrate those parts. This isn't a problem or a bug, it's a feature!

What you do to deliver your application is to strip the image from what isn't needed any more (standard stuff with Lisp environments, too, so not really an obscure feature) and bind it with the virtual machine to form the application. This usually is a builtin tool. The reason you do it this way is that Smalltalk - same as good lisp environments - allows you to make much more use of what is already there in the image. You decide how much of the standard environment you need. Need a scripting language? Use smalltalk, deliver parts of the development environment with your application. Need a hierarchical browser for in-image structures? Use the available ones as a starting point. Need a simple attribute panel? Use the inspector. Sure, there are solutions that give you much of this flexibility in more classic environments - Ruby, Perl and Python for example. The power of already installed tools is what makes me use Python ;-) " -- comment on