Seminar with Alan Kay on Object Oriented Programming

[Music] good idea to put up a slide warning you

there might be some IBM jokes of course this isn't I guess this isn't really IBM

country out here although I did hear a rumor that you're still programmed in

Fortran quite a bit and even the dread word COBOL was heard so maybe it's

worthwhile you know object-oriented programming is actually a rather old technology it is

just a few years younger in fact than the kind of programming technology that

most people are used to that of data structures manipulated by procedures and

for various reasons it has not come into

currency into vogue until the last couple of years but it's actually about

25 years ago I wrote my first program that I would call object-oriented in

1962 and people have been writing

programs in that style even earlier than

that in my particular case I was a programmer in the Air Force at Air

Training Command in 1962 the there were

no standardized operating systems of course that's true today

but back then there was actually a reason for it

nobody had gotten around to the idea of thinking it it might be useful and Air

Training Command had a problem of moving

tapes tapes with records of various

kinds on them from one Air Training Command base to another the machines

back borrows two twenties which were

machines that have had about five thousand characters of of storage we're

about the size of this room and we're great coffee warmers my image of them of

the 220 is with a this huge set of boxes with a row of pots on top trapping the

heat is a came out now the problem that

they had was that there is no way to standardize on what the formats of the

different records were they changed and the operating system he was usually just

the kind of a loading program and so there was no way of standardizing on

that and they wondered how can we actually read these data records if

everything is constantly changing and nothing holds still somebody thought up

a great idea that idea was to have the

records shipped in the following format the each tape file had three sections to

it the front section was fairly short it had a bunch of relative pointers into

the second section which contained a bunch of Burroughs 220 code and that

code knew how to deal with a third section which had the actual data records and so what you got when you

read a record from this machine was you

read that record the first two parts of the of the record into storage use the

the front part of it which were these indirect jumps into the second part of

it the code as the protocol for dealing with the tape

they're usually about 20 or 30 what we would call messages today but 20 or 30

entries in the in that first table and the code that came along with the tape

records knew how to deal with all the data so in current day terms what the

Air Training Command was doing I think it was as far ago as the late 50s was to

ship an entire class of objects the

class was shipped with the protocol with

all of the code and with all of the data in a form in which you did not have to

penetrate any of it in order to make use of it that was used for a number of

years as a technique until COBOL came in

and the Air Force forced all of the all of those good ideas to go away in order

to standardize and COBOL which is a much weaker conception going back to the

notion of data structures that are fragile now I understand that we have a

kind of a mixed audience today in that some of the people in the room are

rather knowledgeable about object-oriented programming some of the

people in the audience are here out of curiosity so I made a kind of a mixed

talk what I would like to do is to give

you sort of a perspective on where object-oriented programming has been

what it's what it's been done without without getting to historical about it

but try and give you an understanding of why it has contributed so much in a

number of areas other than just writing programs that don't break one of those

is user interface which is a very important area and there are some direct

relations chips to the way we think about objects and the way we think about

user interface and then take you into

the future a little bit and show you some of the things in which object-oriented programming is being

used for in research directions and then try and open up the form into issues

because my belief is that the basic ideas of object-oriented

are quite simple maybe too simple to be

popular until we absolutely require

simplicity in this stage of 2 million line programs but that the most

interesting thing about object-oriented programming are the are the various

issues and the styles for using it and those haven't settled yet so my

reference to the IBM joke I think a good good way of starting out the talk is

that last year it was even reported in

Business Week as a significant event IBM had its first object-oriented colloquium

it was such an amazing thing they believe that only 25 people would attend

and in fact 500 attended and they had to turn away 500 people from within IBM I

got invited to give the keynote talk part of what I'm going to show you today is from that keynote talk and standing

there in Yorktown Heights giving the

giving the talk I was reminded of William James's characterization of the

three stages that an idea goes through the first stage is the new idea is

characterized as the work of mad been

absolutely denounced out of hand a few years later goes through a different

stage when it's remarked on as being commonplace and obvious all the time

then the third and final stage is when the original denouncer is claimed to

have invented it and we are now in that

third stage for object-oriented programming because now that iBM has decided to adopt I've yet

I'm Jacobian program we can be quite sure that it's actually obsolete

and on its way out

so now before before I get into the

historical part what I thought I'd do is

for those people who are not acquainted with it at all I thought I would just

say a couple of couple of words about

what it what I mean when I say object-oriented programming and I have a

I have a very simple diagram here for me

the whole notion of objects was

triggered off by seeing a number of different systems some of them in

computer science but the first ones that I looked at were actually biological I

have a degree in molecular biology and

one of the things that struck me when I was studying molecular biology many years ago was that compared to the kinds

of structures that we tend to build here on earth the average biological

structure is more than a thousand times as complex both as regard to the number

of different parts it has and to the

complexity that has to be controlled for

instance a grand piano is a rather complex machine has about 20,000 parts

which surprises most musicians you don't even think that they're actually playing

on a machine they think of it as an instrument and the instrument by

definition can't be a machine but in fact it is a machine has about 20,000

parts our bodies have approximately a

trillion cells in them and each cell is

rather complex each cell has many millions of components in its own right

so one of the ways nature discovered to

control complexity and the kinds of interactions that are likely to happen

is to try and incapsulate them in

various ways this is a familiar principle to us it's something that we use in regular program

as well trying to encapsulate and the

question you're always asking when you encapsulate we're going to ask this

quite a bit later is just what is encapsulated what kinds of things are we

trying to control are usually in regular programming what we encapsulate are

sections of programs that occasionally

will try and encapsulate with regard to a protocol for dealing with some system

we don't want to inquire about the internals of what biological systems

encapsulate is the actual environment in

which most important processing takes place there are very few object-oriented

programming languages that go that far the average object-oriented programming

language encapsulate snot the environment but in fact something like

the state of a data structure along with

the procedures that know how to intimately manipulate it and try and tie

those two areas together in a way that

they cannot be penetrated from the outside when people speak of an

object-oriented programming language like Objective C or C++ they're talking

about even less than that because they're the encapsulation is almost a

convention it's done by means of macros

the amount of protection at runtime that

is delivered is rather low so there all

of these gradations now biological systems encapsulate with a vengeance

because nature discovered that if you

give each cell its own little captured ocean and let it devote about 90% of its

actual energies to simply protecting

itself from the outside world as though the outside world were hostile then you

get a situation where you can build very large structures rather safely and

encapsulated is not just the saline solution not just the organic Moloch

skills but also encapsulated and not

just the programs that drive the cell but in fact encapsulated in biological

organisms as many of you are aware is the entire plan for the entire structure

okay now we don't generally do that when

we write an object-oriented program but in fact people are starting to do that

now in artificial intelligence and people who are interested can can bring

this up later so my particular

my particular motivation

when I started thinking about objects

was simply that of biological cells and

one of the things that is difficult to escape when you look at biological cells

is first the extent to which the outside

world is kept away from the cell membrane and then the other thing is is

that the cells aren't completely in isolation they communicate by means of

sending messages to each other and again the way we way we translate that into

computer terms is done in a much more

restrictive way than biology does it biology generally communicates without

wearing who's going to receive I'm going to talk a little bit later about a

object-oriented strategy in which messages aren't sent at all they're only

received you might think about what an object-oriented system might be like if

you never sent a message but objects could receive what would they receive

all I could do is receive the translation of this model into machine

terms for me 25 years ago or so was that

these biological cells acted a lot as though they're on a network you can

think of it as a crossbar switch or a

Ethernet type network in which every object can send to every other object

and each one of these things is a lot like a little computer in fact is very

difficult in a good object-oriented system to find out where the hardware

stops and the software begins and the

this notion of a little computer in the

in the large here is something that is worthwhile considering when we think

about making very small things now there's a principle in design that

people came up with many years ago it's

called the basic principle of recursive design and the idea is make the parts

have the same power as the whole

we know in the factorial example that a

recursive program like factorial its

charm is it's able to reinvest the

conditional branches and so in some sense the program remains as long as

that is true the program remains as strong as it was when you entered it

because you can always reinter it instead of getting diluted away now

another thing that that crossed my mind when I was pondering these ideas back in

the 60s was why if that is such a

powerful idea why is it that we take a very powerful idea like a computer and

dilute it immediately in most programming languages divided by

dividing it up into data structures and procedures data structures don't have

the same power as a computer they're static can take on marks but they're

once once you get a data structure it just sits there procedures don't have

the same power as computers because they can't remember state they have to have

something additional so what we did in the guise of following standard math

mathematical notation in the 50s when Fortran was developed was to mimic

standard mathematical notation without thinking about this basic principle of

recursive design because people didn't write recursive programs back in the 50s

and so the baby is thrown out with the bathwater almost immediately in a

standard procedure and data structure language and it occurred to me and other

people who are thinking about these ideas back then what if you didn't do

that what if the only subdivision you ever made in a programming language was

a subdivision of a computer into a computer you're never allowed to

subdivide the computer into something that was less than the computer and what

does that mean that means that each subdivision has to be something like a

black box that has inside of it some

mixture of State and process from the

outside you can only invoke behavioral attributes

rather than invoking method attributes

and what I mean by that is this is something that was even in Fortran

because the earlier designers of Fortran realized that there is a very funny

correspondence between procedural things and data structure things so for

instance when you say Si and parentheses

30 close parentheses in Fortran you

can't tell by looking at that whether you're invoking a function or whether

you're accessing an array and that was not accidental back then because of

course they thought of arrays as being a kind of a function and they wanted you

to be able to write arrays huge tables

still done today in order to do

functional evaluation very quickly what they didn't realize is that you wanted

to be able to trade-off between the two but that notion of just saying sine 30

degrees without indicating how its to compete be computed is the essence of

the kind of abstraction that that object-oriented programming is all about

it's carried very far here by

this strong membrane of the object so that what we're dealing with here are

behaviors and there are two important

implications that had to be worked out early on one of them is that messages in

most cases can't be commands or you're

violating the notion of the object as being in control now most

object-oriented systems today when you do what is called sending a message you

are issuing a command Objective C C++

even small talk eighty all of those systems a message is actually something

very very close to if not identical to a certain kind of procedure call okay but

in fact in the original scheme and we can talk about the implications of why

this is a good idea later in the original object oriented

systems that were so successful messages aren't commands at all what they are are

desires I'd like to have this happen just to

give you an example of why imagine we have an object masquerading as a

critical system file and the question is

it should just anybody be able to come up and issue the command to it turn byte

5 to 0 now it's done all the time but in

fact in an object-oriented system you would like the object to be able to

protect itself so that even a person who

has a pointer to it even a person who has the knowledge of which command is

the right command that both of those do

not imply that you have permission to actually change that file so in the when

I talk about an object-oriented system I mean an object in which the worst you

can do to an object is to simply indicate to it that you would like it to

do something for you and the best that can happen is it will do that the worst

that can happen to it internally as it will simply refuse it may put you may take your name

and give it to the principal later if

you've done something wrong but so this notion of absolute control that messages

can't be commands and the other one is

because the object is no longer a data structure in any sense that we regard it

that assignment is something that can't

be done from the outside either so the assignment statement has to go away in

the form that we know it as an irrevocable change to a variable or a

slot in a data structure an assignment has to be changed by something that we

can think of as being advice or influence so again this notion of

getting an object to to change its state is something that we normally don't do

in object-oriented programming because normally in object-oriented programming

we are not simply trying to imitate data structures now to be a data structure is

that thing that if you send it to

somebody else you're giving them permission to change it that's what I

mean by a data structure so it's clear that some of the things that we call

data structures in normal parlance in a

system with an operating system that offers some protection are not strictly

classical data structures by that means certain files usually have protections

on them so that in a good operating system when we send a file from us to

somebody else we are not can conveying to that person

the same level of protection necessarily that we have been granted so in a good

operating system this is this may be an operating system that you've never seen

but there there have been operating systems in the past there exist

operating systems now so that if you have a certain set of permissions for a

file a and you wish to give it this file

to your friend suppose you have the the magic permission to change the any

byte in the system file because you're a honcho then you might wonder should I be

able to pass on those permissions to the

next person that I give this file to the answer to good operating system is no

each person should get their own permission separately and when they

receive this file a it's their permissions that are granted by the

operating system that obtain not the permissions passed on to them by

somebody who had the file before so you can think of taking this desperately

important file passing it along and when

it goes to somebody who is less to be trusted with it they have fewer

permissions on that there are fewer things that they can do with it and then

they passed it on to somebody again that may go back to a trusted person that

person should be able to reintroduce

that is called capability protection and

capability protection is again another one of these old ideas from the 60s

intertwined in a very strong way with

object-oriented design that is now coming back capability is simply a

technique for protecting objects in a

stronger way than normal digital computers allow them to be done and

again at the end of the at the towards the end of the talk we'll talk a little

bit about this so to me there are lots

of different ways of talking about objects but probably 90% of the reason

to me for dealing with objects at all has to do with their abilities to

protect in various ways protect by

encapsulating various kinds of things almost always state less often control

is encapsulated and so forth then about

10 percent of the use of object-oriented programming to

has to do with its ability in whispering

to you how you might design a system better and just one more note about that

before I get started on the on the talk proper and that is that the way objects

are used today is a little bit confusing because they're intertwined with a

another set of ideas that came out of the 70s that are very similar

particularly in implementation these days and that's what's called data

abstraction how many people are familiar with data abstraction as a idea okay so

data abstraction looks a lot like object-oriented programming but its

intent is different the intent of data abstraction is to take a system that

you're familiar with like Pascal or Fortran that is starting to run into

difficulties of various kinds difficult is usually a representational ones I

think everybody's had the experience programming in a language with data

structures you get this big system done you decide you need to change your

representation and the next thing you know you're hunting down all of the

procedures that think they knew about the old representation and the rule of

the universe is that there's always one or two that you don't find so you slide

in the new representation and a couple of months later one of those procedures

is invoked and all of a sudden you have a crash and people wonder why the answer

is the critical knowledge has actually

been spread out in such a way that it can't be recovered it's like what you

have to do after you do a multiplication in order to recover the the operands you

have to do much more work like the difference between differentiation and

integration the same thing is true is once you've lost information in a

century in a system once the entropy has

gone up then it's very hard to get it back so one of the things that you try

and do with objects is to try and maintain the

as much informational content as you possibly can in a smaller place as possible now data

abstraction techniques use a similar way of wrapping an envelope around a data

structure and invoke operations by means of procedures in order to try and get it

to be a little bit more representation independent the difference though ADA

for instance is a language that is a data abstraction language is not an

object-oriented language and even the the people who actually understand ADA

don't claim that but you can do certain kinds of things that are now today

called object-oriented in Ada so this

envelope of procedures is wrapped around the data structure in an effort to

protect it but then what happens is that this new structure that's been created

is then treated as a data structure by all the rest of the program the result

is in particularly in ada is that the

programs are not small the programs aren't any smaller than they were before

and one of the hallmarks of object-oriented programming if you have any sense of whether you're doing it

right or not is that the programs are remarkably smaller because there's a way

of using the design that is not simply

imitating a bad old idea which is data structures and trying to shore it up by

putting it in an orthotic brace but in fact to go beyond the notion of data

structures so for instance in in a NATO way of of doing object-oriented

programming one typically comes out with

something that looks very much like a data structure it has fields that are to

be written to it has fields that data is to be taken out of the structure is

static there's no actual process going on and it's essentially a slightly more

abstract way of doing data typically in an object a good object will not

actually permit you to write assignment statements to it at

all because an object generally will not

look at all like a data structure just to give you an example we can contrast a

personnel record as it might be done in

Ada in which we still wind up with fields as we had them before some of the

fields might be a little bit more connected but it's still a large thing

it's still passed around as a passive object we could contrast that with an

object-oriented approach with which would be to try and turn the personnel record into something much more like the

like a real person in other words this personnel record instead of sitting

there on a file waiting to be manipulated would actually be trying to participate actively in some sort of

simulation instead of changing the person's age from the outside the way

you might do in a data record the age of the person would change dynamically as

the birthday was passed because there was something in this object that was

actively looking at the clock actively running in some sense the notion of

being able to edit the object from the outside would be much less in the sense

of editing the actual fields so objects even in a in a programming language in

which everything is an object like small talk objects tend to be larger things

than data structures they tend to be

components active machines that fit

together with other active machines to make a new kind of structure just to

give you an example of a modern attempt

at large scale object-oriented programming which hasn't been done very

much for a long time the largest object-oriented system was small talk

zone system which was even though it had

its own user interface and its own operating system and its own sets of

editors and facilities and file system

and every other kind of thing the small talk ad system that is distributed by park play systems

for instance is only about 40,000 lines of code which to me is is 10

approximately 4 to 10 times as large as it actually needs to be it's actually

kind of junky in various ways but when

you consider that the UNIX kernel it's alone is 400,000 lines of C and that is

thought to be a rather small kernel in the operating system domain you can see

that most object-oriented programming historically the programs have been tiny

the all of the stuff that we did at Parc that led to the Macintosh could be

summed up this includes the equivalent of about 15 different Macintosh

applications including mac draw and mac paint and all of those things were

summed up by approximately 175 pages of

code or approximately 8,000 lines of

code that included the operating system the user interface and everything these

programs are tiny when they're done right because of that people have been

very suspicious of them in the world for instance that you come from you know

does this idea really scale is it just for toy problems and so forth the most

recent example of object-oriented programming in the large that I know has

one done by Arthur Anderson consulting at the Brooklyn Union gas company over

the last year now Arthur Anderson I don't know how large the jobs typically

are at McDonnell Douglas but Arthur Andersen consulting typically and I

think they do some work for McDonnell Douglas but typically when they get to

work on a job their clients have already failed a couple of times and implementing it they're usually called

in at the last moment they charge twenty

to fifty million dollars a pop for one

of these jobs and their jobs typically run to about one and a half million to

two million lines of COBOL this this is

done over a period of about a year and a half to two years by a highly trained group of

people I think of as technological Marines they have a very rigorous

high-spirited training facility called st. Charles they have a approximately

27,000 people who do this kind of work

and it's a fascinating fascinating set up I'm on their technical advisory board

and I got on the board partly just because I was interested in the culture

of this particular company I was really surprised that given how successful

they've been that they have been shifting their entire set of operations

over to objects over the last five years or so it's an enormous change for them

because they have it's not the change in

going from a non object-oriented language to an object-oriented language the change of going from one kind of

culture to another kind of culture it's a change that as Koon mentioned about

paradigms the reason the paradigm shifts take 25 years or more in science is in

order to have a paradigm shift in science you generally have to let the old physicists die off once once people

have learned a technique and have gotten comfortable with it is extremely

difficult for them to go to something else the Macintosh user interface in its

early stages had that difficult people had gotten so good with function keys

that they actually felt diminished by

using the mouse even after was shown to them that the mouse is four times more

efficient in speed over what they've been doing with the function keys it

didn't seem that way to them because they've gotten so adroit with it and the

same thing is true with any technique that people use so Arthur Andersen has

done a number of different pilot projects but last year they started the

first large implementation this is a project that was a reimplementation of a

system that had been done some years ago and it was originally designed to be

done in the standard Arthur Anderson case tools and the estimate was 1.7

million lines of COBOL and approximately 2 to

two and a half years of implementation time to do this enormous system which is

both both an accounting system and a management information system and as an

experiment they decided to left a New York group which had been the pioneers

in object-oriented programming do a

implementation using object-oriented techniques now of course they didn't

have an object-oriented language to work with for their end result this was to be

done on IBM mainframes 30 90s there are

no object-oriented languages extant on

the 30 90 so they did a trial implementation to test out the design in

small talk taking a few months to do it and then wrote a set of library routines

and some pre-processing macros for PL 1 and then we implemented this project

with about 10 programmers in PL 1 so the

results of that are now in the minor

interesting thing was that they got done about 6 months early the major

interesting thing was that the amount of code that actually had to be written to

do this Amandla to 150,000 lines of this

library is PL 1 as opposed to the 1.7

million lines of COBOL that their estimates had done before so this is a

factor of 11 less code and from their standpoint the six months was down in

the noise because the the months that they're interested in are the 5 or 6

years of maintaining the code from then on and being able to reuse those modules

as they are going to be able to on other 3090 implementation so in some sense the

the fact that you can program faster that you're you can save time and so

forth in object-oriented programming in in the larger world is not nearly as

interesting it as it is in research and research basically the ability to do

quick prototyping dominates almost everything else

in the large world the world that you come from the world that Arthur Andersen

is in quick prototyping is something they'd like to do they're starting to do it but it's not nearly as important as

maintainability reusability is the

second thing if they can reuse a module as a component in some other system then

they have saved themselves an enormous amount not of time although they have

certainly done that but to them it's not time but it's designer skills the thing

that all large companies are weak on is having enough designers to go around

they're usually plenty of people to write code but the designers are few and

far between and this notion that a successful design can actually be moved

from one place to another in components is something that literally drives the

Arthur Andersen people crazy with joy to to think about so they have now come up

with an object-oriented repository and are starting to craft rather large

useful objects that can be used as standard components and building blocks

in various systems and we'll talk a little bit later about how one goes

about to me this is what object-oriented programming is about it's not saving

data structures from itself it's not making a slightly fancier data structure

it's not even making a data structure that can implement certain kinds of constraints within itself and so forth

it's thinking of those objects as independent machines going back to this

whole biological notion that it's one thing to build cells and it's another

thing to build tissues and for people

who are just starting out in object-oriented programming they're usually thrilled that they can build cells but the real goal is to be had

when you move from cells to thinking about what are the tissues what are the

conglomerations of these atomic style objects into components that if you were

to have three or four hundred of them in a repository usable by any programmer

what would you be able to build could you be able to Tinkertoy things

together could end-user programmers be

able to do a considerable amount of the programming and retailer and so forth so

the real change if there is one I think

I think it's coming faster than we think that object-oriented programming is

going to bring along is actually both a change in the way professional

programmers do their work but even more so a change in the way these

applications are designed another example for instance at Apple now we

design all of the applications that we do as though they are going to be

actually tailored not completed but

tailored by an end-user a person who has

programmed almost not at all person who's used HyperCard a few times

so this is a really big change and it's

something that has been talked about for 20 years or more but it's something that

just now is possible to actually do what does it mean well it means what you'd

like when you get an application from somebody is to be able to use it right

out of the box read them the manual understand what it is don't have to sit

down and think about it as a kit or anything but just use it the way you're used to using it now it's a temporary

solution to some set of problems you have right now also you wouldn't be using it but a month later your old

attitude about this ad this application has changed completely month later now

you're saying boy I wish this thing could do this and I wish this thing could do this everybody does that person

who's never program before is only used the computer for a couple of weeks after

a couple of weeks they'll say boy I wish this thing could do this and I wish it could do that and that's the point where

you'd like to hit the hood latch button on the application and open it up and

see something in there that was comprehensible right now if you open an

application on the Macintosh you open it up it's sort of like looking into the

hood of a Mercedes Benz or something there's this mass of tubing and if the

thing had a carburetor you find it because it's a mass of spaghetti

mostly machine code on desktop micros but doesn't matter whether it's machine

code or Fortran it's a mess and on the

other hand what the user wants to see when they open it up is something that looks like a Model T they want to see a

schematic even if there's a Ferrari underneath the Model T they want to see

a Model T they want to see a schematic engine of what makes that application

tick because they've already got an intuitive notion about how that works and then they would like to be able to

make changes at the level of that schematic engine there are a bunch of

applications you can buy for the Macintosh now in which that's possible

an example is focal point and most many

other applications written in hyper card because hypercard is a an object-oriented language set up so that

professional applications programmers can give you not just architectures not

just a kit but working architectures working kids and then after you've used

them for several months you can make the change that's going to change the whole

way we go about designing things professional programmers won't be

designing programs for each other or F at its worst professional programmers

tend to design programs that will keep them in job security there's a class of

programmer who delights in the obscure they love the fact that they are the

only ones that can understand how this program works and there's a maxim that

says if you're the only one who understands how it works you don't understand how it works and so progress

is isn't to be made there so so I think

I'm going to go into the the give you an

idea about where some of these ideas came from the one thing I think you may

be a little bit surprised to add is some of the earliest object-oriented ideas

were some of the most sophisticated and it will be revisiting them in the next

five and ten years to come one of the reasons for this is that because you

couldn't make money in computing in the 60s many of the people who

had ideas about how computing should be done in the 60s had extremely pure

conceptions those conceptions are

powerful yet today and it's worthwhile showing you a few of them

so just just as a reference point

I like I always like to start off with this slide because this is my vote for

the world's first personal computer this

picture was taken at Lincoln labs in 1962 summer of 1962 and this is a

machine called the link and it's

especially appropriate to mention here since the person who invented this machine West Clarke had a research

project at Washington University for many years

sponsored by ARPA those things that look like Dec tapes over on the side he

actually invented they were called link type tapes originally and this is kind

of a metaphor for our talk which is the

best that Dec could do with these ideas that came out of Lincoln labs as well

when Dec saw this machine in the early 60s it said boy what a great way of

making a small mainframe and it immediately adapted the the architecture

of the link to make many computers but Dec said well people aren't used to

looking at displays let's make that an option so he took the display away and

people didn't understand what was

actually on the link tapes some obscure stuff so they said well let's put files

on the link tape so I'll call him Dec tapes and out of this machine Dec was

able to come up with the astounding idea of the mini computer whereas in fact about 2,000 of these were built in the

60s and an astounding as far as I've been able to determine is an astounding

900 of them seemed to be still working today now they were designed for

biomedical labs for technicians who

needed to do their own programming and needed to do real-time experiments and

it was an almost perfect machine by the way what was on those original link

tapes what was on there were the pages of the virtual memory this first personal computer

had it's very hard to go out today and

buy a personal computer that has a real

virtual memory this machine had it back in 1962 so as an excellent idea but like

many things thought of it it actually

was so far ahead of its time that it took another decade or so for people to

catch up to it

one of the very first object-oriented software systems and one that's I think

a particularly in this talk is Ivan Sutherland sketchpad which is also done

at Lincoln labs on the tx2 computer which was the last computer in America

large enough to have its own roof and in fact was it was about four times the

size of this room and every Thursday they would take it down and change about

10% of it because they were always

putting new things it had some of the earliest core memory ever devised and

it's quite a remarkable machine for its day it was used as a single user machine

by Ivan Sutherland to invent sketchpad

and you see him here he's working with a

bridge truss sketchpad is very difficult to appreciate and just by looking at

slides so I thought I would show you a videotape of it in operation so if we

could run the first videotape take a

look and see what this again is the summer of 62 is tape number one stop

could you we I thought that was rewound could you rewind that please

and then show it

now back then they didn't really have computer displays as we know them today

so that tx2 here is actually simulating the lines by drawing dots rubber band

technique that you've seen before now here's something that I even invented which is he's pointing at the edges and

telling sketchpad he wants them all to be mutually perpendicular and sketchpad

just solved that problem we see the sketch pad is the first system to have a

window the virtual paper he's drawing on

is about a third of a mile on a side

here the constraint was make the lines parallel now the constraint is

collinearity so sketch pad wasn't just

the first graphic system was also the first non procedural programming system

so everything is controlled by non

procedurally giving goals that the system has to figure out here he's

making the guidelines invisible to get some dashed lines

so he's made himself a flange now he wants to make a rivet and this is why it

was called a sketchpad that you didn't

want to have to be precise he wanted to be able to just sort of sketch things

he's gonna use that as the center for an arc and now he's going to again point to

those and say make them mutually perpendicular that pulls the center

which pulls the arc which makes it symmetric which makes the rivet because

of the way that program is implemented you can actually see it solve the

problem there's actually quite

sophisticated this is a nonlinear problem that's actually solving

so no matter how he distorts it it comes up with the same general shape and he

could constrain the ratios of the lengths if he wanted to now what he's

been working on there was actually what we today would call a class he called it a master and this is an instance of that

Rivet can make it larger or smaller

so he wants to latch it into the flange here you can see that this program

rapidly led to better display designs

these are other instances of the rivet and now he goes back to the master and

says well let's make those guidelines invisible so it looks more like a rivet and we see that the instances

dynamically feel that change so these

are not copies but actually dynamic instances

okay and now he shows that any constructed thing can be a master so he

had made the plan for the rivet into a master now he's pulling instances from it and rotating them and changing them

and so forth

okay if you stop that tape please so

sketchpad even today is an amazing program you can't buy a graphics system

that is nearly as as good today in the

sense of it being a comprehensive system for allowing you to set up problems

allowing you to solve problems its implementation not just its appearance

was also object oriented and the style

was something that Ivan settlin came up pretty much on his own because of the

difficulty in dealing with many different kinds of objects and having

them solve constraints and being able to make pictures for them of themselves and

so forth so he got interested in this idea that each object could actually

have its own drawing procedure embedded in it and all you had to do is be able

to send the message draw to any of the objects and it would invoke the correct

procedure although would be a different procedure each time and the same notions

were later used for constraints now I

once I asked to Ivan I said Ivan how how

is it possible for you to in one year just by yourself come up with the

world's first graphics system the first non procedural programming system and

the first object-oriented software system and he said to me well I didn't

know it was hard

fortunately didn't and actually it has it has barely been improved on since

there have been some improvements since the system called thing lab done at park

about a decade ago or so was an improvement on it this whole area of

constraint driven object-oriented

programming is something that is a hot topic in research right now and I think

for the first time in twenty years is actually going to yield some fruit over

the next five to ten years the reason is is that people who do mechanical design

particularly such as you do here at McDonnell Douglas require now for the

first time serious simulation of the

mechanical design particularly how it articulates with other parts of the

design really want to have a simulation job-shop built into the design system so

you can do a lot more than just finite element analysis but be able to do

analysis of linkages and other kinds of situations that are too difficult to do

simple in analytic solutions or do finite element analysis and the answer

to this is a kind of constraint driven object-oriented design the sketchpad

actually invented the first kind of so let me give you another example I'm

going to go to the number four tape this

time though

okay okay I'll pause well had some

interesting questions actually one of

the things I should have mentioned at the beginning is I'm perfectly happy to entertain questions that at any point I

believe that the the we have an hour and

a half that the at least an hour of the

hour and a half I think we should spend talking about issues that concern all of

us about object-oriented programming I have some of my own people who are

starting out on it may have some crap you the trepidation they may wonder

where it's going what the actual leverage is I had a a question asked

again about the difference between abstract data structures and what I

think of as a real object-oriented style another question was asked about is

there any way of preserving already written COBOL and Fortran code in an

object-oriented fashion so it doesn't

all have to be thrown away and maybe

that last question is one that's worth while answering now a lot of companies

are trying to figure out what to do

about object-oriented programming particularly given that there don't

exist any good object-oriented programming languages for programming in

the large small talk is not a good

language for programming in the large as it's currently distributed it's a great

language for learning about object-oriented programming because it's

written entirely in itself and so you can learn how an operating system how a

user interface how applications how little things and

larger things can be represented in an object-oriented form how inheritance

subclassing and so forth all those things small talk is ideal the of the

small talks around to look at the one

that has the best manual is the one called small talk V and it runs on both

the IBM PC and the Macintosh it's not

the mote it's it's a rather complete system in in a number of ways the other

system is called Park Place small talk small talk

8e and it is sort of the granddaddy of the small talks that that Xerox has

released it has a even more complete set

of system tools and some very ambitious

applications written in it both of those are worthwhile looking at

but for programming in the large objects

aren't enough I don't believe and the reason is that at some point it's not

simply a matter of piecing together something that is supposed to run it's a

matter of being able to verify different

sections different parts different modules independently to be able to

unplug and replug and even I think in

many cases it's desirable to allow different implementation languages to

actually be used now if we look at the

the standard

so we have a glob and the main principle in object-oriented programming is to

separate the outside from the inside so

on the outside we have a variety of

messages that we're willing to respond to and on the inside we have some

methods oh sorry

we have some methods the may or may not

correspond to these things on the outside cuz whatever the idea is we're

not supposed to understand what the inside looks at from looking at me on

the outside and outside thing might even correspond to a little data structure

inside a thing equally innocent might

correspond to an enormous amount of code there might be code in here not directly

connected to this and in fact some of the messages that the object may be able

to receive aren't directly characterized in terms of some outside protocol lots

of different variations here but the most important one here is that we're

trying to separate a protocol

from some methods

at this level and then if we think about going a little bit more fine-grain where

we started having zillions of objects interacting

in a sea of messages

in fact some of the

some of the objects might not even be on the same machine they might actually be

over here a good object-oriented system

you shouldn't be able to tell what machine you're running on that's what

messages are all about very quickly when

we're starting to build a large system down here we've got something

interesting we have absolute protection but we still have confusion right

because it's you can have thousands of

thousands of diamonds that are impervious to all normal wear and tear

and still not be able to build the simplest structure out of them they may

need to be too shiny may not be able to pile them up they may not fit together

but by god they're perfect so what I'm

trying to say is that the the protection issue is a critical one but it still

doesn't guarantee that you actually have an architecture now in small talk in the

most object-oriented systems how you come up with these guys is govern very

much by convention there's a particular

way like it's a convention in small talk systems that one of these guys will always be called print so that for every

object in the system you're guaranteed that one of the messages you can send to

it is print and theoretically what that

means is this little patch of green in

here that corresponds to print is

supposed to print for you now there's nothing in small talk or any other

object oriented system right now that guarantees that printing is going to be

done now there was a strictly conventional it's something that

everybody agrees to it's like overloading operators in Ada when you

overload plus in order to give plus more

meanings for different structures you're usually trying to adhere to something

metaphorically similar to what plus originally stood for so for instance if

you have a plus a plus it adds two numbers together you might overload it

to apply two arrays so that the operation is some sort of point point

point addition maybe vector addition sometimes you might overload strings -

what could + mean and strings well one of the one of the ways of thinking about

strings algebraically is that plus means concatenation because it's a way of

adding two unary numbers together and so forth and at some point you started

stretching it as you stretch the metaphor but generally you don't want

Plus to go off and do some sort of multiply or something else but the only

thing that controls that is some agreed on set of conventions and because of

that what this protocol is how complicated it gets and so forth is the

most important part in any kind of object-oriented design but it's also the

most fragile the fact that there's

nothing to protect print is absolutely

critical let me let me give you an example of what we could do to protect

print

one of the things we could do is to have

instead of having print just be code we

could actually have a print class

and its offspring its instances are

actually structures that look like this

okay in other words each offspring of print is a message method pair in which

unrestricted code writing over here is not allowed does everybody understand

why this is an interesting idea because

so but if you could only if you can write anything here then J random

programmer often will as you go as you

go along and the fact that the system seems to be conventionalized at this

protocol message level which is the very

charm of object-oriented programming why object-oriented programs work so well why they fit together gets destroyed as

the amount of generic information in the

actual methods gets diluted but if

another way of doing an object-oriented system is to actually make classes for

each of the major code types that you're going to write and what you get here is

something that would insert itself in here but in fact the only codes you're

allowed to write are certain little restricted boxes in here and this thing

guarantees that it's going to print for you it's not going to go off in zero

byte five of some system file this thing

because it came from a print class and because the print class does printing

type things every piece of code that goes into a protocol actually is going

to do something like printing and what you're allowed now is a certain amount

of parameterization a certain amount of freedom but the meaning of print now has

been nailed down because there's some actual code from the print class

sticking behind here that you can't see that's going to make every effort to

deliver a result that is what you want this is like types in type languages

except it's stronger because it can controls the goal of the result the goal

of the result not the shape of the result right in a typed

language when you have a typed variable or type procedure what you can state is

that might have some integer parameters and I'm going to deliver a

floating-point result what you can't say

in the type statement is what the intent of that procedure was the only intent

that you could indicate is that's going to in it's going to give you some sort of floating-point result you can't say

it was supposed to give you a sine or cosine or anything else that is up to

the convention of the actual programmer

itself so what I'm just pointing out here is that if you take a if you take a

system in which there is a protocol you

can get a lot out of it just by having the protocol be a convention agreed on

by everybody as you go into a larger and larger system that that inside out

outside Ness will protect against the inside getting dissolved by some hostile

act action by the outside but what will get diluted as you go to a larger and

larger system with more and more programmers is whether the protocol is

going to have any meaning practical example in small talk has approximately

Park Place small talk has approximately

5000 of these green things each one of

them is there each one of them can be reused by inheriting it from somebody

else the number of red things it has is

on the order of twenty one hundred that

means that the amount of how generic the

code is with respect to the protocol is not much right it should the number

should be more like 400 or so different red things four hundred concepts and say

five thousand realizations of those concepts now print is the happy exam exception to

that because if you have a 154 different kinds of objects than their 154

different green guys and only but only one print concept so there's the same

technique that people use overloading of operators for you want to reduce the concept space by making it more

algebraic make take a concept make as

metaphorical as you possibly can and

like equal is a good one what does equal mean some systems that

means we have I'm looking at exactly the same thing some systems it's okay for

the same if the same things look the same some systems is if under some

particular evaluation rule they evaluate to the same thing or they might evaluate

to the same thing so equal is one of these very slippery notions because it

very quickly becomes useful to think of equal as being very useful in terms of

equivalent this is equivalent to that

that's a generic notion so again you might imagine that one of the one of the

things you might like to have be generic

are comparisons equal equal is a much

stronger one of course than greater than or less than because greater than less than involve some sort of sorting but

again greater than and less than don't have to apply just two numbers in small

talk there's a super class called magnitudes and anything that can be

sorted in any way under any kind of sorting rule is underneath magnitudes

and underneath magnitudes are things

like less than and greater than

so for instance dates are an example

times time intervals anything that can be sorted in any in any form you can

those what you might what you would call operators in a de or automatically

overloaded now what happens in an

object-oriented start off with a nice set of these and then as practical

programmers chew on it the heat of debugging one of the things we

discovered is that even good programmers don't make up generic operators for

things what they do is they make up any old word think they can think of at the moment write a method for it and

continue on the result is that what the

object-oriented style was buying for you starts diluting it starts gradually

diluting away the manuals get larger and

all of a sudden you're back to something that is close to what you had before so

I'm not I'm not sure if people didn't understand this explanation I'll be glad

to go over it again because it's it's

it's one of the important examples of something that you can actually do with an object-oriented system everybody more

let's get what I was talking about that you can actually legislate one of the

things you can do in an object-oriented system is to legislate to some extent

even what the code that the programmer is going to write is going to deliver to

you you can build in to these main

concept classes the tests to see whether

the code is it all behaving the way you think it is those tests can be run

independently of the programmers who are writing the code now another thing you

can do using these protocol ideas is

horrible as it sounds there's no reason why you can't put some COBOL in here

this is not something that people do in

a typical object-oriented language like small talk because it's designed to to

write all of the methods in itself but if you think about this whole notion

here as a binding mechanism for a component not just as a way of

protecting a data structure but a binding mechanism as a component then

what you really are programming in terms with is the blue and the red what the

green is is almost completely independent as long as it conforms to

whatever this guy wants it to be able to do what I advise large companies when

they are embarking on object-oriented programming is to do a few systems using

something like small talk or preferably just to get an idea of what it's about

but then think of all the things that you've already learned about controlling

modules and systems and realize that the

small sizes of the code of the small talks from the 70s don't have all the

protections in there that you actually need what you really need is what these

days is called a configuration language a C language configuration language

and this language can be independent of all of your method languages it's it's

something that is dealt with it the operating system-level it's something in

which the protocols are chosen as much as possible ahead of time it's a

standard vocabulary of concepts that you're going to use to write in it's one

in which the protocols are controlled by active code the give you places to write

code and insert other code that allow you to bring over a COBOL routine or a

Fortran routine or whatever the heck you want and bind it in it's a binding

mechanism it's a way of setting up

environments for debugging modules

independently of each other it's a way of assuring yourself that a module will

be able to move from one place to another it's a way of discovering

whether you want to use a module so at

some point the ability for human to read this configuration language is going to

be much more important than the ability to write it one of the embarrassments

that you often find in an object-oriented language is you have all

of us we have usable code and it's too hard to find the modules you want to

reuse small talk has a lot of that flavor anybody who's ever tried

programming and especially in small talk 80 is bewildered by the fact that the

system is completely written in itself there are tons of usable things in there

and yet it is such a pain to find those things you wind up tandem out having to

read other people's code and then in order to find out whether you actually

want to use the stuff so the for instance what Arthur Andersen is doing

right now is to try and come up with

something that is completely independent just completely x-out forget about the

interior stuff just come up with something that is basically modules in

terms of blues and Red's making the the

red message protocol be as powerful as possible controlled by other things and

then using that as a dynamic binding mechanism for

configuring programs it allows them to

take large sections of database and

sequel calls that they've already done and bind it into an object-oriented

framework as an example yeah yeah

so configuration

let's start off with the things that you might want to have in it now the there's

only I only know of one actually good configuration language that's been done

as a language called C Mesa which was

done by the Parc computer science lab

about ten years ago and it served

exactly this this purpose and here are some of the things can have it there are

some things that you'd expect just from your previous experience you'd expect

that there would be some sort of message name for something you'd expect that

there would be I Oh parameters so that

you would have input expectations

output expectation

a good configuration language has a an executable predicate you can think of as

a goal that they may have a variety of

them and I connect those with when I say

input expectations I mean not just the

types of the parameters that you expect to send to it and the types of the

results but also these predicates sorry

predicates you can think of

preconditions on the input side and goals on the output side

you can think of those as being executable there are environmental

expectations

one of the difficulties in most object-oriented programming languages is

although you can protect an object what

you don't have any sense of when you want to move an object is what the

object itself expects to have as environment as a give you an example in

small talk you can write an object move

it for one place of a particular Smalltalk system to another but when you

want to take it out of your small talk system and give it to somebody else a small talk system you often are

unpleasantly surprised and it's not that

the object has been solid in any way it's that it has some other assumptions

about its environment that you weren't thinking about before in particular

small talk allows you to do the somewhat obscene thing of allowing you to go and

change existing super classes to make them more the way you like the benefit

of this is that every class and the system feels this improvement and the

problem with it is if that improvement is important then you've all of a sudden

have done away with your portability so what I'm trying to point out here is

that the modularity you get in object-oriented programming is slippery

and one of the most critical things to do is to be able to pin down the amount

of modularity that's actually there I'm gonna I'm going to go into that in a

little more detail so the there are more

things that are here people have design

configurations languages in such a form that you can actually from the runnable

parts of the stuff that you can actually derive an explanation mechanically of what the method and what

the module itself is supposed to do

okay so there are any number of things

basically it's something a little bit more close closer in spirit to Parnas

they've partners who did one of the original notions about information

hiding although it wasn't object-oriented than what you might think of as straight object-oriented

doctrine and that each one of these these things is part of

this blue

no Sheena that this forms a class from

which we get the various instances that

our system is actually made up of so each each a little instance

now it is often the case that if these

two predicates here are done correctly you can actually run you do your

prototyping by running the blue thing essentially without any green things

inside of it or you can think of it

being just tiny little green things that come along because of what these are yes

okay the this is it's similar to ADA

except that ADA for instance doesn't have inheritance and so does everybody

here understand what I'm not sure I didn't come to give a tutorial so I'm

not sure what I'm what I was supposed to assume everybody knows about the thing but in most object-oriented languages is

this notion of inheritance that you can

define something very general and abstract like

say a thing called a magnitude

in a magnitude maybe something even more

abs I mean let me use the fresh sheet of paper

start off with something really abstract like a general object and then one of

the operations and an object you might want to have for every object is

equality then a little less abstract you

might have something called a magnitude

one of its operations might be less than

but there still that might not be any notion of what addition is coming down a

little bit further you might have something called a number and it might

have a notion of plus and there might be

a various specializations of numbers so you might have an integer a fraction

these guys might have their own versions of plus the notion of inheritance is

that very often you can get a compact

sorry you can get a compact description

of a wide variety of behaviors by

factoring out behavior as abstract li as

you possibly can you move it as high as you possibly can and occasionally you

may have to give your own versions of things like integer may want its own

version of what plus generally is it may

even want to have its own version of what less than is or may be able to use this general one up here and but

inheritance actually allows you to

cascade descriptions and in a number of

object-oriented systems particularly the AI ones you can actually blend them

together in various ways so you can actually say this this thing is not just

a number it is also a geometric object and inherit a bunch of things from the

side as well so what go to when I talk about doing the

configuration stuff I mean to imply all

the things that you usually do in a typed language but also applied to a

system that has inheritance because it's inheritance in object or any languages

is how you share things the goal of

release it has been the goal for the last 20 years of people who do this and

write very small very reusable very

compact code the goal goal is to make

the things that are shared as abstract

and inheritable as they possibly can be

so you want the smallest number of

maximally independent concepts that you

can Tinkertoy together and have some confidence that the active Tinkertoy is

going to give you something that also still works the whole idea in

object-oriented style is to linearly combine things together not a native

package allows you to subsume some of

the details of a data structure it does

not allow you for instance to define

generic operations which are then

inherited by subclasses because it simply doesn't allow you to subclass and

what that we leaves you add is a single single layer of description for

something which you can get instances from but you can't you generally Eneida

do not write an abstract thing that you're going to get in instances from

because usually these very abstract types like magnitude and so forth aren't

things that you want to use directly they're really placeholders for general

code and strategies and this is a foreign idea in the in the aid of

programming world which is almost entirely concrete yes

well I do to an actually ADA shouldn't

even really call them generics from but it's yeah it's okay anybody can use a

name for whatever they want but it's that's a it's a different way of

thinking about what generic is than what I'm thinking about here the generic power in an object-oriented programming

language is your ability to not just

reuse a concept sideways but also to advance it abstractly the more you can

advance it abstractly the more chance it has of being involved in in an abstract

design the less probability you have of having to recode whole strategy here's

is true is to avoid recoding remember we

got off on this thing I'm just pointing out there's just really just an aside

remark that you could make a very strong

object-oriented programming language by being completely independent of whatever

the methods are actually coded yet that was the whole point behind that

digression that as you build yourself object-oriented tools you're much better

off worrying about the integrity of the

individual objects and then the next thing is can an object be a component

and fit into some larger scale protocol

when I say a component I mean something like let's say a paragraph of text or

generic gear something that actually has a fair amount of meaning behind it might

even have its own inference engine as part of it talking about something that

can be used in a wide variety of cases in which the sharing is more than

parametric you're really getting not

just a class of things you're you're sharing a notion that somebody has come

up a concept a set of concepts that somebody has come up with this obscure

it's the hardest it's actually the

hardest thing to explain simply because I'm gonna try another pass at it one of

the reasons it's hard to explain is that the this notion because of ADA being

called object oriented being taught in school as being object oriented actually

has clouded the the issue considerably so it's very difficult to even explain

why some of these ideas are more complex let me give you another completely

different idea this has to do with

another way of thinking about modularity now in most object-oriented systems the

modularity that is gotten by them is one

that is regard to the state that you put

in each each object what isn't modular is the control

this is another set of issues to talk about so for example one of the things

that you may see when you're looking into an object-oriented programming is is you may see the state and each neatly

encapsulated but you may see control going all over the place what happens

when you send a message the answer is often I don't know goes here goes there and find somebody

here talks to this guy dozens of things happen and I can't even tell whether

control is ever going to get back to me that's often the state of affairs now

what would happen if we actually made control modular

we'd have something more like this where

instead of control going through the objects the objects themselves are

sitting in a sea of messages but they

don't actually originate them themselves how is that possible well one way you

can imagine for it to be possible is for the objects to simply say I need to know

the following put needs in here

now the object there are object-oriented system is one of the ones we've just

developed at Apple one that we did at MIT is an object-oriented system in

which you never send a message okay you

only receive how is it possible well the

system contrives to make the messages get to you by looking at your needs and

looking around to see who might supply those needs

okay is this obscure okay so an example

is suppose your

suppose you're a a button whose job it

is to move the corner of a window so one

of the ways of programming that is for

you to be in a loop constantly looking

to see if the mouse is coming into you okay it's a polling solution to the

problem where somebody is polling somewhere but you're constantly looking

to see whether the mouse is coming in when the mouse comes in then you say okay now I know what to do I'm going to

latch on to the mouse's coordinates and I'm going to tell my window owner

exactly how he should be moved around and so as we move around the corner the

window corner moves around itself and so

that's that's this kind of style of programming control is explicit we have

to poll to find out things that are going on the other way of doing it is I

could just say I need to know when the mouse comes in to me and then I can do

my job this is like an on condition but

it's an on condition that has to be scoped because we can't have it

happening every time the princess the mouse button goes down but we can

imagine that this guy can say okay I have a set of conditions I'm not going

to explicitly look for it I'm just going to tell the world that if I had these

conditions come true for me then I would be able to fulfill my

obligations to the rest of the system I'd know what to do likewise the window

that encloses this guy could also have a

set of conditions that say well if the corner if my corner guy starts moving I

should probably move too I'll change my size if he moves so if

only if somebody would let me know that then I'll go along see what this is like

this is like constraint programming okay we're going from

a procedural style which controls past

explicitly around to a declarative style in which were simply indicating needs

and the system without having to do any problem-solving is picking up the slack

by providing the actual information in the forms of messages HyperCard has this

about half way it's a technique we've been experimenting with at Apple for the

last couple of years and what it looks

like it's able to do is to completely

remove the necessity for actually being able to follow a control flow what does

this mean when you move an object from one place to another

when you move an object from some place into this kind of situation nothing is

going to happen with sorry kind of a

tiny screen isn't it and you put in when you move a new object in here in this

kind of situation nothing is going to happen to that object unless you go in

and recode somebody else in order to send it some messages right and so my

modularity of being able to move an object from one place to another depends

on me being able to do some kind of modification and the system is already

there that's not so good it's good in the sense that this object is guaranteed

not to hurt anybody and it's going to protect its own self from being moved

around but in fact I still have to go in and make some sort of modification in

order to get control the flow when I

put in a new blue guy here

and he has all his needs specified is he

going to be able to run why

because he doesn't have because the whole idea is that he's not intertwined

with anybody else's control he's simply saying I know what I need god damn it

then the question is can the system actually deliver those needs just

because he's a new thing and the answer seems to be yes this is a peek into the

object-oriented programming of the next couple of years in interesting you know

if this the need to do things this way came out of yet another project with

children all of the object-oriented stuff has developed at Park and the

Macintosh user interface came from a set

of designs to try and allow children to

do serious programming on a computer that was what forced object-oriented

programming out into the open the last set of stuff that we've been doing with

children at Apple forced this out of the open because we wanted children younger

than nine to be able to program and children younger than nine have a very

hard time following control flow of course when we're thinking about that

we're thinking well of course they have a hard time following control flow so do we except where you see the problem is

adults are used to suffering so it's why

I like why I like to design for children so designing this new programming

language for children I'm going to give you a little example of some of the stuff programmed in it this notion of

making control completely modular by going to a needs thing became apparent

yes

yes

yeah well it's complicated because I'll

give you I'll give you a simple example and then maybe we can generalize it a

little bit the motivation came from a couple of years ago of you know

wondering why it was so easy to program in spreadsheets and wondering what

spreadsheets would be like if there are more object oriented I've always thought of the spreadsheet cells as being almost

an object and spreadsheet cells have this nice characteristic that they they

are these aren't they in other words the

very act of writing the spreadsheet expression indicates to the rest of the

spreadsheet system what your needs are now usually they're pretty simple needs

they're just I need to know the values of so-and-so cells relative to where I I

am but I got interested in generalizing that and started off with a spreadsheet

system that I did in small talk that had

a spreadsheet optimizer that first started off simply trying to look at

places you wanted to get values from and building a propagation network rather

than executing every cell every for every change in this especially I think

most of you were aware that most spreadsheets today do not execute every

cell there's a propagation network built by the spreadsheet compiler that you

don't see that tries to find you the

minimal number of things that have to be executed every time the change is made

in the in the spreadsheet I started working on that and then the next thing

is to go to billions where you're interested in whenever something like

for instance whatever this is equal to that I would like to do something or

whenever this is less than that I'd like to do something and the I'll just give

you a hint of it

so they start out with this fairly

simple idea that if you have a variable somewhere one of the things that you can

do is to link you can have a link to all

of the different places that ever need

the value of that variable and when this

changes you simply fire off all of these guys and you get the desired result

let's take an expression now so we take

an expression like a is less than B or C

is greater than equal to D and then ask

what we'd have to do to that to make that efficient the answer is you make

this thing into a little tree and at each stage each node of the tree you

hold the very the value of the things so

far

so in this case the a value would be linked through here and you can think of

the tree is pointing upwards

okay and we can presume that this let's

make this an just for the heck of it

see that this is false and we assume that this is true and that this is false

let's do it the other way I make this true

this false so the idea is now if it

changes the insight here is that all you have to do is compare it to whatever the

current value of B is let's say this goes to to true you don't have to

recompute this guy because it didn't change it's already part of this frozen

result and then you come up and recompute this guy so you bait what you

basically have done in this technique is to have sorted the actual computation

that you have to make this this tech this way of doing things is called a

continuously evaluating expression

so it's a conglomerate of things it's actually a little computation engine designed to compute in parallel and only

the stuff that needs to get computed gets computed so you the computation now

the compiler instead of compiling machine code in a system like this is actually compiling a propagation people

are interested in these techniques I refer you to the books on functional programming mostly being written in

England these these days functional program is about this and well-behaved

functional programming languages have the property that you can take any computation that has variables in it and

through a fairly simple compilation change it into a network that has no

variables whatsoever but simply routing x' for values does that sound please

please interrupt me if that's it doesn't sound reasonable is that sound reason

it's intuitively reasonable isn't it because what does a variable as a place

you go to to get a value but of course you can what you really need in a

computation is simply a value delivered you don't need the value to be anywhere except where the operator is so by using

a combination of those techniques you can actually remarkably enough it's

actually it's always surprising when these things work you can actually go to

a thing that's an extreme generalization of a spreadsheet cell that does an

enormous amount of parallel computation but in a way in which you see none of

the interactions yourself

now because of production production system it it's not at odds with the

production system it's on this it's not like ops five as an example which is a

production system I understand people use here it's basically it's orthogonal

to whether there's a production system trying to do things or not

ops five has an example in which the you

have to order the rules yourself to a certain extent in order to in order to

get efficiency and so forth and you can

think of this as something which is independent of whether there are rules

and I didn't say there are rules here what I said is that what we actually are

interested in is whether there's whether there's a set of conditions that can

deliver to me what I actually need one of the things you could implement with

this idea is a production system I'm not

but it doesn't lie it isn't particularly like a production system you could

implement a production system using the idea though do you understand to say it just one it

yeah because it because some production systems have to be executed in sorry

we're getting killed for time we only have a half an hour so what I would like

to suggest is that we just sit still while they change the tape is that okay

should only take them 10 seconds

I was brought up about what do you do

with real time in fact what do you do with time and historically the first

object-oriented programs that were done outside of machine code were done in a

programming language called Simula and Simula had this way of looking at time

the Simula he had

a bunch of objects

one for each entity that you're trying

to model so the

these guys might be modeling pipes

and so forth and the blue the blue guys might be modeling reactors in a chemical

plant or something like that but

basically as far as seeing they're concerned they're all objects they're

all trying to execute at once trying to

get to the new trying to move advance the entire system time and they had this

problem of if you have a system time the system clock that's going on

how can you compute because you might

actually run out of time for computing

before you can actually advance to the next system time so what the similar people realize that they wanted to do

was in between the system clock so

system clock might be one and the next

time any of these guys had to compute

was two so what it would do is it would

do all of the computing in between the

ticks of the clock so the computing was actually outside the space of the simulation so Simula this is a non

real-time situation simular running on a mainframe would compute an arbitrary

amount in between each state change so

guarantee that each as much as it could possibly do it would settle down the

state of each one of these objects during this time when they were all in

process as soon as that that had happened then it would say okay now I

can go to the next time on the clock it is now - what do I have to do now then

the clock could be frozen would compute like mad again advance the clock again

now of course there's a huge conflict

that's the way you generally do it when you're doing object-oriented program

huge conflict between this and when you want to do real-time things because um

real-time things you don't get to stop the clock the clock is moving along

and of course one of the answers is if

you don't have enough computing power to compute before the next time the clock

ticks then you're dead anyway okay so let's assume that we have enough

computing power and just to ask what we

can do an object an object-oriented design to reconcile what time actually

means and the way people generally think

about time and object-oriented programming as time has entirely to do with who can view what when so it's a

viewing operation so let's suppose we have our objects here and we have some

views

attached to the objects we can ask what

is it like if one object is viewing another

the first question I just should ask everybody this is absurdly simple once

once you see it but the first question is when should I not be viewing the

object when it's in transition right so

it means I have to have at least a two-phase clock so the object really has

two two states it's going in one is it's trying to settle itself to what it

thinks as a stable state and the other one is one that's going to allow itself

to be viewed okay so mmm let's we can do that and

it's sort of a sort of a diagram here

so here's the here's the object and

here's the view so what we're saying is

that when the object is computing we can't view and when the object is

viewing we can't compute

so we're gonna have a bunch of these little phases like this now that's not

always useful sometimes this viewing

thing is very long so the viewing can

actually hold up the progress of the computation and so what can we do there

this is suggested by actually this model so far just just curious to see if it

suggests anybody what would be a good thing to do if to break this rigid

synchrony we have what can you do yeah

we could that's what's called slippage so we could actually arrange a slippage

model so we let the as before as we had

before we let the object compute and

what we take is a copy of it that we let

the viewer view

and so the object in simulation can have an quite a number of phases as it goes

along and every once in a while we get

to view it

we take let's say we take this guy right here okay now what's interesting is in

an object-oriented system this slippage model is usually computed automatically

by the the object in the view both of

which are objects when you hook the view up to the object what they do is

exchange information because one of the things that the object has some sense about is how long it takes it to settle

it state typically the view has some sense about how long it takes to

abstract the view and so they actually arrange and build a little buffer in

between themselves and that buffer has the actual amount of information to

allow the slippage to happen so the way this intertwines with doing real-time

and deterministic computing is almost all real-time solutions to queuing

problems knowing some sort of determinism they actually aren't

completely deterministic what you usually do is you're saying I have some

limits that I want to guarantee the

computation is going to take place in between it I'm going to do enough buffering to make sure that those limits

get down so for instance when you're doing real-time reading of records from

Fast disks and so forth you set up buffer areas because you don't want to

have to have real kind time constraints in every part of your real time

computation in an object-oriented system these are usually handled by having

what's called a viewing model small talk has one called models views and

controllers which is quite general and has the facilities in it for generating

all manner of slippage models in between by you putting on the outside what it is

that you actually need to know from these objects at some point of course

you can break it down there's no real time system you cannot break down but

this gives you the maximum amount of automatic buffering that the system can

generate without having to be explicitly programmed

yeah very very large how can you well

the way that's usually done is by trying to again it's that you know the stuff

isn't a panacea but what you usually try and do is when you write a device driver

in an object-oriented language what you try and do is ask what devices are

likely to be like this device now what is this like so when you write when

people do a user interface and an object-oriented language usually they

don't write a driver for the mouse or for a tablet or anything else what they

come up with is an abstraction of what it means to it's usually call a pick

device it's an abstraction of what it means to be able to do selection and

tracking and then one programmer at one

time writes code for that and then if you come up in a system and it has a

specific device you may have to write a line or two of additional code but it's

written in a subclass below that the main driver is already written already

been written in it's um it's not just doesn't just serve as the code for what

you're doing it serves as the model for how you treat the actual devices when

they're put in there so I'm part of the part of the the charm of the system is

to be able to get away from the from the particular as much as possible and

program as much as possible in the general case the whole act of

subclassing is basically saying to something I want something just like you accept and the theory behind this which

seems to work is that it is much easier to program differentially than it is to

program from scratch it's much easier if you see something that is like what you

want and you can get it in a way that um doesn't damage anything

else then if all you could make have to make as incremental changes to it then

you should be way ahead that's not always true you know there are always

pathological cases always pathological cases but generally speaking like this

is an example where the whole strategy once it was thought out was realized oh

yeah this is something we can use it's not just for user interfaces we can use it for every kind of device drivers we

can use it for every kind of real-time stuff where we have two different clocks

going at two different rates and we're trying to synchronize in some way why

should we have to write this over and over again why should some program we have to figure it out over and over

again it's not that we have the solution to every possible problem but what we're saying is we've got a solution it's the

80/20 rule get a solution to the eightieth you know 80% of all of the

code you're ever going to have to write if you can put that into a superclass

and then distribute it automatically as part of the solution so small so small

that when you when you're doing a viewing operation and small talk you

don't even have to think to yourself whether you should worry about

synchronization or not until long after

you may decide that you need it then you just have it oh it's already in here I just got it for free when I subclass the

class view well try think like I say an

ADA it's a little bit harder because you can't do those super classes that have

all those goodies lying in there you have to you can do it with a macro

operation people do to super classing and ADA by making macros that allow them

to do a kind of copying and stuff

No well in small talk no you can small

talk allows you to dynamic basically small talk has no concept of loading

code so everything is there dynamically into there and at any point

you can go in examine any piece of code in the system you can rewrite any piece

of code in a production case you really don't want to allow just anybody to go

in and rewrite a superclass because of

course the work it's really bad if they if the superclass starts doing something

different generally when people go to rewrite a super classes to improve the algorithm

that hundreds of applications are already using like you may go in and

improve the sort algorithm yeah

right that's why I was talking about the

configuration so my belief is that in a production case you must have something

like the configuration setup or else

it's just too fragile it's not it's it's

fragile in a funny way because in small talk we used to give $5 bills away to

anybody who could crash the Smalltalk system it's very hard to crash an a good

object-oriented system because there isn't anything you can get to that where you can actually hurt more than one

layer of thing and then the system's says hey wait a minute what are you

doing like in the small talk debugger as

you'll discover I think there's a tutorial coming up has the anytime

there's any kind of an error the system

doesn't crash there was there's no concept of crashing the error is simply

set aside as just another process and once when we were debugging the system

we found 1,700 suspended errors waiting

for somebody to take care of them and so I'll talk didn't care you know it's just an error comes up fine you know um set

it aside it's right there you can go back to it anytime you want but keep on running it just keeps on running so the

that's one of the reasons why we didn't do a configuration language because we

were programming in the small and you couldn't hurt yourself so as the the worst he could have

happened was something annoying they would come up but it wouldn't crash what

you're doing so somebody who fixed it or make a note of it but I think that's

intolerable in the production sense

where you really don't well you have people who aren't part of the same group

and so forth that you really have to have a configurations language and the super classes are the ones that you want

to have most understood and most nailed down in particular the for instance in

small talk it's often to make things like the sorting stuff parametric so

you're actually sending in sorting objects that will do sorting for you

as parameters rather than even putting

that in embedding that into the the code just because you don't want somebody to

try and change it that way you'd rather have it be something separate that you

can dynamically bind in really good superclasses don't do much except act as

really good binding mechanisms for other

stuff that's going on

yeah

yes there is you can but again the the

original the original small talk for example didn't use a kind of procedure

call in order to send it really acted as

though you're on a network and if you're interested in what order things had to

be done in they they could actually be stamped and recued at the other end and

people do do that when when you run small talk over the network people make

the connection to the network by having what are called phantom objects and a

phantom object is a stand-in from the object you're trying to send the net right because you're always sending a

message to something so suppose yours suppose your

so if you're over here and you think

you're sending a message what you think you're doing is sending a message from

object a to object B and but they may be

on different machines and so what may be really going on is object a is sending a

version of object B

which is really going over the network to the real be again these are called

Panem objects and usually there's just one class of them and whatever you're

distributing a copy a computation usually the environment for the objects

just consists of a few local objects and

the rest of them are phantom objects the phantom objects take care of all the the network stuff and synchronizations and

reorderings and other kinds of things that you have to do when you're going to slower slower media that's a

well-established technique and any good object-oriented language you can set

that up literally in an afternoon today

oh it's quite instructive to think about what it means not to send just a message

but to send an object from one place to another what part of its environment do you have to bring along with it in order

for it to be understood see in theory sending an object let's say we send

objects see across

well si may not be terribly understood

on the other side on the other hand it's still active so if your network has the

rule as ours did it park that whatever an object shows up and its class isn't

there its class a clone of its class

gets sucked over with it so you compare

that to sending a data structure which is sending bits and how fragile they are

because you're not sure that there are procedures at the other end to know them here you're ensuring that either nothing

at all happens or the right procedures are actually automatically sent along

and so you can it's remember that story I told the beginning of the Vosges 220

that's exactly how the training command protected their their tapes you just

make sure the procedures go along with them and it's quite easy using these

phantom objects to make that automatic so you can think of the network of

objects as constantly rebalancing itself as to where the code actually is

I think I believe that's true and from

Park yeah it's written it's been written up

yeah well my message to you is this is the same reason I told you the Arthur

Andersen story is they have exactly the same you know their their attitude to me

was kind of interesting they said they went to several phases and this is

probably you're in one of these phases right now as well it went through one

phase where the first phase with objects it was like magic God all the things you

could do code is so small the second phase was complete disillusionment when

they realize that for instance small talk which they were using as a model

didn't scale they said you know what is you know is this the emperor's new

clothes or what and I said no it's just because the part of the reason small

talk wasn't built to scale was simply because we were able to do an enormous

amount with very tiny programs and we're

designing for children anyway and when

you want to use these ideas and they're in the in the large I believe that you

have to do a little bit more then you can go out on the street and buy that's

what I'm my message to you is that and

it was to Arthur Anderson that you know a lot about what it can once you've

learned the object-oriented style which I believe is the right way a protecting

state of the right way of making components the right way of making urns

superclasses right way of sharing there's a whole bunch of right things about it in order to make it work in the

large you then have to sit down and protect that by coming up with a

configuration language and you can do yourself a lot of good by doing that

carefully because the configuration language can include languages that you

already have hundreds of programmers that know how to write in in other words

the configuration language can be a way of protecting programs that are already

written in COBOL and Fortran as well as

new programs written in Ada it should be a really separate way you think of isn't

and the architecture is opposed to the bricks of actually building the thing

the architecture to me rules life is an architecture it wasn't

as early as the turn of the century there are people that thought memory there's the stuff called protoplasm

written about in books was supposed to

be some special kind of material that you can build living things out of because people didn't believe that

ordinary chemicals could bake you could make a living thing out of it wasn't

really until 20 or 30 years ago that it was really shown quite definitively that

we actually are just an architecture in fact we know now that the atoms in our

body are actually recycled about every seven years so you and I as individuals

are patterns in space the material is moving through we don't have the same

atoms in our bodies that we had seven years ago we are a pattern and

interesting things made out of the patterns you have - you know I have to

have some understanding of the bricks and stuff which I think everybody is getting now but at some point you'll

realize that the power of this stuff isn't from what the bricks do and that

the bricks are have integrity the power

of the stuff is from the architectures that you can create and the

architectures have just been scratched now up until really a couple of years

ago there probably been less than a god I don't know 100 or 200 people over two

decades actually doing this stuff so

it's the and the problems that have been

worked on have tended to be small the reason I believe that object-oriented

programming works well in the large is simply because it works well in the

biological world and I see no reason why it is going to fall down in any way when

we go large but in order to in order to make it work we have to either look at

the biological world war which is the

biological reason of urging can a configuration language or we have to go

after for other reasons of just realizing hey this stuff gets fragile at

this point what do we actually need and the answer is a configuration language

but I think that there might be some immediate benefit these ideas of

object-oriented design where you have existing systems that because it would

nature the islands of automation approach have gotten tremendous ly complex and you

need to be able to characterize various things possibly the concept of objects

to help you do that and to help them understand what are the objects of one

of the Linc right well I'm trying to think of it was

Rudolph's irken that said you can't if you want to be a piano player you should

spend half of your time reading books and his his point was is that if you

spend all of your time just learning to move your fingers you have not absorbed

any contact the context necessary to play any real piece of music that

there's there's something else besides the practical application of the of the

technique and I think that the somebody was asking me at the break it was a very

good question actually which is and the

it had to do with she doesn't sounds

like objects make you do a lot of design and anyway but you know it wasn't said

stupidly at all it's just said isn't that hard and I said yes it is hard and

it's hard whether you've got objects or not the main reason is that objects

provide both an excuse for designing and they also give you a framework for

holding the design every little bit of design you do you get rewarded in an

object-oriented system for having done it you really get rewarded where's it's

hard to get rewarded in a in a procedure data structure system because often the

design has nothing to hang itself on there can be local good things but you

can't propagate the design forward the way you can in an object-oriented system

I don't know because I haven't hung most

you know Edward de Bono's says the problem with most American companies is

that when they get in trouble they redouble their efforts so you know the

idea is that we're basically too industrious for our own good and once we learn a technique we tend to put our

head down and just fight like mad rather than trying to smart our way out of it

like I said I particularly efference to

me I had actually seen these techniques and actually programs using some of these techniques for five years for a

period between 1961 and 1966 before

Simula hit me on the head and hit me on the head just because at that point I

had a problem that was much harder than I wanted to program it was the first

time I was willing to actually see that was when I was going through insane

minutes and I said to myself holy cow this is so you know there's just nothing

here all I have to do is this and that I'm done you know all of these things

fall in I was actually programmed in the game of space war you know which is one

of the first video games but it wasn't even a video game back in the in the 60s

and they're all of these it's very hard to do in an ordinary language because you have all of these spaceships and you

have planets and you have torpedoes and when I was looking at Simula I was

trying to get figure a way out of doing

this I didn't want to do it in 30 pages of alcohol or so and I was trying to

figure out a way and all of a sudden it occurred to me that every single thing in space war and Simula was the same

thing the only thing was different was the costume they were wearing the

planets were the same the spaceships were the same the torpedoes were the

same there was like one line of code difference in each of their behavior and

they all had to obey Newton's laws they all were interacting with each others in

exactly the same way it was trivial and I wrote that program and a half a page

of code and I never looked back since because the you know the that is the

thing if you don't find this folding up of complexity into simplicity then

either you're working on a truly hard problem which really really do exist

or there's probably a rotation of the situation that you haven't examined yet

you're probably still thinking the old way in thinking in terms of particulars

rather than generalities we're so used to programming up each specific thing

that's hard for us to think of avoiding that then we only have to to program up

one general thing and then write a couple of lines of code for each of the

particulars and we're done that's a really good test in this stuff and it

accounts for the religious fervor of people who have had this happen to

themselves as after pounding your head away on a system to have it fold up like

like there was nothing there it is the most amazing thing they have an

operating system go away to something that is practically a clock which is

what it is in an object-oriented system because what do you need in an operating system well once you've got the ability

to sustain objects and stuff like that you practically only need a clock you

only need to get control routed around and everything else is written essentially as an application on top of

that kernel that's a very modern way of looking at things and it's a terrific

way of thinking about doing stuff

okay yeah

that's a very good question some of these idea a relational database

everybody knows what a relational database is right okay so the the there

are several things a relational data an item in a relational database has fields

it has some of some of the things and depending on the data dictionary that

the relational database wants to sustain you can occasionally do some integrity

constraints the most relational database is friend for example is very difficult

to do the following thing in a data record and that is make sure that Joe

blows age is always the right one when you ask it because when you ask

somebody's age in a relational database what it expects to do is to go to a

field and find a number and bring it back to you right in an object system

what you would have there is you'd sent the message age to the object and it

could just go to a field and bring back a number but a smarter one would

actually look at the guy's birthdate and compute his age for you right then and

so you'd always get the right answer every time you asked aged you would

always get the right answer from the object you would not get it from the relational database unless you're doing

careful updates that's one difference

the other difference is that in a in a relate in any kind of a relation it is

extremely difficult to embed code although people sometimes do by

embedding it on the outside of the database rather than on the inside with

it so for doing a dynamic simulation for instance is quite difficult a good way

of understanding where relational databases is going to go comes out of

one of your own products and an industry that McDonnell Douglas is one of the

leaders in Amanda's CAD CAM CAD cam can't be done on relational straight

relational databases there simply aren't enough hooks in there to deal with all

the things it's not you can't store the data so you can't deal with all the

other things that the relational database database can't store that

cad/cam requires so object-oriented

servers like the gemstone or this the

ontological rated servers are ones that

the CAD cam industry is going towards now these allow you to do all the things

that you're used to doing with relational database but also give you this extra level of abstraction that you

get from objects what's nice about it I think for people worried about

transitions is that there's a fairly reasonable transition almost everything gets better when you go to an

object-oriented database server for instance I think most people would like

for instance to have joins be real

things rather than a made-up thing for

the moment and they can be in an object-oriented database most people

would like to have views be things that you can add it back through or views

that you can view whereas a view in a

relational database is an extremely weak notion of the whole notion of what view

is where in an object-oriented system is extremely easy to have a view look like

the set of stuff itself and so you can put another view on top of it and

cascade them and so forth and all of those things are being done right at

this moment with object-oriented servers

excuse me yeah I think for also because

the the tutorial it's going to happen in a couple of weeks is going to be one of the people from this digital company the

company that does small talk V I want to just mention again that besides the fact

that it's cheap small talk V I think is only $99 on the IBM PC and 150 on the

Mac so it's the cheapest small talk they have by far the best manual none of the

other manuals are even in second place because they actually don't believe that

you understand about object-oriented programming in the beginning of the

thing they actually write the manual there's a splendid tutorial hands-on tutorial for getting versed with all of

the object-oriented lore and sub-classing and building a very

powerful little application another thing that they give you for free in

with small talk I don't have any stock in the company I haven't made a cent on

small talk but what they do is they also

give you for free a full-blown implementation of Prolog Edinboro Prolog

written in small talk okay and just to

give you an idea this whole implementation of Prolog written in small talk with its own user interface

its own browser its own debugger and everything else is less than 20 pages of

code okay and if you've ever tried doing

anything like a programming language like this is a convince err okay and it

uses object-oriented programming for what it's really it uses the fact for

instance in small talk everything is an object everything is an object and

protected including the things that you think of as stack frames and ordinary

languages that you can't even get to how is it the bugger written in small talk

well this stack frame is simply an object so you simply write a method that

allows you to ask the guy well what do you what do you have here what do you

have here can you advance your PC what see I mean I mean the debugger is like a

page and a half long because it actually is part of it's just a subclass of class

stack frame prologue is so simple in small type because they actually take

the stack frame as an object and implement prologues control structure

directly in using the small talk using

small talk sone stack frames but using a non stack protocol which is what the

Prolog backtracking requires this is gorgeous stuff and it's done completely

without impinging on the integrity of

small talk itself the two systems are integrated together and so you can do

Prolog unifications into small talk variables and vice versa so it's a

perfect example of what an embedded system in an object-oriented system looks like they give it to you for free

you can do real work in it if you just want to use it but people are really

interested in why this stuff is powerful that's an example of where the power of

it is actually concentrated and used by some design thinking here's another one

most object-oriented languages don't

have a complete model so for instance

when Simula for instance has classes so

you have a class paragraph or a class

string but Simula doesn't have classes

be objects so if you have an object-oriented one of the choices you

could make is to have everything in the language be an object why not that means

if there are things called classes there

must be a class class a class whose instances are the classes okay that

sound shaky let me just let me just draw it cuz it's

so I'm going to draw classes in red so

this might be integer might be fraction

might be paragraph this might be document this might be file and there

are instances I'll draw in green this might be three and this might be for

this might be three quarters this is a

paragraph of text and so is this one

this is a whole document this is a whole file here's another one they have lots

of instances of these classes they've been on Simula these red things in an

ADA these red things aren't around at runtime they're like macros they just help

create the structures underneath that these green guys can work with but in

small talk these are really objects and

the question is is if they're objects what are they an instance of what is

common to all of these things somebody tell me they're all a class so

what what's common to all of these what do they do they all make instances right

I mean they're the thing that holds all of the information that's necessary to

make multiple instances and so you can imagine that there might be a thing

called class class whose own instances

are these guys

okay that sound reasonable why not okay

down remember I can subclass what do you

think it might mean to sub class class class let me do that let me use another

color here

so I'm going to sub class class class here look just in general what is the

sub class of class class going to be able to do it's going to no it's not

gonna make some classes it's gonna make be able to make classes like these guys

plus something else then I'm gonna add right there because anything that's of

class class is going to make classes so any subclass of it is going to make

classes now here's an example of something we did at parc many years ago

we wanted to do a system in which every

instance was data-driven okay in other

words we wanted to do a data flow system

inside of small talk in which the every

thing that happened to some variable in

an instance could be propagated to the next thing that meant that every instance had to have besides the places

in it that an ordinary instance has here's what an ordinary instance looks

like it's a thing that has slots in it for holding values and plus what we

wanted to do was to tack onto that some

pointer information that would link all of these guys together so we'd actually

have a data-driven network here now how do you suppose we

did that sub class class class

right the various places I could do that but what if I did it up here and put

that information in here and now every

every class that this guy makes whatever

it is is going to have the property that the instances of it regardless of what

these guys are as I go along making up new classes for this kind of thing and that kind of thing every one of them is

going to have the property that the instances are going to be instrumented this way see how high that change was

made what I did is I actually change the meaning of what class this was in the

system with one operation I just subclass a very very high-level guy and

all of a sudden I got essentially a new small talk with a completely different

strategy for how these things strategy independent of what the new classes are

going to be okay that's the power of

this stuff it's not the direct stuff

that you can do that's so appealing now it's the meta stuff that you can do

that's so incredibly powerful because you can literally when you have a new

idea that's important you can literally distribute that idea over the entire

universe with just a few changes in a

system like this well let's I think we're about done let

me let me give you a one of our favorite

stories and as a winch and Winston

Churchill story widget Winston Churchill jokes always have them at a party after

a bunch of whiskeys and I'm sure everybody knows the one of

the he was incredibly drunk and a woman

came up to him at two o'clock in the morning and said mr. Churchill you're

disgustingly drunk and he looked at her

said and you Madame are indescribably ugly but in the morning I'll be

indisputably sober

so this particular this particular Churchill joke a little earlier on the

party he hadn't had quite as many whiskey's and the hostess of the party

came over to him quite agitated and said mr. Churchill I'm just really upset I

don't know what to do I saw a famous Earl over there steal some of my silver

salt shakers what should I do Churchill thought for a minute and stuck his cigar in his mouth and went over to

the Earl along the way he took a salt shaker himself and put it in his pocket

and we got over to the Earl took it out of his pocket and said I think we've

been noticed perhaps we should put these back so that's my version for why we won

World War two in other words if you want to get people to do something to go

along with you you have to involve them in the same conspiracy and

object-oriented programming is a kind of conspiracy that people are just finding

out about it I hope I've been able to involve you in a little bit and I hope you will involve others thank you

[Applause]