Aug 31th 2001.	Camp Smalltalk Essen ESUG 2001

ESUG Day 4.

Back to Day 3

Friday Morning.
The last day of ESUG 2001, seems I missed saying goodbye to some people as they flew out this AM, but I'm sure I'll met them again at OOPSLA 2001 or Smalltalk Solutions next year.

Even if it is Friday and the conference is ending and the halls are packed with luggage there was still room for people to break out laptops and interact with each other for just one more time. Lots of that occurring in various corners, a great thing to see.

So the first thing to see this morning was Tukan which enables GroupWare interaction. If you want to do XP, then this is a good thing

Pair programming with your junior programmers (i.e. your 6 year old eh) Well seriously it's usually the fellow in the cube next door, or the one in your cube. Ok but what if you want to do pair programming between remote locations, some people like your scribe would like to live in Canada for example and consult to Europe perhaps.

This pairing isn't as efficient as true pairing but can you do it with Tukan. So if we look at methodologies like the XP planning game:

Communications
Set rules, structure, communications
Have external customer steering.
etc

You need a distributed planing tool that allows multiple people to capture stories. In this demo we had two machines and two video projectors running so we could see the activity for both players, or should I say developers, or the XP pair.

Ok first I login, then I pick a story and task that I want to discuss with my partner. The other player then selects, changes, modifies, and deletes information in the story. At the same time the information is updated in real time dynamically on my screen. This is cool and it seems a lot of thought went into doing the update process because it wasn't dreadful and distracting like other tools I've seen

The tool also collects information about when work on a story starts, how long, how much etc. and the other interesting thing here is that we can link to other Cards

Designing in Graphics methodologies in contrast to XP

Expressive but it requires effort. Methodology of drawing tool enforces lots of rules. However we have a drawing tool in which you do UML <I think> Layout and animation is done on both machines. The tool has annotation about what the other peoples visual view port is and which object they are manipulating. {Later teleprompters were mentioned, visual pointers to enable remote users to point things out}

Daily programming tasks
Choose a card
Start working in a collaboration aware Refractory Browser
Semi-synchronous conflict awareness
Synchronous presence aware

So in the Refractory Browser we have indicators on the classes and the methods that indicate what is happening. So for example if someone changes a method then the indicator changes to a conflict symbol {think storm clouds, rain, sunshine} that lets you understand someone in the environment made a change that affects you in some degree, light rain or soaked. Because the other people are using a central Envy database then they can load the new edition if this change has affected your work. These indicators prevent one from working with obsolete code. {If you get thunderclouds then it should be no surprise that the method or the one your call, or the class definition has really changed}

There is also indicators to represent other people working on methods. Actually they use color intensity to represent distance <a calculated number showing the distance of the object from other objects people are working on that might affect you, more on this later> I can of course open a chat line to the individual and get clarification about what the developer is doing. The Chat tool used face icons etc, messages go back and forth, so we decide we can do this method change together. We then bring up a Browser together and input code into the method at the same time. Ah some interesting fighting over what was being typed by the two developers, which showed the tool didn't overload and break. But it's not really window sharing, because I can close my browser, but the other person's browser isn't closed.

Because of Envy only one people can accept, the other then loads the new edition.

Question. "What about Audio communications".
You must have a good audio connection this improves things. Much more productive to be able to type and talk about what is happening. Note from another Smalltalker. You need to use headsets, using a regular phone is a hassle that disappears with even cheap headsets.

Since the tool needs to collect information about all the changes in the system, we in fact can log this information, such as method x in class y was changed at this time. This gives you a quite a good overview of what is happening. Also you can see what methods were looked at, etc.

The user experience? "We think it works just great."

Questions
"What if you have a slow connection."
A slow connection is not a problem for us, but it is a problem for ENVY.

{Scribe note. I think the Modular Smalltalk stuff from Joseph can solve some problems in this area, perhaps you can run a central image that uses Modular Smalltalk to receive updates, which are then applied to the image and triggers the Envy update. The remote images could receive and apply Modular Smalltalk declarations to the semantic definitions, and not actually install them into your image until you agree to do that. Just a thought you tool writers should be kept busy over the fall. You'll note we did a similar thing yesterday with Joseph demonstration where a VW Envy image accepted an ENVY change then triggered code requests to flow to a Squeak image}

Tukan is (Technical thoughts)

Maps the software project to a graph
Nodes represents artifacts
Weighted edges represents semantic relations
graph.. etc.

This gives us a mesh from which we can calculate distance, this is calculated by static analyze.

Question, "Use of dynamic analysis?"
Yes we are considering something

Note as I work on things, then distance between items I work on gets reduced. The results sometimes are very interesting. I think this is the answer, versus dynamic analysis.

Comment from audience Michelle Fillman's <spelling> work should also be looked at.

To continue then the objects that I work on or close to become part of the nimbus of the work I am doing. So we used the Refactory Browser, Envy, COAST and the Tukan software space that maps between the Refactory Browser, Envy and Coast. We of course layer the Tukan user interface on top to provide the tool support.

Some more detailed technical information on changes to MVC to capture the user activity. Also some information about the hooks in the browsers to update the indicators. {It all looked very standard}

Where will it go
Porting to 5.i4
Store
Seeking for experience reports
Stronger integration of planning, design, and implementation.
Fixing the test deficit. I've only learned about SUnit recently. Sigh, hard to test GroupWare.

Perhaps we will do something else, my thesis is on distributed awareness. Note if you look at this Amazon page it actually tells you many things, which groups are buying the book, what books others are buying, etc so the context of the book has many other things that are visually displayed based on some interesting relationship.

Conclusion.
etc

Question from Audience
"We got a lot of good things out of pair programming even close together with two machines instead of cramming two onto one machine. Have you found that? "

It's not made a difference (not sure I understood the answer) We added the feature of a teleprompter to assist the partners in indicating things between each other.

Question
"You should show at XP conferences?"

Yes we did show this at XP 2001.


Need for Smalltalk need of OS Synchronization
Frank Lesser
www.lesser-software.com
His software company has been working on a version of Smalltalk for a number of years.

Note demo was given on Windows XP Professional. It's too bad David Simmons <pulsar@qks.com> was unable to attend, many people I talked to really wanted to understand what .NET was and where Smalltalk was going with it, however Frank attempted to clarify things for us. (My developing head cold made it difficult to hear things, I'm sorry I couldn't capture all of Franks Comments).

Frank: "This isn't a completed task. "

Hey how come Squeak doesn't use Native widgets. Well lets look at the
issue.

Smalltalk advantages
Programmers need to target today's OS and browsers
How does this problem affect Smalltalk's observed marketshare
How come Java got successful from living in a browser with emulated widgets, I mean this was a major complant about Smalltalk for years.
.NET a second chance for Smalltalk

Yes Smalltalk is being made available under .NET we should be paying attention.

Smalltalk is a system not a language
Full incremental development
Everything is a first class object
Every change is reflected
Objects are mutated if a class changes (Yes we forget that feature)
Smalltalk uses primitives to interface to the host OS

Low level problems
Recursive callbacks
Interfacing external memory
Foreign function interface

High level problems
GUI frameworks, browser integration.

So we ported our vision of Smalltalk to Squeak.

Other problems
Deploy Smalltalk in DLL's
OS threads, OS processes
Deploy smalltalk in browsers with JRE
Deploy smalltalk under .NET

The recursive callback problem
Smalltalk needs to be recursively called back to fulfill the host requirements
VM needs to be reentrant
During RBC interrupts must be disabled.

So the strategy of OS bindings
VisualAge
Fast JIT, use of Motif, .NET work (unknown). Avoidance of the recursive callback-mechanism forces implementation of special primitives in the VM.

Dolphin
Fast interpreter with minimal OS message loop
Recursive callback over cookie mechanism
.NET work (unknown)

Squeak
Interpreter, JIT in progress (JIT 3 out, JIT 4 in beta)
Set of primitives doing own GUI
OS bindings for non-rcb api using FFT.

.Net (unknown but LSW-LST shares ideas with Squeak)

Object Studio
Interpreter
.NET work (unknown)
Bindings to MFC

Smalltalk MT
Compiler, no VM
OS message loop partly hidden
.NET, deep integration seems possible because some .Net concepts match well.

VSE's strategy of OS-Bindings
JIT-VM with minimal OS-message loop
Recursive callback mechanism
.NET No active development
Formally the best integrated Windows Smalltalk
{Sigh too bad, many here miss it)

AOS strategy of OS-Bindings
JIT VM as .NET extension
No recursive callback (MFC as in AOS 98)
Pure .NET -> smallscr pit
Looks like it has very advance concepts but with MS-VL

Smallscript
Build on top of .NET
Development via MS-VisualStudio, Ack

ST/X
Compiler not VM
.NET work (unknown)

LSW-VST
VM interpreter with minimal OS message loop
Recursive callback problem solved
Patternized MVP based GUI framework
Deep OS integration (windows, mac, X)
Deep browser integration (IE, NS)
.NET support
Twisting NS view LSW-VST's .NET integration

LSW-VST'started more that a decade ago
Used in R&D
More than 10,000 classes
Avoidance of vendor lock-ins
Self like extensions
Rich set of development tools
True translation
Windows bindings porting to Squeak

Share ideas with Squeak, (VM in ST, pure ST-8O)
Available on Windows
Planned on Linux and Mac and embedded systems
Fast interpreters (no JIT) performance tradeoff accepted for maximum design time flexibility and stability

Instruments and framework
MVP based
Interchangeable view hierarchies
Component based
Visual com position
Translation support

.NET integration
No mix between smalltalk and .net VM concepts
.NET inSt framework
MVP framework for GUI (Instruments-Framework>
Translation Browser

Lots of discussion in the room about native widgets versus emulated, in different Smalltalk and Java. Pros & cons

Design time commander assembly for communications
.NET com based smalltalk framework
Rich set of development tools for .net

Windows binding ported to Squeak
Make the Squeak-VM reentrant
Provide recursive callback
Extend the FFI
Serve the OS-Event loop in Squeak
Port the GUI framework

LSW-VST .net integration
We won't migrate yet
.net CLR as a library

Mmm however we've not seen any .Net statements from the vendors.

So a simple Smalttalk .NET program

F := DotNetCLR current new: 'LSW.VST_Form'.
F text: 'foo'
F show

Also examples to show to build a button

So Smalltalk remains pure Smalltalk
Incremental development
No .NET development environment required
Easier migration of existing smalltalk apps
.NET CLR as huge new library for Smalltalk
MSIL translation for pure .NET deployment

Why we won't migration to .NET yet
Simmons has to create smallscript
ISE has to create Eiffel#
Haskell need a CLR extension ror parametric types
C++ is restricted, VB was extended
Java is not available

Source code exposure
.NET is a BIG vendor locking
meta data formation only available over MS's secret API's
self invented DLL hell can be circumvented in a different way

Arguments to use .NET (as a powerful library)
Easier interface to MS world
C#
Smalltscript

Ok lets see the LSW-VST refactoring browser

We have lots of Module-Graph classes
Lots to tools to view Classes & objects in a graphical manner
A tool to give you a visual syntax that you can alter.
Also Spreadsheets
Patternbrowser & Pattern Lab
XML inspector
CPU instruction dissassembler ie 386
Diagram renderer.

{Lots of visualization tools}

Mmm coffee, and I needed some time to pack. This means I missed some material. But over coffee someone asked me why the attendance here was high, double last year. Why, is there some sort of interest in Smalltalk again? Are all these people unemployed and don't have anything better to do. Well if you looked at the presentations this year, they were of a high quality, but more importantly Smalltalkers are busy doing interesting things with tool development and setting the future of programming (once again).

This is reflected in the demonstration ducked into just after coffee. Again Smalltalk using diagram tools to display information about a class hierarchy and of course full integration with browsers to change and refactor code. I think this argues that Smalltalk is alive and well. Mmm I did note this tool had to import at least 7 different types of Smalltalk dialects.

However over dinner last night it was mentioned there was a problem with the large (we think) crowd of programmers who are using Smalltalk who have no interest in furthering their knowledge or know about things like Camp Smalltalk, or Smalltalk Solutions, let alone ESUG. The question is how do we change that, how do we get those people involved. Every day it seems that people discover some of the mailing lists, or comp.lang.smalltalk. Why is this something difficult for people to understand. Perhaps a 9 to 5 job programming in Smalltalk is no different than a 9 to 5 job dealing with Visual Basic. Yet do they have the same fun, the same intellectual stimulation, I'm not sure then again I don't know many VB programmers.

So at noon the conference mostly ends, there is still a few people pair programming here and there, since the facilities here at the university are still ours for the rest of the day. So ends what I think was one of most significant ESUG conferences in many years and I hope next year there will be a just as great an attendance.

In passing I'll mention they need a city and a sponsor or two, so interested people should step forth, after all it is a lot of work, so thanks to the organizers.

Back to Camp,