Tip:
Highlight text to annotate it
X
>> MILLER: Hi. I'm Mark Miller, the host here to introduce Dan Ingalls. I'd like to say
that Dan Ingalls I think of as one of the architect of the modern world. He is one of
the original architects of Smalltalk, the object-oriented programming system that's
essentially the ancestor of all modern object-oriented languages. He designed the Smalltalk-76 virtual
machine, which was the first practical implementation of these ideas. And he's done a very fundamental
work in bringing object-oriented concepts through the user interface, the BitBlt graphics
primitive but also the Fabrik programming environment; a lot of contributions to Squeak
and others. And now he's brought many of these things to the world of JavaScript in the browser.
So, Dan. >> INGALLS: Thanks, Mark. Does this work okay
if I'm having near the... Yes, it sounds that way. So I'm going to be talking to you about
the Lively Kernel, which is a project we're doing at Sun Labs. And it's not just me. There
are a number of us doing it. I'm one of the principal investigators along with Antero
Taivalsaari, who's in Finland. And then we also have a visiting professor in Finland,
Tommi Mikkonen and Krzysztof Palacz, who's here in the audience. He's in Menlo Park with
me. And, you know, anything here that looks like it might be hard to do, most of it is
easy but some of it is not. Krzysztof is done. He's been great. And then we also have a couple
of other collaborators. Steve Uhler, who's here with us. He's at Sun Labs. And Steve
knows all about all sorts of things, but among the other things sound. And he's been around
a lot with user interface design of layouts. So he's sort of been doing this and that and
we look forward to him doing more. Richard Ortiz has helped us with the website [INDISTINCT].
And then we had a couple of interns from Finland also who helped with the some of the applications
that I'll show. And now, my way of giving a talk is just to give demo typically. So,
let me just jump into that. But I will start with a little sort of a bit of history about
how this project got going. It started with the dinner conversation. I was having dinner
with Antero and we were sort of--Antero had just given a sort of a summary course on web
programming. And I have been thinking about web programming. And we were just sort of--you
know, this pause came when we sort of both we're saying, "There must be a simpler way,"
you know. "How can this be so complicated? The machines are so much better. We knew how
to do things fairly simply 30 years ago. Why is it getting harder?" So we started scratching
our heads about that and we went off on several tangents about how to make JavaScript faster
or this or that. And eventually things kind of converged down on this basic idea that
there is a dynamic language that's out there in every browser. It's JavaScript. And we
both--it was in both of our hearts that what you needed was a dynamic language and a basic
graphics library and the data ought to cover most everything--network access, too. So the
kind of approach we adapted is--this is kind of the conventional stack of web programming.
It starts out with an operating system that gives you network and graphics; a browser
that sort of makes that available through the Document Object Model. And here we get
into the history of how the web started. And with the Document Object Model and HTML, a
text mark up language, what a great place to start. And then on top of that worlds of
widgets that got built and then JavaScript came along kind of later in the game to add
some dynamic behaviors, the ability to, you know, test for things. And what we're trying
to do is a little bit different which is to take the same-the same substrate and--because
we--you know, what we're starting with is the operating system in the browser; part
of this what we wanted to do in this project. We both had some experience with systems that
we did all ourselves in a proprietary way and they were wonderful but they had trouble
going anywhere. So we thought we'd start with what everybody is working with and then maybe
things could go somewhere. And then instead of copying all these sort of complicated world,
we just wanted to take JavaScript on the browser and then build the widgets that would be needed
for doing most of the sort of, you know, Mom and Pop software on top of this. And that
is the stack as we look at it and so many other frills that we might want to put such
as the effects of cascading stall sheets and stuff we figured we could do in that environment.
So that's the approach. And as you might guess, I'm running the system now. What you're looking
at is a webpage. And I think if--you know, if there's one thing I'd like you to get through
all of this is it's not complicated. It's really easy, you know. So this entire system
is 10,000 lines of code, which seems like a lot, but it's something, you know, you can
give to a grad student and he can play around with it and do a useful thing in a day or
a week, you know. So--but I'll just kind of take you through a little bit of how it's
built. You see here some simple graphical objects on the screen; a rectangle and an
ellipse and so on. And so one of the first--if you think of the page that comes off into
your computer and starts running and then--one of the neat things about this system is it
never needs to be installed. It just runs when you hit it. One of the first things you
might like to do is to be able to take the shapes and pick them up and move them around.
And another thing I have sort of a disclaimer I have to make is that a lot of this is in
a primitive state and some of the features we're using in the browsers are in a primitive
state. In the--if I go to the beta version, one of the special beta versions of Safari
then this would have had a nice drop shed I wanted. But the--but this all runs in standard
Safari 3.0. So as I say, you have the--one of the first things you have is the ability
to pick objects up and move them around. So you can think of that as--you've got your
basic graphics library. And then how much does it take to do that? Not much. You know,
half a page, something like that. And then the next thing you might want to do is to
be able to copy objects. So, you can do that. And this is--this is pretty simple to do.
You know, how hard could it be? And I'll make a couple of this. And then the next thing
you might want to do is to be able to edit the objects. So what you--what you're seeing
here--so here--if I get near this part of the ellipse, it springs--open a little handle
that I can edit things with. So what you're seeing here is along with the code to move
objects around, to copy them. There is a little bit of graphics editing in there, too, but
it's done in a very uniform way so that basically that little handle that came up is just another
one of these objects. Let me play around here a little bit more. Something like that. And--so
once you--once you can do that, you can edit objects, move them around. The next thing
you might want to do is to be able to compose them. And we have a very simple rule here
which is that if you drop one object on another and when you let go, the cursor is over the
target then they stick together. So this is now a compound object. Again, each of these
is just, you know, a little half of page code. Probably less when you put them all together.
And there are other things that come with the system. So here's a polygon. I'll make
a copy of that. And it's got the same kind of graphics editing in it. You can pick up
the vertices and--it's got--one nice thing about it is that you can--you can go in the
middle of a line and you get a different kind of handle and that just makes more vertices.
And so it can do that. And if you move one over a nearby vertex, you can see the handle
turns red. Maybe you can't but it does and that gets rid of that vertex. So, that's just
a really barebones little polygon editor. And we could pick this guy up and drop him
there and make this guy happy. So--and this is all done--I'll take you back to a little
bit of history. The first version that we did with this use a canvas graphics model.
And we worked with that for a while but we wanted--one of the things we wanted to do
was to be able to make a kernel that would work nicely in mobile environments. So it
was important to us that things would be able to arbitrarily scale and rotate. And the canvas
environment did not have a good answer for that in the space of text. So last summer,
we sort of latched on to SVG and this current version I'm showing is using SVG. And what's
nice about that is that then--with SVG, you can do--so this whole object is nicely scalable,
you know, and you can rotate it like that. And--so this--and copy. So you got--basically,
it's not like what we want to do is have people building frogs, but this is a stand-in for
the basic operation of building up complex graphical objects from simple ones and making
that simple. And the one other ingredient that I'll show you is--at this simple level
is you can have objects that have scripts on them that tick. So that's how you get a
dynamic object like the star and make a copy of it like that. And as you might guess, if
you take something and compose it on that, it inherits. So--and you can--you can have
lots of fun with this. So that's--I guess the other message of this talk is that all
the systems I've worked on, part of the goal was not only to make them simple in general
but to make them fun. And this is sort of fun to play with. So if I take a copy of this
star and--if I can drop it on--right there on that when you see it's picking up the rotation
relative to the other guy. Okay. So--and that's not magic. I mean you've got a very simple
programming language here. It's just set up in an architecture that preserves the generality,
right? So now let me--I'm going to you a little bit about the structure of this world. So
this came as a webpage and we have ways of linking webpages in the system, but we also
have a way to have linked worlds within a given scope of objects. And that's what I've
got here. And this is actually a sub-world of another world that I'm going to go out
into and this has some stuff I'll talk to you about later. And I'm going to go in here
to another world called development tools and just sort of continue the process of building
up this graphical world. I guess the first thing I'll show you is that little piece of
code up in the upper right, which maybe hard to read, so I'll make it a little bigger.
And one of the nice thing--things is that the text editor is all written in JavaScript
so it inherits all these properties. And in fact, one of the--one of the things we often
like to play with is--let's see. Let me get this. Like that. Okay. So here's a little
piece of code and I'll read to you in case you can't read that. It says let P be a new
pen, set its pen color to red, and then go through a loop from 1 to 40; telling the pen
to go that distance times two and then turn 90 degrees and then draw resulting lines.
So let me move this guy out of the way and come up here. And if I execute that, then
I get this figure here. And what's nice is it isn't just scribbles on the screen. It
actually created an object that captures those graphics. And, you know, you can get in here
and mess around with it, too, you know. And you can--you know, you can make little changes
to this. If we turn not quite a 90 degrees but only 89 degrees, then it has this nice
sort of precising quality. And you can have lots of fun playing around with that. But
again, this isn't about fun geometric--well, it is. It's partly about how easy and fun
it is to do little geometric games. But more importantly, here's a [INDISTINCT] of JavaScript
that I've tried out two versions of now, you know, in a few seconds. So this could have
been a little piece of code that was there doing some piece of screen scraping where
I was looking for stock prices and I--you know, I tried it out and changed a bit and
tried it out. So that's--and the other--the other aspect to this is that from that graphic
vocabulary that we started out with, it came with the operating system and it came with
the browser. We've now extended it. S, we can make up objects that hadn't been thought
of in the operating system and use them in the system. Just have a sip here. So now what
I'd like to do is to continue that process a building up and out of the very simple graphics.
So, here I have--it's sort of a widget test panel if you will. So there are two things
going on here which is we've built using very simple little swatches of JavaScript, some
conventional widgets. And this panel also has the property to sort of try out an NVC
style model so that a lot of them have common models underneath them. So here's the button.
And the one below it is hooked to the same Boolean but it's--the one on top is one of
these things where it goes when I push and this one down below just changes when I push.
But they're hooked up to the same Boolean. And here we have a piece of text. It says
hello world. If I select that and say hi and accept that, then you'll see that the other
three panels we're looking at the same model. This one however down here has a continuous
update property. So that--so this is just trying out various little text things that
have a common model. And you may have noticed the one below is testing the fact of--that
these guys have an output that is their current selection. So if I select there then it gives
the selection down below or it actually will do it dynamically while I'm going along there.
Okay. And over here we have a little bit more text but this text is made into--is in the
form of a list and in fact it does have some scripts on it that gives it list-like behavior.
And its neighbor is viewing that same model of what the selection is. And down here, we
have some rectangles that are like those rectangles I showed you in the first screen but they've
been put together with a little bit more scripting so--to work as a kind of a slider. And you
can see they've been hooked to this text panel up above and it's been done by directionally.
So if I change that to .8 then it jumps over that way. And you might guess that--what this
one here is doing is giving me the extent of the slider. So if I change that to .3,
then it changes that way. And what else? Well, this one's got a little piece of generality
in its code. Nothing earth shaking but you can see that it works horizontally and vertically
as well. Okay. So we're now at the point that we could actually start to do some useful
software. Remember, there's nothing native here. All this is, is the graphics that came
with the browser and JavaScript. But I think you can see that if you take those things
we built and put them together--here's that slider doing service as a scroll bar. Here's
that list showing a list of items that you can select. And what we have here is actually
a class browser looking at the classes in the system that's running. So for instance--let
me--let me go get us a little application that we can be looking at while we're looking
at the code. I'm going to go back to that outer world. I'm going to pick this clock
up and--so here we've got drag and drop of a live ticking object. And we'll now drag
it through this worm hole. So now we're looking at the clock. And here in the list is the
code for the clock. And like everything else, it's pretty simple. It's got--it's got a little
constructive thing and initialization. Most of the work here is in this make face routine.
It doesn't mean make a bad face. It means draw the numerals. And you can see it's sort
of--most of it is here in this loop that goes from one to 12, putting out the numerals.
And it will leave--either do Roman or regular Latin numerals. So that's all that code there.
This creates three hands called hours, minutes and seconds not surprisingly. So that's all
that code. And then if you look at this thing called start stepping script, every object
in this system, when it's dropped in the--into the world get sent this message start stepping
script so that if it wants to do stepping behavior it gets--it gets--given a kick start.
And this one, you can see it's says send the--send the start stepping message with a parameter
of 1,000 milliseconds and the procedures set hands--the method set hands. So if I look
at that code, you'll see that this is what it does on every second pick. It gets the
current date and it computes the second, the minute and so on. And then down here, remember
these hours, minutes and seconds, those are the names of the hands. So if you take a look
at the seconds, it says set the seconds--excuse me--tell the seconds to set its rotation to
the current second value divided by 60 times two pi. Looks right, right? And we could actually--we
could go in here and change that to be minus two pi just to be devilish and accept it.
And now we've got a clock that runs backwards. Okay. So let's just indicate that everything
that's here is here in a live way. And that applies to the clock or to the actual parts
of the system if you wish. And again, since this object itself is all--you know, is all
made in using the same components. It can be scaled and rotated arbitrarily and it just--it
keeps on working. In fact, I can go back and unfix that. So we're back running that way.
So that's the basic way that we start out with a simple webpage that just allows you
to, you know, move graphics around, add a few script, build up some widgets and pretty
soon you're into the space of integrated development environment. And now what I'll do is to show
you just a few things that we've--that we've build in the--in the system. Here's a window--one
of the things I neglected to show you, we have a sort of a--I'll go back to where we
were just so you get a sense of it. You notice things look pretty primitive in this world.
All the shapes are very rectangular. You can--you can--you can come up to any object and ask
to view its style. So I can come up to this widget test panel and view its style. And
I could go and move this slide over and round its corners like that. And I might say it's
bordered with the--or a little bit more. And I might give it a border color that sort of
more consonant with this background. And just to make it look sort of modern, you know,
we could make it look translucent so that now when you pick it up and drag it around
it--you know, one of those nice controls. So here again, it's a system working on itself
and allow you to make changes like that. And I guess you could even take--let's see here.
Look at the style of the style panel and set its--okay. So you have that kind of control
over everything. And then--and we sort of build into this a very primitive sort of facility
for--I'm going to get rid of that. It's kind of--well, I'll leave it there for a minute
because--just to make a point. But we put--got a sort of a simple facility that's along the
lines of cascading style sheets which allows you to specify style in an inherited way.
So if I go down here and, say, choose display theme--the theme that was in this window was
primitive and that's why everything's very rectangular. I'll choose the lively one which
is our default. And you see all of a sudden all of the windows, you know, got there title
bars rounded. And the scroll bars got a slightly different fill and the title bar's got a gradient
fill. So, there's that kind of control there. That's all pretty simple to do. So now I'll
go back to where I was. And you can see that this is in that style. These windows are--and
these are just simple little applets that you might want to make. Here's one that shows
the current graph of the stock market. And then it's got RSS feeds for Dow Jones and
for NASDAQ and, you know, the price of your favorite stocks and stuff like that. And I
got a very simple little sort of 3d-ish little demo here. We've got--this software system
is complete if they can't do asteroids, you know. And I won't take time with that but
that's how that works. Here's a little weather widget for San Francisco. We've got San Francisco,
Tampere, Finland. You can guess why that's there and we can see what the weather is like
there. I'm glad where we are. And let me--I'll show a couple--a couple of other applications
done. Here's a Google Map sort of application there and you can scroll around. And here's
another RSS feed guy where now you can look at the contents below each of these. But you
can see that these are all made up of those simple primitive widgets that were built so
simply that's got a little--here's a little movie player. Yes. This is something about
some guy who strapped leaf blowers to a bicycle to make him... And let's see what else we
got here. This is--I don't know if you know the Canvascape demo. But this is--here, we've
got that running in this system. And you can see these things all sort of running together.
There's a lot of--we have work to do on the performance still. But as near as we can tell,
a lot of the performance is going into the API. I'll come back and talk more about this
between the underlying system and the graphics. So here in this one--oh, yes, that's right.
This is a funny little aspect of this. Don't be alarmed. So here you can move around in
this little 3d space. And coming back here--so those are a bunch of the sort of simple applications.
And then I did one application that's more complicated than the others in terms of its
sort of actual, you know, programming model if you will. So this is a model of a--of a
gasoline engine. And you can see it sort of changes color depending on whether it's taking
in or compressing the gas. And it turns yellow and it explodes and stuff like that. And this
is set up to be any number of cylinders also. So you can do this. And part of the--this
was a piece of tutorial software that I wanted to do for a long time because there's a funny
thing about building a radial engine which is that--first of all, it doesn't--it doesn't
run smoothly if you do the sort of simplest thing. I'll stop this and step it through.
So we've got--at the top is where it's compressing. It's about to fire. And then the next one
is to the right of it. That was 90 degrees. The next one below--you know. And then here.
And then because it's a four-cycle engine, the whole thing just idles for a whole revolution.
So you wouldn't want to build one like that unless you like vibrations in your airplane.
But even there--so we'll change to an alternate firing order and step it now. So now you'll
see--the one on the right is about to go. And then the one on the left, 180 degrees
later. But now it's going to fire the one at the top just 90 degrees later. And so we've
got--we've got an irregularity there. And it turns out that if you build a radial engine
using a four-cycle engine, the only way you can make it run smoothly is to have an odd
number of cylinders, okay? So if you now step this through, you'll see the familiar five-pointed
star. It's going to go off on the upper right. And then the lower left. And then the top.
And then the lower right. So this is a demonstration of that. And if you look at any radial engine
in an airplane, you'll find that it has an odd number of cylinders. And it's set up for--you
know, you can choose seven and--or nine, any of those. So, that's where I wanted to take
with the demo. I think what I'll do is to just come out and talk a little bit about
the system and then open it up for questions. So let me come out here. Slide show. And move
on there. So some statistics about it. As I said, it's about 10,000 lines of code. About
300K of that is in the kernel, which is the graphics architecture and the widget that
I've showed you. And this is 300K uncompressed and with comments, okay? So it's something
like, you know, a third of that if you compress it and so on. There's another 100K there of
kind of adaptation and workarounds. And so an example of workarounds--well let me digress
for a minute here. It's very interesting doing this project because you can sort of tell
the people haven't done this before because the programming language is set up to be a
scripting language. So it's got lots of features that make it better for scripting like sort
of for giving many errors, but it makes it much worse for programming because you've
got the errors. And the problem is you find out about them at three--you know, three cycles
later when it's harder to debug. And with the graphics, we found that, you know, lots
of the graphic systems are fairly solid except that if you want to, for instance, layout
text, typically, that's done elsewhere on some server before [INDISTINCT] HTML. And
a lot of these systems--both in--both in the canvas model and the SVG model, if you ask
them for the geometries of the text, it's hard to get that and it's often wrong. So
along with this adaptation, which is sort of the API that gets us through the DOM to
the graphics calls, are some workarounds. So for instance, Krzysztof had to do lots
of work to get in and find out from--through the DOM the real measurements of these characters
because SVG wasn't giving it to us accurately in this system or that. Now those are things
that we'll all get worked out. It's--you know, there are parts of the browser graphics and
language systems that are solid because they've been used for 10 years. And these are parts
of and it hasn't really been used until now. And they'll get solid. And then there's another
120K of sort of a JavaScript extras. This includes Doug Crockford's prototype stuff
and a little bit of other kind of structuring mechanism. So where we're going, you can see
things are still in a fairly primitive state but they're going forward. It's gratifying
to see how much you can already do in a system that's so simple. We want to complete the
IDE that we've got. It's gratifying to see how much you can already do in a system that's
so simple. We want to complete the IDE that we've got. So we have in there the ability
to do--you saw--well, you didn't see it all but there's an inspector that let's you inspect
objects. And we've got some measurement facilities. I'll show that to you later on. And we've
actually got--one of the nice things about JavaScript is it is pretty general. And so,
for instance, you can--you can just tell the system to wrap every--well, let's see. As
it normally comes to you, you can't inspect the stack. But what you can do is wrap every
procedure that puts the stack on a stack. And then when you--when you get an arrow you
can look at what you've created. So, it takes a lot to keep us down I guess is one way of
saying that. We want to hook--that browser that I showed you was the compiling code.
So that was simple to do. What we want to do is to hook it up to our real code repository
using WebDAV. And we have--there is WebDAV code in here for doing that. And at that point
when we make changes then, you know, it'll actually be in our repository and we'll be
advancing the system with every little change. That's where we wanted to be. We had an earlier
version of the system that was collaborative in the sense--I don't know if you noticed
during the demo. And when we go back there, you'll probably always be looking at it. Now
this little sort of fly following my cursor, that was the actual hand object that's a part
of the orphic graphics model and there can be several of those. And in an earlier version
of this system that we did on top of Java 2d, Krzysztof actually got a whole synchronization
mechanism going so that you could have multiple people working in the same world using a comment
style update. And so we're--you know, now that we've got this all working with SVG,
we're going to go back and revive that so that you can--he said that you could really
do sort of a collaborative whiteboard this way and other things like that. And in the
last sort of point I want to make about this environment and it--it's got to do with how
small it is also which is that whenever you build a self-supporting system, the neat thing
is that--in--you know, in its little universe that's all there is. So if you want to do
some experiments like if you want to try to put this in 3d, you have nothing more that
you have to work on than the code that's there. And so we want to--we want to play around
with that. We're also interested in looking at smaller, faster JavaScript, smaller, faster
SVG libraries and especially the interface between them. So if any of this looked a little
logy to you--it does to me--a lot of the problem has to do with the fact that the SVG that
you get--given in a browser is given to you through the DOM interface. And for an example,
every time you make any call that has a color in it, we've got a perfectly good RGB color
object sitting out in our system. To go through the DOM interface, the red, green and blue
all have to get converted to a text string which then gets parsed and taken apart on
the other side of the interface. This is not the way you do fast graphics. But it shouldn't
be hard to do some experiments to get around that. And then again, the opportunity with
a system like this is to--you know, along with experimenting with, you know, other languages
or whatever, there's--and this relates specifically to the [INDISTINCT] project here. It's fairly
easy to take a system like this and try it all out in some variant--say, some variant
of JavaScript. And the nice thing is that if you can just make it work, then you know
that sort of all of this stuff will come along with it as soon as you get it working. So
that's something that we're looking forward to exploring in both--Mark and I have been
talking around this except we've both been busy with other things for the last month.
I wanted to show one thing just--actually, I think I'll open it--open it up for questions.
And if people want to go in to some of the ID issues, I can show you a bit of that. So
that's the end of the formal presentation. Yes.
>> This looks terrific. With power comes responsibility, and in particular with program ability, there
is a class of things that most people can do with mobile code. And I wonder if you have
any thoughts about what's different in this system from all other mobile code systems.
>> INGALLS: So, it's no different in sort of all of the downsides and the upsides. And
that's--so there are various answers to that. Mark is working on an important one which
is how to really organize your universe in terms of capabilities so that--so that you
can't do damage unless you're supposed to be able to do damage. The other thing you
can do is you can divide it up and allow somebody to work in this lively world but only share
things that are not lively in dangerous ways. But there's no magic here in that regard.
Yes. >> Hey. The guy that worked with Smalltalk,
and BitBlt and [INDISTINCT], it's great to--it's good to be here. I'm at the Google Gears team...
>> INGALLS: Yes. >> ...and one of our goals is to augment current
web browsers with new capabilities. So very interested to know what kinds of facilities
would make your software more, you know, easier to build, faster, along those lines to be
able to [INDISTINCT]. >> INGALLS: Yes. So we've--I can see lots
of overlaps there. The--I guess the first one that occurs to me is that I had a lot
of fun in a former lifetime doing this system called Fabrik, which is--it's a visual programming
language in which you have objects on the screen and you hook them up just like in Google
Gears except that it had a different model. It...
>> I should just make sure--I mean, are you aware of what Gears is? It's a--it just plugged
new features in the web browsers like offline access.
>> INGALLS: Yes. >> So it's not visual.
>> INGALLS: Okay. Yes. So I guess I was thinking of the interface on top of it, yes.
>> Okay. >> INGALLS: So, yes. So that would be a nice
opportunity. So if we wanted to play with a better--sort of more appropriate graphics
model, it'd be a great way to do that and also alternative JavaScript engines. One of
the things I didn't talk about is from our experience working with JavaScript it would
appear that you could have a considerably simpler language that probably could be executed
quite a bit faster and still have very much the same feel. So, yes, I think that would
be a lot of fun. And I don't know if that's the kind of thing that you're getting at in
that way. >> Thank you.
>> INGALLS: Yes. Thanks. >> Cool. I've only gabbled with Squeak and
I guess this is how I've kind of seen how--you know, all these different ideas. It looks
very much like that. And also I know that Smalltalk was kind of the originator of Unit
Testing, the unit test talk or SUnit. I was curious, is there a Lively Kernel unit or
how do you test it is basically my question? Do you have automated testing?
>> INGALLS: There probably should be and we sort of rushed into it without having done
a lot of that. So that's an opportunity that sits there for some of the people who want
to come along and work on the project. >> Was it--is there like a technical like,
"Oh, shoot. We have to solve this other problem before we type letters with just limited time
and just having out to you." >> INGALLS: I think it sort of--the background
of the participants and the--in the headlong rush but--and that's not to say that you can't
go fast the other way. But anyway, that's the way it currently is. We--I think--I see
that as being, you know, another component when we--when we get the repository online
is to get some of those facilities in there soon.
>> Cool. Thanks. >> INGALLS: Yes. Currently, just to add one
little postscript to that. You asked: how do you know that things are working? One thing
about systems like this and like Squeak and--which is to the extent that they are still a small
kernel. You find out immediately if something doesn't work because everything is using everything
all the time. Yes. >> Okay. Another question. So Smalltalk, Squeak
and this have really similar sort of user models and user interface and they've had
difficulty gaining adoption. Are there any sort of lessons learned about usability and
how to get these kinds of systems in the hands of more mainstream users?
>> INGALLS: Yes. I think--well, there are--there's the perennial push and pull between with native
widgets and self-supporting systems. So in this system, it's all written in the Lively
Kernel itself. The upside is if you put it on any machine, it's going to behave the same.
And that's--this is also true of Smalltalk systems and so on. The downside is that one
of your customers may really like his windows that he's got running on his system and he
wants it all to look that way. And more over when he upgrades to his new operating system
he wants to inherit all those new properties. So the way this has been handled typically
in the past is that somebody takes a good bit of care to establish a layer over the
user interface that has implementations that are self-supportive and small on the one hand
like this. And there's another implementation that you can use alternatively that goes to
native windows. And then, you know, some work is done at the boundary to make sure it's
all compatible. So that lesson has been learned a while ago. What you see here is just a self-supporting
system all written in itself just because that was--you know, we're on a proof of concept
role here and wanted to get that working. But that is a piece of work that needs to
follow here if we want to see general adoption I'm sure. Yes.
>> An earlier Sun project was something called NeWS, you know, Network Extensible Windowing
System. And one of its facility is--was the ability to partition an application across
multiple machines so you could have something running, doing some graphics work on your
desktop by doing some compute work on a remote machine. And to some extent how you partitioned
was negotiable according to your network connection speed and so on and so forth. And I wonder
if you thought at all--you mentioned having collaborative desktops but I wonder if you
thought at all about taking things and partitioning them across multiple systems in that way.
>> INGALLS: The answer is that the topic of news has come up and Krzysztof was particularly
interested in that. Do you want to say any words about that?
>> PALACZ: So I wish say I have something more [INDISTINCT] interested in having the
[INDISTINCT] move computation between the client and the server. And assuming that both
ends who have the same--the same programming language [INDISTINCT] than NeWS [INDISTINCT]
or whatever. So, yes, it's definitely in the NeWS. It seems like people walk around JavaScript-based
application servers. There's a lot--there's a lot [INDISTINCT] application servers. So
it's definitely in the works [INDISTINCT] have a compatible architecture [INDISTINCT]
of what's going on in the server and then the client.
>> INGALLS: Yes. Yes. >> So this sort of system where UI can drag
and drop stuff and they do visual things, it's very fun for demo sort of thing in my
opinion but there is the--the perennial problem with the--you know, with the difference between
more for declarative system like HTML is--from a programmatic and even more to the extreme
from a visually-driven programmatic language where--you know, the system has very little
information about what things actually are rather than--other than what the programmer
decided to put as very specific things and--do you have thoughts on that?
>> INGALLS: Yes. So you're right about that. And the ways I felt with that in the past
is that you complete a system like this by allowing the objects to essentially print
the kind of declarative specification that has--that they've been built to be for people
who want to work in that textual space or get programmatic control over it. And you
should also be able to build things in the system that same way. So I look at it as kind
of another piece of--you know, this is a drag and drop gooey gooey builder. There should
be another piece there that let's you specify a window textually if you want to.
>> But even that wouldn't give you like sort of declare--like for example, if you wanted
to go back to your demo and use it without touching the mouse, you wouldn't be able possibly
to do that because the system has no real concept between the difference of what is
a window from what is a bar, slider, or something else. It doesn't really know what things are
other than being lines and being drawn on the screen and being as 3d objects, maybe
[INDISTINCT]. You can't--in a webpage you would be able to say, "Yes, this is a heading.
This is a folder. This is a text field, which is different from a combo box." None of these
things is built in any system that is non-declarative that I have really seen and I...
>> INGALLS: Well, yes. So this is true about the parts that you just put together with
drag and drop. You're right about that. If you look at the objects that are in the widget
set that I showed, you'll find that there is semantics there. So, you know, a scroll--you
know, a scroll pane knows that it has a scroll bar and a clipping frame and all that other
stuff. I don't know how to answer you, you know, sort of briefly except--I think you
need both aspects. And if somebody tries to build something doing nothing but drag and
drop, you're right, they would have that other semantic base. It's just like programming
by example. If somebody deletes a file, they don't--there isn't anything anywhere that
recorded why they deleted that file, you know, that the reason they did it was that its name
began with this and they want to get rid of all of those. So you've got the same kind
of comparison there before the drag--between the drag and drop construction and the declarative
model as you do between, you know, one off actions in--on the screen and to sort of programming
by example field. But, yes. Thanks. >> So it sounded earlier when you're asked
about adoption that you suggested that the reason why we hadn't seen more Smalltalk,
Squeak adoption was that the windows didn't look like the operating system. And I'm really
just not buying that, right? Like, we've had Smalltalk, we've had Squeak for a really long
time and these are frequently shown up as life, "Oh, look. It's a great prototype of
what?" Like, what's the business model or what's the development model? Like, you've
got some buttons, you push them, they go beep. That's great. But in a deployed application,
I certainly don't want people to be able to arbitrarily interact with--or browse the code.
And, like, I would really like to see some kind of--like, what is it you hope people
build other than, like, saying I hope people build? It's perfectly legitimate in educational
environments or in whiteboarding environments. Do you see this as being useful beyond that
because I really just don't see the model that you're replicating as what the earlier
question about adoption having ever really made it?
>> INGALLS: Okay. So can you see any analogy between this sort environment and mashups?
>> I think that this sort of environment is perhaps a bit too locally fluid, right? You
don't have strong definition of what these APIs are. You're strongly encouraged to just
change it whatever you want. Our code browser that you showed us doesn't have versioning,
right? Like, I don't know--like, the local person could knock something together but
then to build something on top of that. Like, am I going to have persistence? Am I going
to have that old version continue to work? I don't know, like, the basic...
>> I think you're getting jammed. >> I mean the versioning and the ability to
publish that [INDISTINCT] and other things that I really need to do mashups.
>> INGALLS: Yes. >> That seem to be missing from the system
and they seem to be missing from Squeak and the system--that this system strongly resembles.
>> INGALLS: Well, let's see. So I don't want to get into a long thing about that but you're
absolutely right that you want all of those good things in an environment like this. And
this is a proof of concept one that is still spurs in those facilities. But...
>> What's the proof of concept of? Like, what's the final model? What would that look like?
>> INGALLS: That you--that you can--that you can build simple objects simply, you know,
using code right off a webpage with no installation and then save those for other people to use.
You know, it's a--you know, imagine yourself sitting at a bus stop and having this idea
and reaching down to your cell phone and doing this kind of stuff. And one of the things
I didn't show is we can write webpages straight out of this. And then you--you know, you text
your friend, the link to it, or send it live that way. So basically making simple things
simple and then there's--and then there's the whole area of being able to--you know,
on the fly in a very simple system, develop stuff, change it, basically experiment it.
It's a prototyping environment with all of those strengths and weaknesses.
>> So you're saying that this is a prototype of a prototyping environment and that it's
not designed ever to go beyond that. >> INGALLS: I'm not going to limit it.
>> Okay. >> INGALLS: You can limit it, but yes. Yes.
>> Two questions. How is the state serialized? And then what would something--like a social
application like Myspace look like inside of this environment?
>> INGALLS: Okay. Good questions. I'm going to turn that over to Krzysztof. And I'd be
nice if we--is there a microphone he could take? The basic answer is XML but...
>> [INDISTINCT] >> INGALLS: Why won't you come up here? That
would be good. Plus then our TV audience can see.
>> PALACZ: So our current form, we are based on SVG, which happens we already have a serialization
format. And we essentially extended with the bits of information we need. And we use the
platform as much as we can to do the hard work for us. And it's true not every object
that you can create dynamically from the--from the IDE will be automatically serializable
but--yes. >> So just to understand. So you--so you serialize
into a SVG document with inline script blocks that are the representation of...
>> PALACZ: Yes. Actions are defined as scripts so there's--actions are defined as blob of
code. You can--you can define a lot of sort of when events are triggered and what--which
function or which--already predefined piece of code is triggered in response to what event
without actually serializing code as such, right?
>> And the world become serializing the separate documents with the link relationship?
>> PALACZ: You can do both. >> Okay.
>> PALACZ: You can have a nested world that happen to be just branches of the XML3 or
you can just write them out and the system will add the enough metadata so that it acts
as a real webpage. >> Cool. Thanks. And then what would Myspace
look like inside this? >> PALACZ: Well, prettier I hope.
>> Yes. Not the particular visual look but social-oriented applications, multiple users...
>> PALACZ: Right. Well, there's--well, there's--there's so many ways of doing it. It's only a platform.
You can certainly imagine if we--if we get the live collaboration working, we could definitely
take it a step further. If anyone wants to have live collaboration where several people
are, you know, co-creating a page. We can potentially do it. We actually showed how
to do it in the previous version. You can imagine a system where every world is someone's
private page. People can create them, delete them at will and link to each other. We can--we
have both the possibility of having several worlds living inside a common run time. But
we can also have separate worlds existing in different run times with different JavaScript
scoping mechanisms. I don't know if that's the answer.
>> INGALLS: That's good. Yes. >> This is related to the earlier question.
So can you--perhaps one thing I see when I see a system like this is a proliferation
of very rich affordances that an average end user might be confused by but at the same
time very useful for someone who is more of a programmer. So can you imagine a principled
manner in which the system might choose to attenuate or display the affordances depending
on, let's say, the world that an object was living in. If you're dragging object into
a developer world, you see a lot of affordances that when you go into several consumer world
or more attenuated and then it becomes more easy to use in the manner provided and not
programmable as much. >> INGALLS: Certainly. And this--you know,
this isn't our particular strength. I mean, we could work on this. But, for instance,
there are controls on every object as to whether it can't be dragged and dropped on whether
it will show its handles and you can have those kind of controls in the world as well.
But we haven't taken time--this--you know, this is not ready for random users to play
with and that's why you see all that happening. And, yes, it needs principles applied. Okay.
Well, I think this is a good place to end the formal presentation. And folks are welcome
to come up and chat more.