Business Object Workshop III

OOPSLA'97 "Squeak" Birds of a Feather Session

Moderator: Ward Cunningham

Comments:

• Alan Kay
• Ted Kaehler

The gang was all there. Alan Kay's team from Disney, Adele Goldberg and others from ParcPlace (past and present), people like David Unger and Ralph Johnson from academia, Sam Adams and others from IBM, consultants like Jeff McKenna, and many more too numerous to name. The spirit was high. You can't kill Smalltalk. It is springing up like new grass between the cracks in the pavement with a new name, Squeak. It has an insidious quality like Java did. Alan Kay said Smalltalk died when it left Xerox Parc because it stopped changing, and Squeak is designed to change. But into what?

What is Squeak?

Squeak is the original Smalltalk from Xerox. Highly portable. Completely open. The VM is in Smalltalk. You can hack anything. Everyone's sharing and it is very Smalltalky. The Smalltalk spirit. We don't know how long it will look like Smalltalk. It is designed to change and evolve. (Ralph Johnson)

It is licensed from Apple. You can do anything, including commercial use, but if you modify the core libraries or build a new VM, you will need to post it to the Web. The enforcers are Apple attorney's who have already forgotten about this.

Why is it called Squeak?

Noone ready to answer this question.

Why now?

It came out of Xerox Parc, why ever? It is a new research approach. The commercial Smalltalk has been pushed as far as it will go. Bill Lyons has burnt the disk packs for us.

Where is Squeak?

http://www.create.ucsb.edu/squeak for newbies

Where is it going and who is driving?

What is Disney's role? Alan is doing the same thing forever. The funding just changes. The Squeak team is like Alan's team from a long time ago. Squeak is our vehicle for educational software. What we are doing will not give a Windows host interface, for example. We are aware of the synergy with compatibility with Smalltalk 80, but that is the pink plane. We are going to get it as good as we can on the pink plane, but will start looking up (the blue plane in Alan's slides).

We are going to be careful about how we move forward. We will port it forward only if we really make it better. We will throw away the old disk packs so we don't cause it to freeze. (Some people would like to have it in a runnable archival state.)

Squeak & the Web?

There is a lot of stuff out there about Squeak on the Web. There are Squeak web servers and Squeak browsers.

On the subject of Squeaklets, Squeak has a plugin for Netscape. We have experimented with Squeak as a coexecution process for Netscape. Coexecution takes over the whole screen. The other allows only uses of a piece of the browser. Both good things to think about (Ted Kaehler: tedk@wdi.disney.com). A few years ago we tried out "Active Essay". Have code, button to try it. Change it, try it again. Backup and try it again. Did one of these in Hypercard, one in CodeWorks. Available at Apple or email Ted. See: http://www.research.apple.com/research/proj/learning_concepts/evolution_active_essay/active_essay.html

There is a category called object filing in the release. Can read back into a previous Squeak and it will attempt to fix things up. It files in the code first and gobbles up the object afterwards like Alan's early Air Force paper tape implementation.

Squeak can run on an Acorn and the Oracle NC's are Acorn machines on sale for $200+.

Smalltalk can be a good HTTP client or server. HTML is pretty limiting. HTTP doesn't care. It is a protocol for getting contend. Do something better than a browser.

You need bullet proof proxies and someone needs to build in delegation.

My hope for Squeak is that it become a living Blue Book. Documentation on the Web that executes. The beginning is the mailing list.

Make a small headless Squeak and leave in the Web serving stuff. Dan did a headless Squeak but threw out the socket stuff. Including a text scroller, the full compiler, all numbers except fractions, size is 240K.

What would you keep from Squeak as you move forward?

Focus on this rather than what you are throwing away. You are trapped in a burning disk pack and can only take ...

Where is Envy for Squeak?

The oldtimers don't want Envy.

Coordinating changes to Squeak releases?

If we don't do this, we don't get anywhere with the rest of it. I did a little Endian BitBlt and it worked OK until Dan did something that used it. Ted did some color handling that is Endian dependent. Have to read every line of code to avoid clashing. Some of the BitBlt methods are long and convoluted. I have to study them in detail for every release that comes out. Need to find a way to save our time. Recently WebTalk and WebServer clashed.

There was a community of users that discouraged change in early Smalltalk because of this pain and that stalled Smalltalk. One possibility is that nobody uses it. The other possibility is to figure out how to deal with it (Ralph). It is usually difficult because the change is not explained (Adele). If we start marching down the Envy road I'm leaving the room. A little documentation helps.

You subclass something and overwrite a method. In the next release nothing works. (Reenskaug) Part of my life I took parts of releases. When I got a diff list, change list, it helped a lot, along with filters that help visualize change. Need to have tools to manage inheritance contract.

There is a really low tech approach that works in some situations. Copy the classes. Don't blindly reuse. Own the code yourself. Otherwise if someone else higher up the food chain alters something you will feel the impact.

The Cathedral and the Bazaar - Linux paper that talks about how to manage change in a community. Linux works because people encapsulate things. See: http://www.curtisfong.org/~nyet/cathedral/cathedral-paper.html

Smalltalk needs a component model. But if you go too far you ruin the beauty of it!

You can use the Web for check in and check out. FreeBSD has some automation that works. Many people are modifying the same body of code simulateously.

What I am hearing here is some denial of what we have learned from the commercial experience. The class or the image is not the unit of reuse. With all due respect to Envy, it does something right. Self-testing really works. (Jeff McKenna)

Differentiating between things that are sanctioned in the official Squeak image and those that are not might help.

Piping things through a central checking committee for the next official release can work.

Is there going to be one baseline Squeak or it is going to diverge into incompatible systems? How to package things I have changed that would affect other people that might not want to change the base image is important issue.

There is the fundamental conflict between the research community that wants change and the commercial community that wants stability.

Ship a stream of versioned code that allows people to pick things that support the correct version.

A program that sits on Squeak is not a thing but a process. The culture has to accept that a program is a process.

UNIX did not put anything new in a release unless the contributor ported it to a subsequent release and recontributed it.

I know this is going to be dangerous statement because I might have to do it (Bill Burdick). Would it make sense to create some sort of packaging scheme so that people could examine the small package to see what has changed. People could choose which sets to load in, not just take the whole image. This would be a component based release of a new image.

db, persistent object store and other commercial necessities

I am interested in how objects change in time for testing. Versions of instances and classes (Jeff McKenna). As soon as you have persistent objects, you have to worry about this.

Lots of interest in persistence. Some interested in legacy interfaces for relational databases.

Visual application development?

When will there be a window builder? One exists. The archival code that is up an running does it, but drags a lot of baggage with it. Sam Adams has one and will put it on the KSC web site (www.ksccary.com).

What about people that don't want to build. Need faster Morphic. We did it real quick. It could be made a lot faster. Morphic works right now as a quick widget builder. It came from Randy Smith's work at Sun Microsystems. Original Morphic was multiuser. Squeak Morphic could be that way. Every release that comes out has a little more there. Ted says it is the best graphical environment he ever worked in. A whole class of bugs that he used to have went away. It is not fast but we can fix that. Dan has had it on his list for six months to force us into the morphic world. Morphic is in our future.

What is the state of HyperSqueak?

This was an earlier, experimental take on a hypercard like system in Squeak. Decided not to go down that path.

What are people doing with Squeak?

- porting Squeak to the Newton. Doesn't allow global variables and has other quirks. Creating a C++ class with once instance to solve this problem. Will allow Squeak to run as a DLL. Writing specific chunks of Newton code to load the image. Interested in merging Squeak with Forth. Forth is very close to the metal. Might be some synergy there. Major thing is to use it for educational simulation. My wife and I have a simulation of gardening currently in Delphi. It is hardcoded and cannot be modified. Want to port it to Squeak. Have other educational simulations and am interested in interactive fiction with agents that think about things and give you output.

Adapative systems, Sante Fe Institute stuff. Initially slightly more primitive than early Smalltalk. Have ported in all my old tools. Want to get old Smalltalk class libraries to resurrect some of the great early applications. Just got KSC to release all their old libraries. Adele Goldberg volunteered all ParcPlace's old libraries. Alternate Reality Kit, old Analyst stuff, lot's of good ideas are lying around lost. Lot's of good code in these things that we don't need to write again. Looking for people to help.

Ported Squeak to Windows. This is ongoing work. Porting was pretting easy. Hard to get BitBlt up which you need to see anything. Had to write own byte code trace to get it up.

Interested in graphics in Squeak. Current commercial systems are not very object-oriented. There are some technical problems. I have tried to emulate all the rendering pipeline and it seems to work.

You start with one huge file, 10K of code. The remaining part is OS dependent and well separated. Not hard to figure out how this works. The real work has been done by the folks now at Disney.

Plan to move from VisualWorks to Squeak next year for teaching. Getting tools that used to work in VisualWorks up in Squeak. Suggested by Ralph Johnson.

Wan to provide apprenticeship experiences for Undergrads. Moving asynchronous collaboration and synchronous collaboration tools to Squeak. Want debugging tools and browser in Squeak. Like something like Mathematica. Squeak-to-MOO.

There are tools (WebTalk) general connections class that sits on top of sockets. Webserver available. Modified to work with HTML. Currently supports CGI written in Squeak.

I am the only person I know that gets paid to Squeak. Interval Research is working on using Squeak for handling digital media - CDs, DVDs, cable TV in MPEG. Everything that sits in the home could be run by Squeak. This stuff will never run in Windows CE or something god-awful like that. If I say much more I will have to hire everyone here. Media, hard real-time, 10 micrsecs response time with handlers written in Smalltalk. We are doing off-the-wall things. I can't tell you what we are doing for garbage collection for that. We are doing a port to the Acorn.

Do you want a real time garbage collector? There is one for free. Pause times are always in millisecond range. There is a high performance persistent object store, fastest in the free world and portable (written in C++). Everything is textbooks is wrong. It is not as hard to write good ones as people thought. Working on compressed virtual memory. Good to avoid things like paging. You can uncompress a page much faster than you can go to disk. Our allocator underlying our garbage collector needs work. We have a lot of stuff to give away. Paul Wilson U Texas, Austin wilson@cs.utexas.edu

Trying to make Squeak faster. Have done some great ports. Want to improve performance without sacrificing portability. Squeak is quit good alreay. If you generate an interpreter from the base Squeak you will get a certain level of performance. At a limit, you could probably go 4 times faster. BrouHaHa is a free Smalltalk without the image. Elliot's BrouHaHa runs 4 times faster on a SparcStation. This is slow process because it was a much harder task than I envisaged. You will go from 45 to 10 times slower than optimized C.

With a bit of optimization I have gotten numerical code to run in threads at 60% of C speed.

Two major steps. The first is to improve speed of message sends. Worked first on a context cache. Smalltalk spends an immense amount of time allocating and reclaiming context. The design is great for the programming model but bad for the low level implementation. There was a scheme in the original Squeak for something like this. Want to keep the top most recent contexts in cache as objects that can be reinstated. This allows message sends to run much faster and the allocation rate goes down. Blocks become reentrant for free.

Now working on dynamic translation. Still have byte coded methods. Before they get executed they get translated into an execution friendly threaded form. You are as close as you can come with threaded code to actual running code. You have a 32 bit op code space. You can peek ahead in the byte code and do several byte code sequences in one. Would you call this a virtual RISC machine? Two stage pipeline is there. You can create self-modifying code allowing message send to run faster. At the moment in Squeak the output code has a lot of overhead. Self-modifying code could optimize this.

Our approach is to keep everything as portable as possible. The heap interpreter (original Squeak) is easy to understand. The context interpreter goes faster for message sends. Good for embedded work with low overhead. Dynamic interpreter is third approach which is fast, easy to understand, with more overhead.

David Unger says some of us have done high performance virtual machines and the maintenance overhead has been enormous. Need to publish performance results as they are created.

First interest was native code translation 12 years ago. I am interested in reconstructing parse trees from byte code. Maybe a new compiler to write assembler in Smalltalk. I like the low level stuff.

Would like some multiple inheritence. Have almost got exceptions. Delegation would be easy. Bill Burdick (bill@appliedreasoning.com) said he has already done it and it is up on the Applied Reasoning web site.

Lots of people are not doing more serious thing because of the lack of native widgets. Conservation of evil. Can't get rid of it but can push it out of the way. Would like to see TK used as a universal windowing system. Completing configurable and can make it look like anything you want. Easy to make it look like ParcPlace or Windows (if you are that mad).

There are lots of people present that would like Squeak to take over the whole Window. There are lost of MSDOS machines out there that could run Smalltalk again.

Dave Unger - is anyone exploring removing classes or variables?

How could they make it faster than Self might be the question.

Should we have a Squeak conference?

Maybe, not resolved at this meeting.

Conversation with Jeff McKenna as meeting broke up.

Squeak is going to have to talk to other objects on the Web. In fact, Squeak will need to talk to other Squeak objects that are running on a different base image over the Web. If it doesn't do that, it is not interesting except for embedded systems, a niche market.

The power of Squeak is evolution. That means there needs to be ways to wrap Squeak objects as components that hide the inheritance hierarchy from one component to another because there are going to be a lot of versions.

There is only going to be one ubiguitous virtual machine, Java. And its handicap is that it must be stable.

Therefore, Squeak components are going to have to carry the VM with them. It better be small. The Web will force the Squeak community to do this if they want to participate in the larger world.

Business Object Workshop III