Smalltalk Tidbits, Industry Rants

It's a good idea to consider every post you make to a blog - and Mark Pilgrim points out today's example: Google re-edits. I seem to recall pointing this out awhile back....

Staffen Malmgren discovers Seaside, and likes what he sees:

At first look, Seaside doesn't look much different than ASP.NET. It's all about modelling your application's interface in terms of objects and methods ("messages" for you Smalltalkers). Pages are built up of components, inheriting from System.Web.UI.Control (ASP.Net) or WAComponent (Seaside) that can include other components. When the user does things with any component, it results in events being fired (ASP.NET) or messages being sent (Seaside). Both frameworks seem to strive to abstract away the request/response nature of the web, and to allow the programmer to use a more event-driven approach to developement. In addition, seaside uses at it uses continuations to make it possible to, for example, ask the user something (similar to how a modal dialog would do it in a normal GUI enviroment), and then do something with the provided answer -- all within the context of a method.

The main difference is that programming in the Seaside framework results in a lot less housekeeping code. The object is really a ordinary object, except that it's executed through the web. The difference didn't really dawn on me before I tried to recreate WACounter as a ASP.Net Server component -- it did involve a whole lot of code to handle events, manage viewstate and so on.

It's cool that people are finding out about Seaside and what it can do.

The Baltimore Sun answers the questions you didn't know you had.

So Scoble says that the XP SP 2 rev will have IE mods. Will this fix the absolutely horrible thing that the last "fix" did to IE? Apparently, there's a security hole in IE involving the use of urls of the form: http://username:password@www.host.com. You would think MS would fix that, hmm? Why no - their solution in the last set of patches I grabbed from the Windows Update (read: downgrade) site just turned that feature off. You try to use it, and IE gives you a "Syntax Error page". Grrr - at least this explains why I've been getting mail from people trying to download CST NC via http. Here's what Scoble says about the fixes:

While we're on it, this page has one falsehood. It says that the next version of Internet Explorer won't come out until Longhorn. That is absolutely NOT true. The next version of Internet Explorer comes with a ton of security fixes, and a pop-up-ad blocker. It will be included in Windows XP, Service Pack 2. For free.

It darn well ought to be free, when it's a downgrade. There should have been a big warning on the last set of patches: "Warning - this update turns off useful features of IE, because we can't be bothered to fix the actual problem. Download at your own risk".

Bob Congdon points to this excellent essay that I've been meaning to discuss:

The golden rule of programming has always been that clarity and correctness matter much more than the utmost speed. Very few people will argue with that. And yet do we really believe it? If we did, then 99% of all programs would be written in something like Python. Or Erlang. Even traditional disclaimers such as "except for video games, which need to stay close to the machine level" usually don't hold water any more. After all, who ever thought you could use an interpreted, functional language to decode Targa images, especially without any performance concerns?

Follow the second link to the original essay - it makes a point about how fast things now perform even in fully interpreted languages on modern hardware - pointing to the absurdity of things like primitive data types in Java. In the vast majority of applications now, that counts as premature optimization. The software industry is guided more by inertia than logic. People continue to select unproductive languages based on the "everyone else uses it" mindset. They stick with manifest typing, even when the best data we have (from Capers Jones) - shows that languages like Smalltalk produce lower error rates than languages like Java. This in turn empowers the managers who want to offshore development - if the results are bad in any case, they may as well be bad for less money.

I'd say that the software industry is where manufacturing was in the 70's - complacent and ready for a kick from foreign competition - but I don't see that happening anytime soon. Why? The big Indian firms are all into huge masses of paper and CMM compliance levels - my cantankerous theory is that you should avoid any firm that claims CMM-5 like the plague (unless you like rigid requirements and huge backwashes of paper). If you really want to outpace the competition, you might want to pick up a dynamic language - Smalltalk, Python, Ruby, Lisp - and run with that.

Bad news for those of us who like coherence in a series - "Enterprise" looks to be back next year, with Berman still running things. If UPN wants to improve the series, the best thing they could do is to fire Berman. Can you imagine a Star Trek with Joss Whedon - i.e., someone who can actually create a story arc that hangs together? The best I can say for "Enterprise" this year is that - unlike "24" - it hasn't completely jumped the shark....

I posted on this topic back here and here. Now, I've come across this perspective on the issue from a woman "in the trenches" as it were. I can add a side note to this - I introduced my daughter to this Girl Scouts site, and she explored it for a bit - but peer pressure intervened and she's back on NeoPets - because all of her friends are there. Now, there's some (small) value here - she's starting to learn bits of HTML and CSS - the site allows you to build pages - but it's not exactly what I had in mind, either. I'm not sure how - as a parent - you manage to redirect towards "better" content. I mean, it's not as if NeoPets is a bad site. Time wasting, sure (but then again, no more so than BSW, where I spend inordinate amounts of time playing Puerto Rico....)

As much as I think Atom is a waste of time, end users shouldn't have to care - that's why BottomFeeder supports the format (both 0.2 and 0.3 - change your upgrade path to 'dev' in order to get proper support for 0.3). So I was a little surprised to see Scoble complain that Radio still doesn't support the format. That's just silly. Atom is a clone of RSS with different tag names; adding support to a tool that already handles RSS is trivial (it took me less than an hour for Bf). As I recall, I only needed a couple of slight additions to the domain model (the additional dates, for instance) - almost everything was a simple mapping issue....

In a Planet Lisp entry, I see that this blog shows up in a PubSub search feed for Lisp references. Heh. I mention Lisp from time to time when I'm discussing the general topic of dynamic languages, but Planet Lisp is where you want to go for Lisp Info. Also Bill Clementson's blog.

MSNBC's business wire picks up the Cincom Press Release congratulating Alan Kay.

James Gosling says that the world needs more "crazy" people:

There's an interesting article at Wired: NASA Funds Sci-Fi Technology. It's all about a part of NASA that funds projects that many would consider completely crazy....

Most real innovation is done by crazy people doing crazy things

Maybe he could follow that advice, and advocate for a JVM that would properly support dynamic languages. Nah, that would be crazy....

We had one heck of a set of thunderstorms roll through the area last night - at one point, my wife and I ran to the door to see what had gotten hit (a particularly loud clap of thunder that seemed simultaneous with the lightning. I'm sure it hit something; I haven't had cable modem service since then :) The cable TV signal has been horrible as well; I suspect that the signal reaching my house is too weak to get me net access. So here I am, feeling the power of dialup. Maybe I should have held on to that AOL CD that came in the mail Saturday....

After many requests, I've added a preview function to the comment form on the blogs here. It only works if you have cookies enabled though. There's also a pointer to the wiki style markup rules that the comment form supports - if you check the appropriate box, those rules will be used when you post.

The NYC Smalltalk User Group is running a poll (membership required) - they want to know whether an StS in New York City would pull in people. Our (the STIC) primary concern with an StS in New York has been the high cost of New York City. In any case, if this is of interest to you, join the STUG's mailing list and let them know what you think

Some image formats are "lossy" - i.e., putting an image in that format can lead to lost information. I'm starting to feel like Java and the CLR are "lossy" with respect to the entire field of software development.

First, there's this post from Roy Osherove. Now, Roy is a good guy - I've had some very pleasant exchanges with him via the comment sections of our blogs. But look at this - in response to a post I made about BottomFeeder plugins:

I wonder how plugins are supported in SmallTalk. What's the Smalltalk equivalant of Reflection, for example? of a DLL? dynamic loading?

Is there an equivalent of reflection.... It's kind of hard to know where to start with that, honestly. The reflection that actually exists in the CLR is a pale reflection of what you get in Smalltalk. I mean, take a look here - that's a paper from OOPSLA '89! I'm not quite sure how you would implement Method Wrappers (the cited page is old, and newer code is already shipped with VisualWorks) in C# or Java. Reflection in Smalltalk is just so much more powerful than what is available in the mainstream languages, but the mainstream languages are so prevalent that it's as if the information has been lost.

Take another example - this post by Victor Ng - he asks which camp is worse, Lisp or Smalltalk:

Which camp is worse? The Smalltalk people or the LISP people? It seems that both those groups just love to say "we did 20 (or 50) years ago"

I suppose it does come off as arrogant and irksome - but it's the simple truth with respect to so many things in software development. Just take a look at one of the big things buzzing around the software world at the moment - self healing systems. In Smalltalk (or Lisp, or other similar systems), new code can be loaded into a running system and override existing methods - or add new methods to existing classes - or add attributes to existing instances - all without having to take the system down or having to worry about the state of objects in memory. Heck, I patch this blog server that way all the time. Lars Bak talked about this in the context of small devices, explaining why Smalltalk was such a better choice - the ability to do on the fly updates.

The dead hand of rigid systems holds the entire industry back. You have to jump through enormous hoops just to accomplish the simplest thing. I'm hardly the only one thinking this - I referred to this essay just the other day. Developers new to Smalltalk tend to pick this up right off

We need to do a better job of explaining this - or else the information loss is just going to continue

Before he left, Michael presented me with a small container of Vegemite. I gave it a try out at StS 2004 (just a dab on the fingertip) - it was very strong that way. So I brought the container back home with me, and it's been sitting on the counter since last Thursday..... So I finally decided to take the plunge. Following Michael's instructions, I:

• Toasted some bread
• Spread butter on the bread
• Took a small bit of vegemite, and added a thin layer into the buttered toast

And it was pretty tasty! Durned Aussies - it's not like they sell this stuff here :) - but it can be procured online. Hmmm

Update: I just found these two hilarious descriptions of Vegemite here and here. And don't forget the "vegemite song"

I went to see Van Helsing yesterday afternoon - it's an ok movie, although the CGI is pretty weak at certain points - the opening with Mr. Hyde is not that well done, IMHO. The movie does move right along though - which is good, because if you stopped to think at any point, you would notice that the plot was as thin as Friday's soup at the elementary school. It's an enjoyable enough "bubblegum" flick - i.e., if the popcorn is good, and you don't really have anything better to do with two hours, go ahead and see it. Otherwise, I'd say wait for it to come to cable.

Patrick Logan states the truth of it:

So JDO is a mess (original report), certainly EJB is a mess (hence JDO), but let's face it, the root cause is the language itself.

And it's not any better over there in CLR-ville either. The dead hand of rigid systems is holding the entire software development world back....

This is a fascinating story about free WiFi access - and the way it's quite possibly outrun the law:

There is little doubt that when you "piggyback" the WiFi signal you are "accessing" -- or "using the resources of" -- the device that is providing the Internet connection. There's also little doubt that routers, access points and gateways are all computers within the meaning of federal law.

The U.S. federal computer crime statute, Title 18 U.S.C. 1030, makes it a crime to knowingly access a computer used in interstate or foreign communication "without authorization" and obtain any information from the computer. A separate provision makes it a crime to access a computer without authorization with "intent to defraud" to obtain "anything of value." Fortunately, this provision also specifies that it doesn't apply if "the object of the fraud and the thing obtained consists only of the use of the computer and the value of such use is not more than $ 5,000 in any 1-year period."

The article goes on to point out that the law was never written with WiFi access points in mind, and that it's not going to be used that way. Still, it points out how unintended consequences tend to slip through when broadly worded statutes are written up. The thing is, this has broader application than just WiFi and law - companies often have very broadly written policies - where the intent is to stop people from doing something bad. Written broadly enough, do they also stop people from trying anything new? Something to think about the next time you sit down to write up a policy directive.

Back to the legal issues on this. The article points out something really interesting about the fallout from this:

But wait, you say, I didn't knowingly access the computer without authorization -- there was no security on it. How was I supposed to know that I wasn't allowed to access the WiFi connection? Here is the troublesome part: If you accept this argument -- that by broadcasting a connection you are inviting others to share it -- you end up on a slippery slope. How much security must you have on a system in order to be able to prosecute someone for accessing it without authorization?

That is a slippery slope, no mistake. Now translate that to the cable segment you live on if you use the local cable company for internet access - see how easily you can fall off this cliff? Go read the whole thing - it'll start you pondering this mess...

Vince Bourgon explains why getting things done in the "modern" languages is so painful - virtually nothing has been learned from the the past - heck, MS has even forgotten what made Basic productive...

No interactive interpreter

I think this was one of the biggest annoyances of all. When I learned languages like Python, like Common Lisp, like Smalltalk, it was always possible to easily and interactively test things. The fact that to test simple things in C# I had to build a whole program, write what I wanted to test, have some output functions to see the results, compile and finally run the program. This took time, and when I had a bug, I had to go back to my editor, find the faulty line, fix it, save and try to compile again. This was much slower than using an interactive interpreter. I had never used sockets in C# and had to make a small program to see how they worked and all. Again, an interpreter would've made things easier and faster. If it wasn't for the very complete MSDN documentation, C# would be a much, much tougher beast.

Gosh knows how far I ever would have gotten with BottomFeeder without the power of Smalltalk. Clearly you can do such projects in C# or Java; there are plenty of such readers out there. But it's harder to get things done. When it's hard to get feedback, it's hard to be productive. And then look at this example:

Simple stuff is made complex

My program contains a Hashtable with the keys being school numbers their name (001 - School Foobar) and values being their IP address. When I ran the program for the first time, I realized something that I hadn't thought of: Hastables are unordered. I wanted the school to go one by one, in alphabetical order. I had this line in the program foreach (string key in ht.Keys)

So I said to myself that the simplest thing would be to change the line to:

  foreach (string key in ht.Keys.Sort())

But this resulted in a compiler error. The hashtable Keys properties returns an ICollecton object which cannot be sorted. So I thought, I just need to take the ICollection object and cast it to an ArrayList:

  ArrayList myKeys = (ArrayList)ht.Keys;
  myKeys = myKeys.Sort();
  foreach (string key in myKeys)

But this raised a runtime exception. After some googling around, I found a solution on this page. Basically, I would need to create my own class called IterSort() to sort the keys. Who else thinks this is way too hard? On the other hand, look how I could've done it in Smalltalk:

  
  d := Dictionary new.
  d add: 'Hello' -> 'World';
    add: 'Bonjour' -> 'Monde'.
  d keys class. "This returns the class of keys, which is a Set"

Now that I know it's a Set, I can just sort it by converting it to a sorted collection:

  d keys asSortedCollection.

The whole thing is just so much easier in Smalltalk than in C#.

He's got other good examples, but the two above illustrate something - yes, there are scads and scads of libraries available in Java and C# - this is something that is continually pointed out to me. On the other hand, if you have to constantly plow through crap like the above, I'm not sure the library size buys you as much as you think - especially when systems like VisualWorks already support a sizable proportion of the extant stuff you need. Take a look at his article, and let me know what you think.

Brad Abrams covers some of the TechEd sessions.

There's a Java/Server conference going on - I've been reading the coverage over on the Bile Blog. It would be nice to get an alternative POV :)

Wired News has a report on the WinHec conference (held in Seattle at the same time as StS, actually). I was kind of interested in some conference reporting - something like this or this from StS. However, all I've been able to find is stock media summaries. Were there no bloggers taking notes?

Via Lemonodor

<malaclyps> i'm going to Camp Smalltalk this year
<malaclyps> i believe as a UN Observer
<malaclyps> it's like Camp X-Ray but the interrogators try to get the prisoners to document their code

LOL

Pete Kruckenberg makes some good points while letting a rant go about Java - here's what I mean:

If you can't develop Java code that is 100% compatible with every version of every JVM, in an application that is compelling to be portable, don't bother. Compile it to a binary for the platform that I'm using, and make it look as good and work as good as any other application for that platform.

Ignore the reference to Java there, because it's a universal thing - end users want an application, not an installation problem. I've tried to get there with BottomFeeder - the only place I really miss is Mac OS 9 (I still need access to the hardware). From the few people who have tried downloading Bf for that platform, I know where Peter is coming from.

PR Opinions posits that the wider array of information available (for any and all products) is making the sales cycle longer and more complex:

In the past, I might have got a couple of brochures from some manufacturers, visited a couple of retail outlets and made a decision. Today that purchase process is far more complex.

I'll search for all the manufacturers. I'll go to all their sites and read their literature.  I'll visit the relevant magazines and read the reviews, visit mailing lists, consumer opinion sites. I'll still pop into the retail store and finally I'll make my "educated" opinion. Then, once I've parted with my cash and my post-purchase cognitive dissonance sets in, I'll re-visit my chosen vendor's website to be reassured that I made the right decision.

That is a longer and more demanding sales cycle.

Hadn't really given this much thought, but it sounds right. There's a positive to this as well - in the software space, the "row of books at Borders" problem has been ameliorated somewhat. As more and better information appears online, you can compensate better as a niche player. It takes work, of course, but it can be done. Read the whole thing.

Ted Leung points to some IBM blogs - Grady Booch and a number of other people are listed on the site. Ted is complaining about the RSS feeds being for the current month only. I'm not going to complain about that - the feeds for the Cincom blogs are a rolling snapshot in time. I'll have to trawl through the IBM site and see what looks interesting.

Nasa aims to find out - check out this experiment.

Joi Ito points to an NYT article (free registration required) on IRC - surprise - the Times is convinced that IRC is a huge den of iniquity:

Even as much of the Internet has come to resemble a pleasant, well-policed suburb, a little-known neighborhood known as Internet Relay Chat remains the Wild West. While copyright holders and law enforcement agencies take aim at their adversaries on Web sites and peer-to-peer file-sharing networks like Napster, I.R.C. remains the place where people with something to hide go to do business.

That's right gang - all we do on the Smalltalk IRC is trade illicit copies of movies and games. No technical conversations, no meeting with far flung friends, no ad-hoc support - not according to the Times. It gets worse:

"I.R.C. is where you are going to find your 'elite' level pirates,'' said John R. Wolfe, director for enforcement at the Business Software Alliance, a trade group that fights software piracy. "If they were only associating with each other and inbreeding, maybe we could coexist alongside them. But it doesn't work that way. What they're doing on I.R.C. has a way of permeating into mainstream piracy.''

Ahh, the fine folks at the BSA have been interviewed. These are the people who who help transform your business into a user hostile gang. And the NY Times is enabling that sort of mindset to spread with sludge like this:

When I.R.C. started in the 1980's, it was best known as a way for serious computer professionals worldwide to communicate in real time. It is still possible - though sometimes a bit difficult - to find mature technical discussions among the tens of thousands of I.R.C. chat rooms, known as channels, operating at any one time. There are also respectable I.R.C. systems and channels - some operated by universities or Internet service providers - for gamers seeking opponents or those who want to talk about sports or hobbies.

Still, I.R.C. perhaps most closely resembles the cantina scene in "Star Wars'': a louche hangout of digital smugglers, pirates, curiosity seekers and the people who love them (or hunt them). There seem to be I.R.C. channels dedicated to every sexual fetish, and I.R.C. users speculate that terrorists also use the networks to communicate in relative obscurity. Yet I.R.C. has its advocates, who point to its legitimate uses.

After the obligatory "some people on IRC are ok" comes the slam - and it's quite a slam, making sure to associate IRC users with groups that the mainstream Time reader is going to find unsavory. Here's the thing - IRC is no different from any other human activity. There are nice places and not so nice places. Just as there are clubs where you can go and hear music (and others where people engage in slightly less savory activities) - there are a wide variety of IRC channels. I suppose the Times has to play up the "ugly" as a way of pushing sales. People are people, online and offline...

Via CLS, news of an upcoming STUG meeting in NYC - if you missed Smalltalk Solutions, here's a chance to see one of the talks:

Please join us for our second presentation of the month on May 18th.

Speaker: David Buck
ElastoLab is a shrink-wrapped VisualWorks application that allows kids to design their own 2D scenes that incorporate physics elements like particles, springs, and gravity and lets them see their scenes animate in real-time. Originally written in C , it was later completely re-written in Smalltalk.

David will be talking about the development history and the design challenges in writing ElastoLab. The talk will explain:

• how to interface to the Windows sound facilities from Smalltalk
• how to make graphical applications run quickly
• how to package a Smalltalk application for release
• developing help facilities and guided tours
• using the web toolkit to develop a message board on the Internet for ElastoLab.

A CD-ROM of ElastoLab will be available to all attendees.

Date	May 18, 2004
Location	Suite LLC offices
Address	440 9th Avenue, 8th Floor
Time	6:30pm to 7:00pm -- Open house
Time	7:00to 8:30 pm -- ElastoLab

Directions:
Take E or C train to 34th (Penn Station) walk to corner of 34th and 8th. Walk up one block to 9th.

RSVP is requested. Please send mail to: charles@ocit.com with subject line of: NYC Smalltalk May 18th, 2004.

Via CLS, news of the next STUG meeting in NYC - if you missed Smalltalk Solutions, here's a chance to see one of the talks:

Please join us for our next meeting to be held May ,Tuesday 11th.

The OpenSkills Skillsbase Project
experience report
Bruce Badger: OpenSkills

Abstract: The OpenSkills SkillsBase is implemented using the Swazoo HTTP server running in GemStone, all hiding behind a Squid reverse proxy.

Bio: Bruce is an enthusiastic technologist and the Founder and President of OpenSkills, a global non-profit association of professionals who provide a wide range of open source related services. His strong technical leadership skills have contributed to his success on a huge diversity of IT projects, over a period of more than 20 years. He has built and deployed many Smalltalk systems and libraries over the past 10 years.

Date	May 11, 2004
Location	Suite LLC offices
Address	440 9th Avenue, 8th Floor
Time	6:30pm to 7:00pm -- Open house
Time	7:00to 8:30 pm -- OpenSkills Skillsbase Project

Directions:
Take E or C train to 34th (Penn Station) walk to corner of 34th and 8th. Walk up one block to 9th.

RSVP is requested. Please send mail to: charles@ocit.com with subject line of: NYC Smalltalk May 11th, 2004.

Yahoo points to Cincom's congratulatory message to Alan Kay.

It's been a great show - My talk went well this morning, and I received some very nice feedback - thanks to all for the great questions! It's been good to finally meet the withStyle team face to face - I look forward to seeing the lot of you in Australia, even if I have some trepidation about the vegemite you provided :) It was a great show, and I hope we have as great a time next year.

Brian Rice talks about Slate. Generally works in language research - very inspired by Self - working with Lee Salzman (not here) - designing Slate with him. Looking for flexibility and minimalism. Want to do what Squeak does, but better. Slate is free, under the MIT license. Want to use a lot of the good ideas in Smalltalk, and bring them together. Admits that the number of unique new ideas in Slate is small. Implemented first cut using Lisp. Why a new Smalltalk? Self and Strongtalk promised change, but we ended up with Java instead. The existing ST vendors have customer bases to deal with. Squeak is free and malleable, but has too many small issues - new designs can't tackle all of them. Really wanted to push together the right set of ideas in one place.

Influenced by Self and Strongtalk. Also by CLOS and Dylan. Wanted to combine best ideas from these disparate systems in one place. Slate development started in 2002. Self was not practical - big demo. Squeak was moving in too many directions, in their opinion. Slate the language is based on objects with slots, prototype based language. methods are blocks that close over their arguments, and have a syntax signature that activates them. Smalltalk is single dispatch - Slate is multi-dispatch. Slate specifically allows for object-specific behavior and state, and multi-argument dispatch. They call this combo "PMD".

All arguments are receivers and they play different roles. Objects do not relate to methods in the same way they do to their slots. methods are cooperatively held between many objects. No self/super keywords - not reserved. lookup is accomplished through messages to the context

Method lookup is performed in cooperation with the arguments - dictionary is searched depth first, left to right, methods ordered by their "distance" from the arguments. The distance is "deterministic" and the "closest" method applies. Optimization needed to be done early as a result.

Slate started with Self's inheritance model, using special slots to store delegates. Shared "traits" contain behavior, not state. This was found to be too dynamic. a pattern - does not distinguish enough. Now looking at new models - Looking more closely at what Self did with descriptors. Looking at Squeak traits for ideas.

Wanted to keep the syntax as close to Smalltalk as they could. So what's it look like?

collections 
	addPrototype: #NoDuplicatesCollection
	derivedFrom: ExtensibleCollection.

nd@(NoDuplicatesCollection traits) add: obj
[
	nd include: obj
].

So it looks like Smalltalk, but oriented in a prototype based direction. Macro-methods - syntax parse trees are an object medium for communication. can annotate these with type info or declarations, or describe a pattern that the compiler van recognize and optimize on. There are tools being built for this.

Summary - this is very early development work - the VM has only just been done - it's a work in progress. Plan is to go VM-less and bootstrap.

Smalltalk evolution panel at StS 2004:

Members: Lars Bak, Martin McClure, Vassili Bykov, neil Konz

Vassili: Evolution happens. Works on tools, not the "language part" of the system. Still, gets to be in that area quite frequently with what he does. Pretty much, given the way Smalltalk works, we all end up playing in this area.

Neil: Agree that evolution happens. Especially in Squeak, it moves in a lot of areas at the same time. A surprising number of Squeakers are playing the language design/evolution area all the time. Evolution in how it's being used. While Alan Kay had the initial vision, he's not pushing from that end. He's funding/pushing his own projects - he looks at is as infrastructure. Some are evolving to make it smaller (Squat), make it a Web Services system, Seaside, graphical experiments (Croquet)... No one is selling it - has pros and cons. Good: No one to kill it, can only die through lack of interest. Con: It's a "spare time" thing, people will only work on things of interest to them. Smalltalk has a bright future for server side work and scripting - other scripting things aren't as good

Martin: Smalltalk needs to get better - contradictions:

• Size
• Smalltalk should get larger (Gemstone - bigger repositories, etc)
• Smalltalk should get smaller (embedded systems - like Lars)
• More Innovation, but also more interoperability between dialects. Should be more discussion between implementors on what is happening and what should happen. Too many times we've had slightly incompatible similar ideas.
• More free Smalltalks - commercial Smalltalks need the ideas

Lars: I'm not a language designer - what will get it more accepted? Better support for Scripting - need to be able to use Smalltalk from "standard" file based tools. The other scripting languages (no names :) ) are pretty much all bad. Focus on what Smalltalk is good at - need to quantify it better. Talk about features, not "religion". Should have a Scripting Smalltalk

Q: Eliot "hijacks" session. Smalltalk community is simply that "we're better" - no uptake, turns people off. Need to explain what actual problem we are trying to solve. Want to sell aspirin, not vitamins.... Draws us a picture of where Smalltalk ought to grow. Off into a business model thing....

Lars: Find a niche where you are better than the competition and try to grow there. Don't fight the same battles - find new markets.

Alan Knight: Push simplicity - point out how easy it is to get started. Point out how quickly you can get into the system and start accomplishing things (closer than where step 1 is "create the XML manifest file"

Bob Nemec: We are techies, not marketers. Have the STIC step up more - get the word out.

Neil: Have to reach the decision makers - not just the tech guys.

Me: Get involved - Get a blog, get the message out there.

Sam Shuster: Get better pages to show up for Smalltalk searches on Google

Vassili: How to carry the message - make sure that the message is positive, not snarky or put down -

Dennis Smith: Marketing - there is stuff we can do. Starting with VWNC is not as simple as it could be (ed. - the New Class dialog helps). Generally, the ramp into the product is harder than it needs to be. Say I wanted to introduce Smalltalk to high schools - what can we point to as help?

Martin McClure: Squeakland.org and EToys. This is solved somewhat in Squeak.

Neil: Yes, EToys and the toys associated with it really does work for getting people into scripting - can and is being used to draw people into Croquet. "People don't buy languages - they buy solutions to problems". Got into ST by looking for something like ControlWorks

Bruce Badger: talk to Linux groups, introduce things like Squeak and VWNC to people, show them what you can accomplish with these tools. Show the open source one, show the commercial one - crowd was very pleased

Rich Demers: Wanted a panel on what should be done to evolve Smalltalk, not a marketing discussion. Lots of things have stayed the same since Smalltalk-80 - should we look at new things for Smalltalk? Look to other languages for ideas? Need some forum for talking about these sorts of things - some organizational thing through the STIC?

Alan Knight: STIC is not a faceless thing - it's a known group of people who are quite busy, and spend most of their time organizing this show. After this show we may actually have some money and be able to do some things - but we need help. "Ask not what STIC can do for you".

Martin McClure: Evolving is done in order to survive better. Need to get the word out in order to be able to evolve.

Bob Nemec: There is a large open source community around other things (Linux). Perhaps we should come up with a "common Smalltalk" effort.

Alan Knight: Not true that all the work is in Squeak - Ralph Johnson's Camp Smalltalk effort has worked very well. Lots of open source work in VW as well.

Sam Shuster: Dialect portability - used to do SUnit ports across ST dialects. For a long time was concerned - at this point: "Who cares?" Bob: Risk management

Martin Kobetic: Too short a time to get things done, nothing gets done between the sessions. "What is Smalltalk?" Squeak? VW? There are efforts (like GLORP), but it's fragmented.

Hunter: used to do Smalltalk back in the 80's - now doing financial services, came here because "it's time to do Smalltalk" - web services make it easier, "no one cares if the server is Smalltalk". Offering a clean object platform that can deal with standards based communications are possible. Only obstacle - getting the examples to work are harder than they need to be.

Lars Bak's keynote address on embedded work in Smalltalk. Lars was involved with Strongtalk - Animorphic, was also involved with HotSpot at Sun - now this

How to make embedded systems "servicable" - i.e., how do you update the thing in the field w/o having to recall it? Example - visiting a VC, met an exec with a big car, digital display - "BSOD" on the screen, had to "reboot" the car - the vendor's answer was basically "yeah, so?". With phone users, you can't get updates as you do with desktop clients - phone users will just switch phones. Need a better way to keep these users.

Past VM experience:

• 1986 Beta - 1990 Self
• 1996 Java HotSpot - 1993 StrongTalk
• 2000 CLDC HotSpot - 2002 Resilient

Wanted to sell StringTalk to Wall Street - but the Wall street folks were thinking "Java" thoughts. Went on to Java HotSpot. Now working on Resilient. So the agenda:

• Resilient in embedded systems
• A variant of the ST language - some additional syntax, will explain
• Implementing OS services
• Product licensing

This is a technology preview at the moment. VC backed company. getting second round of funding, so they are moving forward. Today, most of the embedded systems are pathetic - they use C linked to an RTOS kernel. Very slow to build and debug. In this space, short turn-around times are critical - with some electronic toys, times are measured in weeks. Updates are either not possible or monolithic firmware updates (reboot). Typically using unsfae languages, no servicability, very static model. Support is "reboot it and try again". Customers don't like that idea.

Predictions for this space?

• Software quantity doubling annually
• By 2007 it will be impossible to buy a non wireless device
• Device R&D is dominated by software development. True even in "old line" industries like auto

What does inductry want?

• Increased reliability
• Low cost (resource constraints)
• recalling a device (like a phone) can run to $50 per device)
• Dynamic updates in the field
• Real time capabilities
• Rapid development cycles

Is embedded Java the answer? - No

• Does not support incremental execution
• VM spec is very complicated
• Bytecodes not designed for speed and compactness
• Configurations for embedded systems are too big
• CLDC and CDC
• Configurations are growing...
• Resilient is targeting down to 128k size chipsets

What can we do better?

• Dynamic language
• Increased productivity
• Connect dev env to the running system
• On the fly updates

Example - Bang and Olufsen tested Resilient to service and control a digital speaker. Able to do field updates w/o recall to the shop. Customers don't like having to do manual turn-around. Transparent updates possible (as is done with ReplayTV and TiVO devices) - have it updated w/o user having to deal with it.

• Platform for crearing secure, OO real-time software
• Minimal memory
• increased productivity
• Enables correction in the field - with deployed software

Examples - take a snapshot of field system and send back to engineering for analysis. use SMS for pushing updates. Two pieces:

• Embedded Platform
• OO OS - 32K
• Pure OO System
• Platform independent mobile code
• Libs for device drivers, networking
• Unified resource mgmt - everything is in one heap.
• IDE
• Connectes to running system
• Supports true incremental execution
• Full servicability and visibility - can change device drivers as it runs

This stuff can be deployed on small hardware (With Bang and Olufson, they had 256K - so they tossed in a web server so that they could look at the results). Cell phones are another platform - especially the ones not running an OS - can add in this system pretty easily. You can use this on a host OS (desktop) for development purposes. The development environment provides the reflective behavior, reflective ifc in the device - allowing for changes to all subsystems in the device. They have customized Eclipse for Resilient. They have also done this for Smalltalk/X, but did not like the environment. Programming support for debugging, profiling, introspection in the plugin... They built the Eclipse support using the Eclipse plugin support.

The VM is portable and simple. 32 bit VM, compact object model, scalable object heap. new bytecode set for Smalltalk. 20 bytecodes with uniform format. Optimized interpreter, inline caching.

• Unified Automatic resource management

• real time GC
• policy based, user definable
• guaranteed allocation/scheduling behavior per thread/application

Smalltalk with a few twists - trying to make a simple system

• Introduced full syntax for classes
• Allows for File based storage
• Atomic test and store statement
• Namespaces
• Typed LIFO blocks
• Removed
• Pool variables (not useful)
• Class instance variables

Shows us the file format for code - looks pretty simple, only a few nits from the crowd on assignment of stuff. method def:

key	=	(^key)

Critique - use something other than "=" for defining a method. Now, blocks in this system are not full objects, so when using them you have to declare them. Minor restriction. The main thing is, it looks like Smalltalk. The changes are all related to issues surrounding actual issues in this field:

• Device constraints (memory, etc)
• Developer expectations in this field (file storage, using tools like CVS)

Class libraries - minmal set of libraries provided. No reflective behavior - only the programming environment can create a class. #perform: is not supported - makes it easier to determine what needs to be downloaded to the device. Scheduler and device drivers are supported, as are standard network libs (TCP/IP, SLIP, NIC, Firmware). Small collection hierarchy. Shape changes are supported. Example:

• Two kinds of integers
• SmallInteger (20 bits)
• LargeInteger (32 bits)
• Writing device drivers on a 32 bit computer requires 32 bit arithmetic.

Namespaces - Able to modularize code. Classes can contain other classes, which is how namespaces are implemented here. Accessing:

Network::Service::Echo install

Performance - issues

• Allocation of block contexts
• inlining of control structures
• flattening of code (Collections)
• Interpretation overhead
• Slow method invocation (only 32K available here)
• results in breaking down code abstractions
• or apply advanced inlining compiler

Block example - Typed LIFO blocks. Stack allocated contexts require no escape guarantee. LIFO block ikmplementation speedd up block code.

collect: [collect] do: [block] = (self do: [:e | block value: (collect value: e) ].

Sharing methods - 10% of methods can be eliminated by doing this (sharing byte codes). "Super byte codes" - computed based on static bytecode pair histograms. With space for 255 byte codes, and only 20 in the system, can create "app level" byte codes on the fly doing runtime analysis.

The Scheduler is written in Smalltalk - so that's field servicable as well. Very cool. The device driver API is simple, mimics the raw hardware. VM provides an abstraction layer. The resilient VM is 2X faster than the JVM for these devices! Supports:

• Bunch of devices - see the site (below)
• IA32/Linux
• StrongARM/Embedded Linux
• Windows
• Symbian OS
• Mac OSX

tech preview available at http://www.oovm.com. Free for NC, pay for commercial. OOVM is actively looking for initial projects, and will make it attractive for prospects.

And a demo - plugging in his phone to his PC, and connecting to it. Synching dev env classes with the device. Developer gets notified of what's there and what's not. And he's executing code on the device. There is exception handling, very simple, but follows the Smalltalk model, using a Java-like API (throw, try, catch). And there's a Wiki here

Mark Roberts and Rich Demers talk about SmalltalkDoc. Mark started with ST back in the late 70's at PARC. Rich started with VAST back in the 80's. What is SmalltalDoc?

• Standards and Facilities to provide reference documentation for Smalltalk
• Authoring tool in the IDE
• Web Application for browsing

The goal is to separate the documentation from the implementation of the system - allow people to learn w/o reading all the code. The documentation can be gathered from a Store repository by the application. Who is the intended audience?

• primarily new developers
• reach out via the internet
• not a substitute for PDF - an addition to online help

Why Smalltalk Doc?

• Reduce the time/effort to learn ST - get them up to speed quickly
• Provide a simple overview of the environment and lower the learning curve to a learning bump
• Improve the "out of the box" experience for developers new to ST. Motivations:

• Need reference doc - we used to have the "Cookbook" in 2.5, but it was huge, and never updated. The ObjectReference was a stab at doing this
• Emphasis on use of the class library
• "Learnability" vs. "Simplicity"
• Learning the class and pkg library
• Need to clarify the functionality of the system
• One of the big issues is the API - what is it? In many cases, our libraries have no API in the sense that developers in other languages define the term. It's a manual "eyeball" process of inferring the API...
• Making the system more approachable is a key goal

The general issue - we have a gap in knowledge - we doc the system, but do not have a "Users Guide" for new people. Using this:

• Authoring content in the IDE
• Generating content for the web
• Browsing content for the web

Now Mark is going to demo the system. The system is built on a content mgmt system built atop an OODBMS. Presented via a VW web toolkit application. What he's got is a prototype that can produce a doc view of the class library - from the package and class view. Now on to Rich. Hmm. UML diagrams of the domain. I know these are useful, but w/o a camera, I can't convey what I'm looking at here....

They have a browser-like tool for displaying and editing content. Basically, the same information that was available on the web side is available in the browser view. The bottom view is an HTML Pane (Twoflower now - WithStyle eventually? Content entry is text. Interesting flare up of conversation on the concept of entering content - current prototype requires HTML tags - why not Wiki markup? Too much work - they want a WYSIWYG kind of tool in the end. The content will be stored as XML.

Q: How does this information get entered in the first place?
A:: Information gathered automatically (garnered from the Smalltalk system), converted into an XML form, and then translated for display. The idea is to keep all this info with the code so that it gets versioned off in Store.

Q: Does this work at all with the Web Services work?
A:: Huh?

Q: What about using something like the JavaDoc approach?
A: The desire is to integrate this with the system. Should be possible to create a tool to "peel" the doc off from the system. The domain model is tied into the code, so it stays with it. The idea is to keep it that way.

Q: Will there be an interface for end users to "mark up" the documentation?
A: The web side? Sure, that could be added via permissions. The tools themselves will be available for end customer use

Day two of StS 2004 is done - all my reports are up, and Michael has a bunch up as well. We're off to the Space Needle - I have to talk at 8:30 tomorrow morning - come learn about BottomFeeder.

Len Lutomski, Martin Kobetic, and Sean Glazier are going to discuss what's been happening and what's in the pipeline in the general area of distribution tools in VW

What's new in VW and OST?
Agenda:

• VW-OS interop
• ASN.1
• Opentalk enhancements
• Opentalk IIOP
• WebServices Tool
• SSL

VW-OST interop - OST has native widgets and a nice story on business interaction with databases. VW has a lot better server support and scalability (and more platforms). Now we have a simple demo of VW - OST - two images, VW, OST. Some simple workspace code in both places. The demo - push a bunch of objects from OST to VW, and print them to the Transcript - and it works! It's not done yet - no demo of other direction yet due to some issues. It's almost done, and will be ready to use in the next release. It's at beta (in OST) now. Have not ported multicast stuff, had to make some changes due to socket, threading, differences. The main warning:

OST users should never open an Inspector on a RemoteObject or any subclass of SelfInitializingObject. Has to do with remote references. In the beta, there are issues with remote exceptions across the boundary - those will be fixed before release.

There are app level issues - class differences, divergence in core classes (Character, Set, Point, Time...). Differences in Blocks, Namespaces - but the basics work!

ASN.1
New marshalling framework for dealing with ASN.1 - fairly complex structures to deal with. The marshaller is pretty fast - a lot of optimization has happened here. So - why did we bother with ASN.1? It's used all over - LDAP, SNMP for starters. Also, VW 7.2 actually had 3 separate variants on this - we are unifying the framework. There are many different encoding styles - BER, DER, PER...) - doing this exercised the marshalling framework and allowed us to "shake it out" in a productive, useful way. Also gave us a way to experiment with abstract type systems (useful in FFI work) in Smalltalk.

Opentalk Enhancements
In version 7.1, enhanced the protocol - released an update.

• Increased the number of tagged classes with optimized marshaling
• Added tags for user employment
• Added two new pass modes
• pass by name
• pass by OID
• refined pass mode control

Improved Connection Handling
In client/server - evil to drop a client request. In the web world? If we get overloaded, it's ok to drop them. What we did is to make the web server load handling more robust. Added load balancing, pushed the Wave/WTK server to Opentalk. Added an Opentalk console - makes it easier to configure and manage orbs.

Remote Debugger
Attach and debug - i.e., attach a debugger to a remote system. Managed through a simple API - allows you to set up a way to debug a headless image, remote or otherwise. Allows you to define a "monitor" image which exceptions will end up getting forwarded to.

AT Profiler
Replaced the profiler (monlithic) with a modular piece of code that supports multi-process profiling. This is the first step towards making this stuff fully supported.

Opentalk IIOP
The re-implementation of DST as part of Opentalk. This will make our CORBA story up to date and allow for support of things like RMI over IIOP - i.e., better Java interop. So Martin has started a Java ORB and name service, as well as a Smalltalk broker. Reusing a lot of the old DST infrastructure. Replacing the transport layer.

Web Services Wizard
You want to make some existing VW piece a web service, or hook to a remote web service. He's showing the actual wizard - I suppose I should try building a trivial service with this and blog about it at some point. Generates the server (SOAP) class for you. You can also have it generate an Opentalk client for you, and have it generate a simple test script. And it can generate a WSDL file as a file, as a class method, or as a document posted to a URL. And you can do it in reverse from a WSDL file as well.

Security Enhancements
Cleaned up the public APIS, starting in VW 7.1 supported things like DSA, RSA, Diffie-Hellman. in 7.2 the hashing APIS were cleaned up, allowed the computation of a running hash. And it's all documented in the SecurityGuide.pdf (in the docs). In 7.3 we plan to get X.509 and the new ASN.1 frameworks done. Allow generated keys to be imported/exported in standard ways.

SSL and Https support
How about an HTTPS server? That's supported as of 7.3. Lots of small improvements here "under the covers". A short customer story:

• Financial house posts trades to NASDAQ using HTTPS client and SSL framework.
• Saves $5000/month over an MQS link to NASDAQ
• No manual entry - HTML pages are automatically read, filled in and posted. Report and retrieval is automated as well
• Other companies are still using MQS a and struggling to manually enter data within the 45 minute NASDAQ requirement
• Implemented in less than a month and running for over a year
• Handles 30 million callbacks per day on average from other systems.

VisualWave updates
Brokers moved over to Opentalk - unifies the server framework, easier to maintain. Completing the migration of infrastructure over to Opentalk.

What's Next?

• Consolidation - trying to do too much
• Will do a few new projects as required
• There are things the team wants to do anyway :)

Want to distribute all the tools - browser, debugger, profiler, inspectors - everything. Long range plan - won't happen until a lot of other things gets done first. More work on the load balancers - state replication and failover. Remote configuration - would help in Automated testing. In that vein, make SUnit remotable. Coming soon - VW-MQS bridge. It's being done by Heeg as a service job, will come in as preview soon, supported later.

Q: MQS should be accelerated
A: It'll be in preview for 7.3, supported afterwards. You'll have access
Q: What about using SRP for passing by value?
A: We would have to look, can't make any promises. We do need to look at that area though, and it's something we plan to look at

A .NET developer asks:

All these languages (Smalltalk, Python, etc) are pretty far from being strongly-typed imperative languages, so it seems that it is indeed possible to use more dynamic languages on the .Net platform. Indeed, Jim Hugunin, the author of IronPython (and Jython, the Python-on-JVM implementation) notes that while his initial intention was to write an article titled "Why .NET is a terrible platform for dynamic languages", he ended up with the conclusion that the CLR is indeed a good platform for dynamic languages. My question is: Is anyone using these languages on the .Net platform in real projects? I'd be very interested to hear any success stories.

Any answers?

Vassili Bykov discusses the VW tools. Vassili: "My hair isn't blond, it's gray. It was black when I started working on VW Tools". Vassili points to the badges, where the names are like this:

James

Robertson
Cincom

Given the font usage, it looks like I work for "Robertson Cincom". Point is, presentation matters. So if the presentation is confusing, the user won't be able to figure out how to use it.

Trippy
A demo - a couple of inspectors. Showing multiple select, and that you can do "accept" of values across all selections. Yes, there's an undo. You can drag/drop between inspectors, and within an inspector (re-ordering an array, for instance). The evaluation pane adds a workspace in the tool. There's also navigation (dive down, etc). Here's a screen shot:

Next - pragmas
Started to appear for dynamic menu additions in VW3. Why was this required? Well, say we add in a tool (3rd party) that needs to add a menu item. Now posit a second tool that wants to add another new menu item? The last one to modify the menu wins. Pragmas solve this by allowing the menu to be defined in chunks. More uses of pragmas:

methodWithPragmas
	

	^3   4.

Look at the byte code: No byte code for the pragma? Look in attributes under attributes - annotated Method. Here's a screenshot:

Add a class method like this to get rid of the warning:

pragmaDeclaration
	

	^#(example:difficulty:)

You can write "script" to collect up methods with pragmas and figure out where they are. Then you can script this in the inspector - as Vassili just said: "Try that in Eclipse". So back to menus - the system just collects up pragmas of a given sort (i.e., referring to a selector) and builds the menu. It turns out that Vassili has been using pragmas to extend various tools - like the new "dock" at the bottom of the VisualLauncher - see class VisualLauncherToolDock.

What about the matcher in the Store tools and the class finder tools? Have a look at class CompletionDriver. It's easy enough to "plugin" to a UI:

postBuildWith: bldr
	completionDriver := CompletionDriver new
		widget: (self widgetAt: #inputField);
		choicesHolder: (self computeCompletions).

Then you have to set up the #computeCompletions method - basically a matter of telling it what you are matching against and how.  

Tool Modules

Things like the IncrementalSearchDialog are built up from component modules.  The main one is IncrementalSearchModule (a class in VW).  The basic comment: "IncrementalSearchModule is a combination of an entry module and a list module. As the user types in an entry field, the module searches for objects matching the input typed by the user and displays the result in the list module.  ".  As it turns out, you can use this module in applications - it's pluggable.  There are a number of utility methods (like #forClassSelector) that make some uses easy, and point out how to build others.  The only other thing to do is to create a method for noticing changes in the input field, which in turn queries the module.  

Interesting - he's showing a pragma that lists a set of relays - more or less a smart delegation target list.  You can use this instead of a hairy #doesNotUnderstand: implementation.  

Ahh, the Settings Framework.  Made my life easier in [BottomFeeder>http://www.cincomsmalltalk.com/BottomFeeder].  Adding your own settings is pretty easy, and customizing the way it does storage of settings is very easy - it defaults to an XML file, and I have Bf dropping an ini file instead.  Cool - if you blow settings code, you get a "Debug" button right in the settings tool.  

Georg talks about Smalltalk on mobile devices. October - Cincom's German sales guy asks about Smalltalk on the pocket PC. Within a few months he was demonstrating VW on Windows CE 4. Will be fully supported in the 7.2.1 release (later this spring). What do you need?

• Win CE4.x (alias .NET)
• Windows Mobile for Pocket PC 2003
• Any variant of CE 4

Examples

Siemens Simpad PC, SkeyePad, Tatung Webpad, iPaq, bunch of others. Where did this idea come from? The DynaBook that Kay (et. al.) dreamed of at PARC "back in the day". Is this the Dynabook? Adele Goldberg Feb 2003: "This does indeed look like the original conception". There's more to the quote, whee she says that the challenge remains to make programming more like modeling, but it's too much for this non-touch typist to copy down...

What about the actual market? There was an interview with a Gartner analyst (Bill Clark):

• Pace is critical- mean lifetime of a mobile device is 18 months!
• ROI must be in 18 months
• Portability is important
• J2ME differs a lot from J2EE (as .NET compact differs from .NET)

Then there was Mark Driver, the Gartner analyst who stated that: "It does not matter what features Cincom Smalltalk has, Smalltalk market will not grow".
Tom Nies (Cincom CEO, 2003) - pointed out that there were proposals to close the US PTO in 1845, as "everything" had been invented

In Germany, mobile device manufacturers have become very interested in Cincom Smalltalk on mobile devices. Heeg produced a demo for this manufacturer (Hoeft and Wessel) in 25 hours for stock-taking, impressed them a lot. Asked for a demo and slide presentation immediately. He got a facility management application - and they released a press release to the mobile market talking about this. The upshot? Smalltalk is ideal here:

• Pace - productivity
• Portability - Windows/Linux/CE
• Technology does not matter as the devices are outdated in 18 months

Target Market

• Professional users of mobility
• Professional mobile software producers
• This space wants turnkey solutions, from solution providers

The competition?

• J2ME/PJ - incompatible with J2EE
• C/C - every device is different
• .NET Compact
• Considered immature
• Windows CE only
• Big Suites (IBM/Sybase/Oracle) of turnkey applications

What about Cincom Smalltalk Mobile?

• You need VW 7.2 VM for Windows CE (XScale/x86/StrongARM)
• CE parcel (part of the distro) - get the latest updates from the Heeg website
• Load CE parcel, deploy the application as appropriate - it should "just work"

Likely, you'll need to adapt the UI to work with a pen interface and the smaller screen turf. The bottom line though - develop on any supported VW platform, deploy to CE. No changes at the code level required....

How fast are these devices? Early Pentium range.

George Bosworth's keynote on the Microsoft CLR, and his personal comparisons of it to the Smalltalk/V VM. George was one of the founders of Digitalk

Why a personal perspective on this? George is one of dozens of architects on the CLR. Why compare specifically to Smalltalk/V? because it's what George knows best from the Smalltalk world. The CLR has been built by a lot of people coming from a diverse set of backgrounds - COM, VB/VC, J++, MTS, Smalltalk, Scheme, Lisp, etc.

I am and always will be a Smalltalk fanatic

Nomenclature - the CLR has lots of code names, and terms are and have been used over. George admits that he's not good at nomenclature anyway. "There are official names for things that he's supposed to know" :)

The CLR is a acommercial platform for languages and tools. A platform for languages and tools is trying to enable divergence and differentiation over time. A language toolset (like Smalltalk/V) is leveraging conformity and uniformity. So there's a different perspective. Smalltalk/V

• GC, IL Based
• Debugging, execution svcs
• SLL's
• FFI
• Smalltalk libs and components
• Basic language libs, change control, UI builder, source control

CLR?

• CLR Execution engine
• GC, IL, JIT
• Debugging, execution svc, remoting (etc)
• Externalized PE files (DLL, Exe) contain pieces
• BCL base class libs
• CLS language interop rules - this is the layer that defines how different languages will interoperate and play together here
• Pile of specs - important to a platform
• Codified standards

• What's not part of the CLR? Lots of tools and services and libs from others (both in and out of MS).

Where are the tools and libs? Available from MS and others (insert marketing information here :) ) Unlike Smalltalk vendors, MS not trying to provide everything - providing a platform to build on, not an end all. The CLI runs in something and things run on it. As a technology, the CLR is similar to a Smalltalk VM. It's in the details that diffs emerge.

The CLR is not itself a product though - things built on it are products. As opposed to Smalltalk, which is sold itself.

Now a walk through the CLR (Common Language Runtime). There are actually many CLR implementations at MS:

• Desktop/Server (CLR)
• VS.NET
• WS2003
• Whidbey
• Longhorn
• Rotor - close to desktop version, under shared source license
• Compact Framework
• Phones, PDAs, etc
• SPOT watch - see Scoble's blog

This talk is mostly about the desktop/server implementation.... The runtime control flow looks a lot like any other VM (In particular, like the JVM with the security model). So code (VB, VC, etc) compiled to IL, which the JIT then turns into native code which executes. There is an FFI. There's an interesting "pre-JIT" piece as well which he'll get to in a bit.

• "Econo Jit" - used in Rotor (slow)
• generates unoptimized native code
• Code can be discarded and regenerated
• "Standard JIT"
• Generates optimized native code
• Pre-JIT generation
• Done at install time
• Reduces start up time
• Native code has version checks and reverts to runtime JIT if they fail
• Assemblies - akin to parcels, SLL's, Squeak Segments
• One or more files, independent of packaging
• Self describing via metadata (manifest) - everything but the executable bits
• Versioning
• Captured by compiler
• policy per-application as well as per machine
• Security boundary
• Assemblies are granted permissions
• methods can demand proof that a permission has been granted to entire call chain
• Mediate type import and export
• Types named relative to assembly

What happens at compile time?

• Compiler reads imported metadata and builds internal symbol table
• Compiler resolves method overloading using languae specific type matching rules
• Compiler adds any required coercions or casts
• Compiler selects and records a precide member ref
• Compiler provides object layout requirements through its choice of
• Layout technique
• Non-static fields
• Virtual methods, with "new slot" vs. "use existing slot"
• Compiler emits metadata by nerging incoming metadata with metadata that's been generated
• Compiler emits IL with metadata tokens

What happens at class load time?

• A type ref occurs and is resolved to an existing type or an assembly ref
• Assembly is loaded
• If no managed native code available, IL module is loaded and first validity checks run
• Class is then validated and the CLR creates in memory data structs
• On first run, JIT is used (and verified if needed)

Jit - a whole lot of stuff you expect (inheritance checks, etc) happen - plus security checks. Finally, the code runs. Permissions can apply here - the security model can block this. This is a richer model than Java, because it sounds like it can be much more finely tuned. Ok, a picture of the "standard" model for compiled apps - code to exe file to directory to run. How about the managed world? source to IL assembly. To deploy, you can use tools that verify the assembly. PEVerify will do checks on the assembly. Then deploy to the GAC (the new registry!). To run, the assembly is loaded and the policy manager checks permissions (based on security model, if any). One interesting fallout - Assemblies (and the CLR) have been written to be hosted inside other applications. Different from most Smalltalk systems.

What's the Pre-JIT? an MSIL to native compiler. precompile, pre-load, pre-layout. Validated at execution time. May factor in the processor type, other assemblies, etc. If it ends up invalid, the normal path is used. The goal is to speed startup time - due to a smaller start up working set. Usually used as part of assembly installation. This tool ships as part of VS.NET - ngen. The theory is that a lot of steps get jumped if the pre-compiled assembly is valid at runtime.

Deployment Models

• Shipping and Installation
• Compile IL in build lab
• Ship IL
• PreJIT during installation
• Possible JIT during execution
• patching and servicing
• Deliver new IL image - could be huge though
• Repair native images (all depending on assemblies)

Application Domains - where assemblies are loaded and executed. Subprocess level of isolation. Defines own types and manages own memory - controlled by hosting policies. Objects in the domain are isolated from other domains, and will talk to them via remoting (proxy operations). This allows you to run disparate versions of libraries and have them all work. Hosting is about policies:

• Security
• Threading
• Threads vs. fiber scheduling
• Robustness
• Exception propagation
• Hosts load, initialize, and set policy for the CLR

An example - SQL Server won't allow a loaded application to use threads. So if yours does that, it won't load you. I see the point, but I have an issue here - same one I have with the final/sealed quandary. To my mind, it all assumes that the developer shouldn't have control...

What about memory issues? Again, this ends up being a policy setting thing. Ok - on to ST comparsion - he's calling it a toolset vs. platform view (I'd argue that Smalltalk, particularly VW, is a platform - but I get his point). The platform (CLR in this case) is concerned with guarantees that people can depend on. Language models (here he means Smalltalk) is different and concerns itself with conventions.

Specs matter more to a platform - changes affect too many people, so they are difficult to fix. Interestingly enough, Joshua Bloch of Sun said the same thing at ot2004.

Opportunity for questions:

Q: Rotor vs. CLR
A: Lousy code generator. Not as optimized. Not concerned with things like COM/OLE, so a lot of infrastructure for it not there. Mostly close

Q: What about in memory stability of objects (in ST - what about CLR?
A:What do you mean by that? Important to have type safe memory? Yes. The CLR should never corrupt memory.
Really talking about productivity/interactivity of objects during runtime (image, etc)
A: We don't do that (image) now. Statement that the image can be brittle. Uses PARTS (originally built for OS/2) and portability as an example.
Question is really about interactive development (workspaces, etc)
A:What is the state of the application that you want to persist? Hmm. I'm not sure he's answering this... Question - can you modify the code while it's running? can load classes. What about shape changes? My question - the blog server - patch on the fly. About state changes - Apparently, ASP.NET has some facilities in this direction, but it sounds complex and sounds like it only handles things forward, as opposed to extant stuff in memory. I think the short answer is "No"
Q:What do we do to survive in the CLR world?
A: learn to live with the CLR

Q: What is lacking in the CLR to support Smalltalk?
A: Tag typing support so that Smalltalk's object model could work. Says that Anonymous delegate stuff will help. "Intermediat late binding" support - Not good support now, needs to have it for good Smalltalk support.

Q: To make Smalltalk work and play in .NET, does it need to be type capable?

A: No, but it needs to be type aware. George related some early Smalltalk/V work in that direction.

Heh - comment from a Smalltalker doing VB.NET on the IRC channel: "I'd say it's about as good as you'll get at putting objects on basic, but it and .NET strike me as rather Rube Goldberg-esque"

Online at the show, or interested in what's going on? Join us on the Smalltalk IRC Channel and listen in!

The room is really filling up - we are getting ready for Sam Shuster's Pollock talk. Sam starts out asking which Smalltalk people are using - most of the crowd is using VW and/or VA. There's a lot of former VSE users here as well. Why is he asking? Because Pollock has borrowed ideas from all the major Smalltalks, from Delphi, and a variety of other systems. The ideas behind Pollock have all been validated (in part or in whole) in other extant windowing/UI systems. So how did Sam get into this? He interviewed with Cincom (5i.1 timeframe) - he was asked what he'd change if he could change anything? He answered: "the GUI! it sucks". Now, he admitted to no actual experience in building UI frameworks - lots in using them, but not in building them. So he was hired, and told he'd lead the GUI project :) So to backtrack - in the interview with Glenn Krasner, he draws a diagram of MVC, crosses it out and says "this is stupid!" - mind you, Glenn had co-written one of the original MVC papers with Steven Travis Pope - so the rest is history :)

What this is about is a roadmap - in the 45 minutes, we are going to be told how we can move forwards towards this admittedly disruptive technology. Pollock goes into "Production I" in late fall.

Q: Which hemisphere?

A: The only one that matters!
laughter

Pollock will be made available outside the scope of the VW release cycle. What's done?

• Widgets
• XML and L.A. Spec
• Code building frameworks
• Windows 9x/2k/ME, Motif and Mac OS X looks
• Wrapper features: 80% done - when Pollock ships, it will be feature complete compared to existing features
• No tools - framework only
• 13,992 SUnit tests

What's left?

• The little stuff
• feature match
• promises
• bugs
• Medium stuff
• API cleanup
• Internationalization support
• The big stuff
• tab order ~= Z order
• Smart invalidation (flicker free - No flicker in Pollock)
• No direct GraphicsContext writes
• Smart clip all invalidations
• New multi-rectangle damage
• Double Buffering - default on all platforms except Win 98/ME (due to resource constraints there)

Here we went into a long sidebar on the way invalidation and painting will work in Pollock, and how and why it will fix flicker issues.

What's it got that wrapper doesn't?

1. Auto look change (all widgets - no code needed from you)
2. Dynamic scrollbars
3. XML or Literal array specs - or build by code
4. Global drag/drop (not OS level)
5. Trigger Event system (no change/update)
6. Better look emulation
7. E-Z Extensibility
8. Consistent API
9. No Wrappers
10. A Future!

When Pollock gets to be the defaukt UI, the existing framework will be softly deprecated - available, but not pre-loaded. Another thing - code will be pushed out to the public store on a regular basis as we move towards release. Highlights:

• TextEdit - save and load in XML with emphasis
• grid - emphasis by row and column and cell
• Grid - resizable rows
• Frames - relational
• Aspects not required - will work automatically
• Rich API - directly on the widget
• Hotkeys - by look, image, UI, or widget
• Tab Control - optional tabs
• Toolbars - input fields and drop down list

Conversion Tools

• Convert Menus
• Convert Toolbars
• Convert specs
• Convert ApplicationModel code and translate to Pollock UserInterface code
• The rule - 80/20 80/20 rule. 80 percent should convert right off. The last 4 percent is going to have to be hand transferred.

Futures

• TextEdit - Hypertext
• Windows XP Look
• Listbox inline edit
• Grid
• Any widget in a cell
• TreeView column
• Different selected and unselected row views
• Smart fly by help (proper list support, etc)
• BGOK/Charts

After Pollock - Chagall

• Native Widgets
• Plug and play - emulated and native together
• Expanded Native Widgets
• Mac OS X
• Windows 9x/2k/Windows .NET Windows Mobile
• QT (KDE)
• GTK (Gnome)
• Motif/CDE

After Chagall - Peaches

• Graphics engine moved from the engine to the image
• GraphicsContext in image
• New Platform Portable Font System
• Event Loop in Image

Q: What about Doc?
Working on doc, there will be basic framework doc for production I. There is more information on Sam's Blog. This series will be continuing.

Q: 2D drawing API and translucency?
Translucency should be in the VM for 7.3. 2D model same until native widgets

Q: Events same as VSE?
Same - same as VSE and VA (whicg was "stolen" from VSE in the first place

Q: Can widgets be laid out in relation to each other?
Yes, using relational frame

Q: VisualWave? What about that?
Will remain dependent on the old GUI framework. The XML specs in Pollock would allow for XSLT to do some magic - talk to Michael Lucas-Smith

Q: Why the name?
Named after Jackson Pollock (the artist) - inspired by the name of the (never shipped) Van Gogh project. Chagall - native widgets - Peaches - Frank Zappa

That's it - we are over time - 20 minutes to the keynote with George Bosworth.

Len Lutomski talks about load balancing and Opentalk. Starting out with a demo - the demo is running:

• On a single host, multiple images (simplicity of showing it, not a limitation)
• Test Coordinator running distributed SUnits
• A Server Monitor that shows the message backlog

There are a number of load balancing algorithms implemented - one thing to notice at start is that things start out a little slowly as the various images negotiate their roles and set up. For the same reason, shutdown can take a few moments as well. The fist demo - a sequential round robin example. The monitor is showing an even load across all the systems as they run - exactly the way you would expect a round robin to run. Question from Len - which will distribute load better - a random round robin, or a sequential? Something for us to think about as he gets ready to run. The sequential distributed pretty evenly. There are some useful statistics available from the clients and servers - how long (aggregate) requests queued up, etc. Random round robin does worse, as the random assignment sometimes tosses "too much" load at a single server. We are actually seeing that in the monitor.

Next demonstration - "least loaded" scheme. As opposed to the round robin scheme, we need stats from each server about their load - so that we can make a determination. "Least Loaded" tends to drop load on a given server in sequence until the data about server load is updated. So a given server is in the "give me load" state past the point where it's no longer the least loaded system - we are making determinations based on old data. I've seen this personally - I implemented (with Sean Glazier) a simple load balancer for VisualWave years ago - the customer wanted least loaded, and we saw exactly what was just demonstrated. They ended up using our simpler round robin scheme :)

Now Len's showing us some kind of request stream that - using sequential round robin - tends to load down individual servers. Now he's going to use the same stream of data, but a random round robin. This is tending to work out better in terms of overall load - individual servers are not getting bogged. Now on to "Least Loaded" - This works out better than the round robin. (In reality, you should run lots of tests). The difference here is that the time to run the requests varies - instead of each being the same, each varies between short and long. Under that test, least loaded does ok. Now a round robin where the interval to switch servers has been set longer. This does tend to load a given server every so often, but in general distributes the load pretty well. By playing with the time interval to switch servers, you can get better (or worse) performance. There are various schemes for Least Loaded that back off - for instance:

• take in load data
• on request, pick lower half of group (on load)
• assign request randomly in that group

Works better than least loaded by itself, but does add complexity. Not only does it work, but it's fun to play with! Now back to the presentation

Load balancing is for syncronous, connection oriented protocols. For Multi-cast, you do something else. Some routers do load balancing - they are faster, but usually less flexible than software balancers. What about things (like web requests) that need to "pin" a server for session oriented requests? You have the balancer work only on initial requests, not on the rest. Why do we do this at all? We do this in order to minimize the time that clients wait on a request. There is overhead to this.

You really need to look at how long your requests tend to take in order to set up an optimal number of servers to use in a balancer - bearing in mind that the balancing itself has overhead (more network traffic, processing time for the decisions, etc):

• Redirection overhead
• Messaging overhead
• Hindered server and balancer responsiveness

Opentalk balancer - released as of 7.3. Four parcels, a framework built on Opentalk. And it's dcumented! There's an API defined for configuring and creating instances of components. Basic support for multiple balancer architecture, and generic clients and servers. Working on the failover and state replication issues.

Supported architectures - Again, not dealing with multiple balancers. The basic assumption is that all servers will deal with the same kinds of requests, and that all servers are the same kinds of systems. You should not use an architecture with sessions or transactions - i.e., any situation where you expect any maintenance of client specific, server side state between consecutive requests. So:

• balancer always, no loads
• client reference wrapper only holds a balancer reference. Goes to balancer for each request. balancer has a static distribution policy. Servers do not have co-located load monitors (not needed). Simple strategy, expensive in redirection overhead, cheap in messaging. Works well with no sessions or transactions
• balancer rarely, no loads
• balancer always, with loads
• balancer rarely, with loads
• balancer rarely, with loads
• no balancer

And we are out of time! Lots of good info on balancer strategies.

Day two is getting underway - we're all at breakfast downing large volumes of coffee. I'm trying to decide what talk to go to first - either Avi's O/R talk, or an Opentalk discussion. Decisions, decisions...