April 19th 2001.	Smalltalk Solutions 2001

Sunday Night

Day One, Smalltalk Solutions 2001

Sigh, 6 am, have I ever mentioned that I hate getting up early, but where else can I have a continental breakfast and discuss the future of computing, or should I say Smalltalk. Over eggs I discussed some things with Les as he prepared for his presentation this morning, then we were off to the convention center. Just inside the door we found a crowd clustered around the entry lines waiting to get their denim shirts with the 2001 Smalltalk Logo. You didn't come? Sorry you don't get a shirt, but you'll know who was here by the shirt they wear to the office next week. I must say they are the nicest shirt I've ever gotten at a convention.

Because of my pending presentation my mind was on more than just writing up the convention, so in the morning I attempted to get a feel for how and where Smalltalk was going. My first choice was to attend Cincom's presentation on eBusiness Solutions at which I took a few notes but they don't completely present all that was discussed at the presentation.

In the room there was about 50 people, stragglers later brought this up to over 70 people, perhaps we violated the fire regulations…

Some notes from the slides, but I'm sure your Cincom rep will be happy to get you a copy of the real slides. The next generation of VisualWave was being introduced, it uses a Web servelet model and a template model. Yes Smalltalk server pages. For the new Smalltalk users you must explore a bit of history. VisualWave in 1994/5 was the first to bring web server technology to the web and deal with issues like remembering state between http connections. It was a tool to convert existing applications to web pages but HTML was an issue, concurrency was a problem.

But VisualWave has aged over the year so:

VisualWave needs to come up to new millennium.

Better connectivity, conforming to Web standards, and retain it's good qualities was the feedback that Cincom got from their clients. Support of application is an issue, you must have separation of presentation and domain logic. The Web look should be managed by the web folks, the domain programming by the software engineers.

Coming features:

FastCGI
Open source support
Separate resident application.
ISAPI for MS IIS.

Secure Connections
Support for SSL, but usually the real web server does this.

Coming DES, RSA, SHA, MD5
Read/Write X.509.
Potential for signed parcels.

SSL in Smalltalk is really fast!
2X faster than C examples.
Cypto work requires large integers.
C code is un-optimized for this type of work.

Servlets
Java Standard, part of J2EE spec.
Look and feel like them but work is done in Smalltalk

So?
Hey it's standard, we need this, because it's base for JSP.

Basically some Smalltalk code to build HTML on a stream, based on the session information.
Boring but important. Cookie support, etc. All what you would expect..


Servlets are ugly.
HTML needs to be managed.
Change is difficult.
Change can take a long time, unlike static HTML you can't just change things this afternoon for tomorrow. It's a program, change cycle is much longer.
But they are good for input.

For example on smalltalkchronicles.net there is a subscription form, this page runs a Servelet to collect the information. The code here gets the parameter information and builds the HTML, then it created a email message to send, and then builds the response to give back to the client for feedback.

Other interesting things
Locales by user to support European clients.

Server pages.
Small amount of code, Most of the HTML

Web designers can in theory maintain the HTML, but code can crept into that HTML.
Remember it is code, it's not in a Smalltalk browser, it's hard to manage and debug
So be careful. The pages can contain a mixture of special tags that resolve to Smalltalk code so you can write loops to construct HTML within the HTML as an example. But in some respects how is this different from embedded JavaScript.

Just then I bowed out to see what was up with Squeak and the artistic community. Down the hall STP was giving a demo of Siren. About 16 people attended, not too bad a representation, on the way I met up with one of the conference sponsors and was told the walk in crowd was good and had pushed the number of attendees to well over 300 which greatly exceed their lowest attendee estimate.

At the time I entered STP presentation a deep discussion about MIDI latency was being discussed. It was interesting to compare and contrast the differences between the two crowds and the objectives of those people. As one could see there was a large number of business programmers present, but yet the conference had streams that allowed the artistic folks the freedom to explore new ideas quite different from the business domain.

Coffee. Need Coffee, actually we need a never ending supply of coffee and snake food, perhaps the extra people caused confusion for the catering staff. The hallway was crowded with Smalltalker from around the world, I was discussing Macintosh OS-X and VisualWorks with George Heeg, other were discussing IBM's solutions for web services in Smalltalk and much more was afoot. The overall feel was wonderful, start marking those calendars with the date for Smalltalk Solutions 2002.

After the break I attended the Building COM and .NET in SmallScript ™ by David Simmons for a few minutes

About 70 people in attendence. Standing room only.

David talked about his Smallscript goals, he then launched into an explanation of how Smallscript is build by showing us the source code. If you were a Microsoft developer this would have been very interesting, and it is interesting to see how it all interfaced to the existing MS framework for development.

David's take is that Smalltalk is built wrong for scripting, it has a monolithic image. It really should be a bunch of Smalltalk pieces. Smallscript isn't a Smalltalk traditional image. It's the best features of the language but changed for doing scripting.

SmallScript is small, it is free, it's not an IDE. It's a compiler and execution engine. Someone else needs to build an IDE and frameworks, QKS may build a simple IDE but these aren't an important part of their research. Smallscript like all scripting languages is text based just tackle it with your emac editor.

Someone asked what is the revenue model for QKS?
It's not tools (We all know that today, look around how many tools companies are there?)
Consulting is a big part
Microsoft is a big part.
Python is a big part for the execution engine, this is a new area. The Smalltalk VM runs Python 10 to 100x faster. {JMM I should point out the Perl and Python folks are working toward having/wanting/needing a universal VM}

SmallScript is subset of Smalltalk dialects, not of the frameworks. You can migrate frameworks, and it has a lot of features for foreign function interoperability.

David then moved on within his slides and talked about the files you need to support Smallscript. The point being there are only a few small files required.

He then brought up the VisualStudio project for building this and explained how the VM starts and worked us thru what happens when the VM launches. The execution path is very short and took about 85ms on this machine, thus 12 executions a second. A more optimized VM, this was a test VM, would run faster. However David pointed out on a heavier loaded machine you could have at least a 30ms variation in startup times because of system load. But the key point here was that you can run a lot of individual scripts per second if required.

Later at lunch David pointed out that perhaps it wasn't clear in the presentation that the entire image is built from the class definitions at startup, there is NO image. It's all built from the definitions really really fast. On termination a module can decide if it must save a persistent state, which could be loaded on restarting. In fact If I recall correctly he say that a rather large smalltalk image would be built by the engine in less than 6 seconds. From nothing to a known state on each startup, this is a important concept.


On-ware to DLL hell, well maybe not. .Net get out of this problem domain. Components are self describing and have versioning which allows you to resolve all the requirements to run an application and to move things around without harming the application. Smallscript allows you to build small DLLS which are compiled very quickly. Smallscript takes the strengths of Smalltalk, it's a simple grammar it's untyped. And it's easy to refactor and change versus C or C++. In Smalltalk it was hard to deal with the outside, handing a Smalltalk object to an external DLL is/was an adventure. In .Net it just gets passed, no wrapping or marshalling etc.

Alas at this point I had an errand to run.

Over lunch discussion ranged from the World Squeak tour, which is progressing thank you, to how SmallScript works, to issues with decimal math. This was interesting the claim was made that some implementations of Smalltalk use fractions to do decimal arithmetic which leads to hidden round errors. Really they should use large integers and keep information about where the decimal point is. It sounds like a test suite is need to confirm if scaled decimal works on all implementations, who in the ANSII group would like to do that? If this cross section of ideas wasn't enough I assure you much more was cover and that was only at our table, you must wonder about discussions among the other 300 dinners.

After lunch I attended the Socket workshop. The objective was to launch a Camp Smalltalk project to build an open source version of a socket implementation and different protocols for talking to the Internet. Then if you build on that layer you can more easily port your application between different dialects of Smalltalk.

Most Smalltalk have poor network implementations, and poor ways of extending the implementation. (Smalltalk/X does provide easy way to extend). In general most implementations are just good enough to get the work done, but porting between dialects is impossible. So can we write an entire Socket implementation in Smalltalk , file it in, file it out? Well this is difficult to do. David Simmons and Peter Hatch led most of the discussion.

A key point was that errors should become exceptions, and these given to the users, not the error code. The error code information should be packaged up for diagnostics which then could be used by developers to solve sticky problems.

David talked about how QKS did real time interrupts at the VM level to deal with incoming Socket events, so issue like blocking/non-blocking, out of band data etc aren't issues, because these get handled and dispatched to the handers that deal with those events as they occured. When you build sockets you assign handlers for each interesting event, or take the default handlers. Each handler has a process waiting for the event to occur. The VM wakes up the process when required and hands it the information about what just happened.

So, if you can get hardware interrupts and can signal a semaphore then you can do this. The other issue is how to get the data back from the error at interrupt time.

David talked at length about thread local storage, so that you store error, locale, date/time for each process. Globals are BAD! Although this talk was about sockets, it really focused on VM things. I talked about how Squeak handles things and that you can async signal a semaphore. Actually at hardware interrupt time you can queue up a semaphore signal which then is check by the VM about 200 times a sec. On the semaphore signal the current process is put to sleep if it is in a lower priority than the process owning the semaphore. If this is not the case the process in question becomes runnable, but when it runs is dependent on when the higher priority process get to run.

Bruce asked about how this applies to his vision from 10,000 meters. If we build a model based on the TCP/IP specs what does that mean . If for example we do a close it was pointed out in Squeak that close and terminate with the default of 10 seconds was a problem on slow connection. It was pointed out that it should really be close and given the transfer rate, we make a decision how long to wait. So work is required to nail down a spec which ensures we don't run into interesting problems.

More technical discussion about how to read a socket was discussed.

I mentioned we needed SUnit to confirm the behavior.

If we spec out the contracts for the BSD layer and above, then use existing implementations we can do it all in Smalltalk, then if later VM implementers can change things at the primitive layer to improve and better remap the logic.

Later in the hour we discussed the legal stuff, the IP ownership and who will lead things, how will people go to the next step. It was also mentioned that we need DNS support. Discussion on how long would this take, how much effort, and who do the work.

Another key point is that Objects should be opaque and implementation dependent. Many implementations may use the same representation, but some data structures might be different based on CPU storage issues. This prevents mapping/translation on each platform. So the spec is behavior, not data related.

Also need the layer above: (FTP,http,SMTP), streams, telnet.
This could be view as
Primitives
VM Level
BSD
Streams
NetWork protocols.

More discussion on licensing occurred and I had to run another errand.

At 6.00 the sponsors were kind enough to feed us all dinner and provide music. Conventioneers crowded around tables, and reflected on how this was the best experience they have had in the Smalltalk arena for a long time.

Somewhat down the hallway I was listen to Georg Heeg, STP, and Michael Rueger talk about historical Smalltalk events. STP perhaps learned that his recollection of when he saw his first Smalltalk system was a few days off, and I was amazed to discover that Michael got involved in Smalltalk a few years before our teenage son was even a thought. But the question was raised where are all the Parcplace people, lots of current Cincom folks a foot, but none of the people who laid the foundation for Smalltalk, sad…

It's 8:30, and I've had 4 hours sleep in the last 36, so I'm off to review my presentation notes, and work on these trip notes. Tomorrow I'll have more words, alas I didn't get to Camp, but I hear John Sarkela was there explaining the Squeak World tour.

Tomorrow Alan Kay is going to talk, stay tuned for the broadcast.

Tuesday