Thin Air

Everything about community

BASTUG Meeting

I'm stoked that we're back on track with BASTUG, the Boston Area Smalltalk User's Group. It went on a short hiatus while I got married and Rob's wife had a baby, but now that things have settled down, we've decided on the third Tuesday of the month for regular meetings. That makes for short notice of this month's meeting, but here's where it will be:

Date: Tuesday, September 20, 2005
Time: 6:00 pm

The Joshua Tree Bar & Grille
256 Elm St.
Somerville, MA 02144


Posted in community

Tyranny considered beneficial

Ian Bicking has posted a couple thoughtful comments on this versioning thread. This one in particular caught my attention. In conclusion, he writes:

In the end, it doesn't seem like Smalltalk is an evolving language, and
there's no one to even go to to ask for new features (who would realistically
respond in a positive way). So it's hard to compare; in all of these
languages, you can cope somehow. You can always do code generation, after all.
In evolving languages there are options besides coping; that people respond to
that and ask for changes doesn't indicate a more flawed language.

I wonder if much of the disconnect between Smalltalk and the newer breed of dynamic "scripting" languages stems from this difference in social organization. The Benevolent Dictator is a very common pattern in the open source world - think Linus Torvalds, Miguel de Icaza, Larry Wall, Guido van Rossum, Yukihiro Matsumoto, and many more. In the Smalltalk world, we have icons like Alan Kay and Dan Ingalls, but they've moved away from active leadership roles in the community. That makes it hard to see all the things that are going on in the community.

In fact, the Smalltalk world is evolving quite rapidly, despite (or perhaps because of) the lack of a dictator to set direction and coordinate development. In the last few years there have been several notable language changes in the Smalltalk world:

  • The Croquet project introduced new syntax to make their 3D work easier: matrix literals and message sends using positional rather than keyword parameters.
  • The folks at SCG introduced Traits, a new mechanism for composing object behavior that avoids the problems of multiple inheritance and mixins. It will probably be part of Squeak 3.9 (and, incidentally, Perl 6).
  • Cincom added Namespaces to VisualWorks.
  • Cincom removed class variables from VisualWorks.
  • There have been 3 new implementations of Smalltalk: #Smalltalk, which runs on the .NET VM, Ambrai for Mac OS X, and OOVM, for embedded platforms. There may be one or two others that I'm forgetting at the moment.
  • Brian Rice and Lee Salzman created Slate, which is a Smalltalk variant with a number of language-level changes, most notably multiple dispatch.

The thing is, these don't feel like languages changes to people outside the community. For one thing, they only affect one dialect. There's no "offical Smalltalk" that one can refer to for a language definition, and so we end up using either Smalltalk-80 or ANSI Smalltalk when the need arises. Of course, the real meaning of "Smalltalk" is more of a weighted average of all the dialects, a kind of eigenlanguage that you can only absorb though experience.

Ian is absolutely right, there's no one to ask for a change in the language, but neither is there anything to stop you from doing it yourself if you feel the need. And isn't that the spirit of open source?

Posted in community

STS 2004: Getting Away With Smalltalk

Well, Smalltalk Solutions is over, and after several days on the road, I'm finally home. Blogging from the conference turned out to be a non-starter, as I ended up using my spare moments to redo my presentation slides. So I've got a backlog of posts to catch up on. Up-to-the-minute reporting wasn't my intent anyway - James Robertson and Michael Lucas-Smith did a fine job of that. Instead, I want to share what I learned at StS.

Avi's keynote introduced what turned out to be a key theme of the conference: there are certain areas of the software industry where you can get away with using non-mainstream languages, and these are opportunities to use the productivity we gain from Smalltalk to competitive advantage. Avi's focus is web applications, and his talk walked through their evolution from CGI to the use of sessions, components and ultimately, continuations. With each step, the application design becomes more sophisticated, with more powerful object-oriented abstractions. In the end, we have Seaside - Avi's Smalltalk framework for web apps.

At one point, Avi quoted Cees de Groot:

Seaside is to most other Smalltalk web toolkits as Smalltalk is to most
other OO languages; it's as simple as that.

That quote captures the gut-feeling reaction I have to Seaside. It's good in the same way that Smalltalk is good. It's the way things should be, but rarely are.

And Seaside is an especially attractive application of that Smalltalk goodness, because it's one of those where you can get away with using it. Nobody cares what's running on your server, and most of the time they can't even tell. What they do care about is the usability and functionality of your application, and your ability to tune it in response to their needs. And that's were Smalltalk is a competitive advantage.

That theme was picked up by Lars Bak in his keynote on Resilient, and in fact just about all of the talks about Smalltalk for embedded and mobile systems. The Resilient VM fits into 32K of memory, and can run an application in 128K. It can be remotely debugged or dynamically updated without interrupting the functioning of the system. Try doing that in Java or C, which are the mainstream languages for these tiny systems.

Web applications and embedded systems are quite different beasts, but they do have two things in common: First, they both execute in a controlled environment, communicating with the world through standard protocols. Second, the business environment in which they are deployed is extremely competitive. The business value they provide and the ability to adapt to changing business conditions is more important than conforming to industry norms. I wonder where else we might find these conditions...

Posted in community

STS 2004: Cryptography and Smalltalk

Martin Kobetic made a really excellent presentation on VisualWorks Cryptography API. He walked through the major elements of cryptography - stream cyphers, block cyphers, message authentication codes, hashes, digital signatures etc. In each case he demonstrated the VW implementation.

The surprising thing that became apparent as Martin spoke is just how simple this stuff actually is. The VW API is extremely simple; generally you can do straightforward tasks with a couple message sends. Even the implementation seems pretty straightforward - the hard part isn't making it work, but making sure there are no hidden vulnerabilities..

One aspect of the presentation was very, very cool. The slides were presented using a custom VW app which had a very effective method of demonstrating the various cyphers. By selecting an area of the display, Martin could apply a cypher to that part of the display bitmap. This was really handy for visualizing encryption - after applying the cypher, blocks of the screen would appear to be white noise. He also did a great demonstration of the catastrophic effect of reusing a key with a block cypher - when two areas of the screen were encrypted with the same key and overlaid, the original images were plainly visible, no decryption necessary.

Congrats to Martin for a very clear presentation of a difficult topic.

Posted in community