![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
Difference between revision 3 and current revision
No diff available.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, http://queue.acm.org/detail.cfm?id=1039523
--
"
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 http://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”
(To link to this page, please use the canonical URI "http://www.purl.org/stefan_ram/pub/doc_kay_oop_en" 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
useful).
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
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
>
> 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
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:
>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
--
Remarks
A memorandum on dataless programming:
http://www.rand.org/pubs/research_memoranda/2007/RM5290.pdf "
--
some good concise notes on various things that Alan Kay has said:
http://mythz.servicestack.net/blog/2013/02/27/the-deep-insights-of-alan-kay/
--
" 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! " -- http://www.ianbicking.org/where-smalltalk-went-wrong.html
" 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. " -- http://www.ianbicking.org/where-smalltalk-went-wrong.html
" .. 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. " -- http://www.ianbicking.org/where-smalltalk-went-wrong.html
" 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. "
-- http://www.ianbicking.org/where-smalltalk-went-wrong-2.html
" 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. " -- http://www.ianbicking.org/where-smalltalk-went-wrong-2.html
" 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 http://www.ianbicking.org/where-smalltalk-went-wrong-2.html
