Niall Ross' long awaited StS 2005 summary is here. It's a PDF, and - as always - worth your time to read. Hat tip Jason Jones.

Adriaan posted a bunch of pictures from StS - start here. Look at the first day pics to get an idea of what the weather was like most of the time.

Jason Jones announces the results of the coding contest:

The Smalltalk Industry Council is pleased to announce the results of the second portion of the first annual Smalltalk Solutions Coding Contest. The winners for the Second portion of the contest are:

• 1st Place: Kevin Badinger
• 2nd Place: Michael Lucas-Smith
• 3rd Place: Blaine Buxton

For those of you who missed the action:

• A minute by minute account of the contest can be found here
• Michael's blog on the contest is here
• Blaine has some thoughts on the contest as well

Congratulations to everyone and thanks for helping make this year's show one of the best ever.

Congratulations to all the entrants!

Smalltalk Solutions is over for the year, but there's still more - Suzanne Fortman sent me some pics she took (these are mostly from day one). I'm sure that I'll receive a (large) report from Niall Ross soon, and I'll post that for download. We'll also have details on StS 2006 to post at some point - we selected Montreal as the site, but we have details (timing, hotel) to come. Anyway - here are some pictures - here's Suzanne and Giorgio Ferraris:

Next, here's a shot of Eric Evans during his keynote:

Here's a shot of one of the talks on day one. I'm half cut off all the way to the right:

Finally, here's a shot of part of the vendor area, where we also had meals served:

These are higher quality than the ones I took, because Suzanne has a real digital camera :)

It's been a really, really great three days - lots of catching up with friends and customers, lots of great conversation at the bar each evening. Watching the coding contest this afternoon was a blast - the guys had a lot of fun, and I expect we'll see more of that next year. Which reminds me - we decided on Montreal as the venue for next year, but we don't have dates or the hotel nailed down yet (we are pretty sure about the hotel, but I don't want to gte ahead of myself). To those of you who weren't here - come next year, you missed a great time! For everyone who was here - hope to see you again real soon!

Last talk of the day, and of the conference - Bruce Badger is going to tell us how Smalltalkers can benefit from what he's doing with the OpenSkills organization - and how they use Smalltalk at OpenSkills. Here's Bruce:

What is OpenSkills? An open forum for networking and work support services. They provide a free, searchable skills base. They are a non-profit, so as an organization they have no money. So - all development is a volunteer effort, and Bruce, knowing Smalltalk and Java, would rather use Smalltalk (takes far less time. Observation: For consulting firms, Java is a great choice - takes 3x as long, so that's 3x the consulting dollars :)

They use WikiWorks for their Wiki. It works quite well, it's reliable, and it's fast. The SkillsBase is the pivotal application for them - Smalltalk is great for that because:

• They have an evolving data model
• They need to be scalable
• They need distributed development
• It makes good use of a scarce commodity - volunteer developer time

All of their web apps go through Squid as a reverse proxy, which gives them simple, secure connections. Their back end database is Gemstone. They've written the SkillsBase application so that it runs either in VisualWorks or in Gemstone - they actually run Swazoo out of Gemstone.

The membership system is a combination of:

• A complex and underdefined process
• lots of external interfaces
• little time
• Those are ideal for Smalltalk use, as it allows for easy evolution of the system as time and details allow

They are getting a lot of help from the open source community, both in Smalltalk and in Ruby. What do they see happening? They are seeing a lot of interest in Swazoo, Glorp, and Seaside. They are seeing a lot of interest in Squeak and Gnu Smalltalk. This is leading to an increased use of Smalltalk in the open source community.

What would Bruce like to see?

• More ANSI work (streams, files, FFI)
• More standardized ANSI interfaces for common libs (sockets, Dates/Times, etc)
• Deployment simplicity- a beginner should be able to deploy "Hello World" (as a deployed app, rather than as a dev env). Yes, that's top of my list

Jeff Hallman, who works at the Fed in DC - his application tracks the money supply and is responsible for the reports on that - the ones that come out every week. Here's Jeff:

So - definitions:

Reserves are the deposits at a Federal Reserve Bank. The supply is based on Fed actions Demand is created by reserves requirements on transactions deposits. So what do they publish?

• H.6 - Money market measure (M1, M2, M3)
• H.3 - Aggregate reserves of depository institutions and the monetary base - this used to be tracked heavily by the markets (in the 80's)
• Available at http://www.federalreserve.gov

MARS (Money and Reserves System) is their application. Loads serveral dozen reports and adjusts for reporting errors. Recalculates (C functions), and does forecasts. This is basically a huge matrix with thousands of columns. It creates summary reports, stores data back into the money files, and does session management over the whole thing (for analysts).

The components that get used?

• R (Graphing package)
• Smallpack

How did this end up in Smalltalk? It used to be PowerModel and C, where PowerModel had become legacy (company had gone under). Jeff convinced his management to go to Smalltalk after a bit over a year of lobbying (I made a few visits myself). It's running on Red Hat at the Fed, he's demonstrating it on his laptop.

Like a lot of critical Smalltalk applications, this one is delivered to the analysts with the full development environment (hidden) - something that one of my frequent commenters seems stunned by, since he constantly blathers on about the power of dead tools where you can't do that sort of thing. Fine - we're busy being productive over here :). Changes in the old system took weeks - he typically makes requested changes in an hour or two - because of what I said above.

So anyway - the analysts can look at the data in a grid, or in charts (seasonally adjusted or otherwise). I've got a chart screen shot here with some large swings (this is monthly data) - Jeff points out that the swings are due to something called "Sweep" accounts, where banks push money around as a reaction to the vagaries of current law:

The reports that this application produces get used by the fed board members to look at trends and help make policy - so it doesn't get much more mission critical than that :).

Interesting note - the earlier system took about 3 years to write, by 2-3 people - about 83k lines of code (C, PowerModel). The Smalltalk system is 21k lines of code. In terms of actual characters, the comparison is 3.2 MB characters, as opposed to 605k characters in Smalltalk. It took Jeff (one guy) six months of work. So... the productivity comparison is 5-6x better in Smalltalk, with fewer people working on it.

Niall Ross on the value of Smalltalk:

"The things you lean from experience are better than what you learn from theory" - they sink in better. Learned Smalltalk on the job, liked it straight off. Later on, at Nortel, found that management was very keen on Java, but Niall found that he couldn't get enthusiastic about it. He's been pondering the why of that since then.

So - why does Smalltalk give value? Consider Statically typed (Niall calls them "stiffly typed") languages: they represent the ultimate attempt at up front optimization. This violates the basic tenet: First make it run, then make it right, then make it fast. Looked at another way, you'll almost certainly get it wrong the first time.

• C#, Java - designed by and for those who expect to be right the first time
• Smalltalk - designed for those who don't

The first example - the Kapital project at JP Morgan. The goal - the ease of a spreadsheet with the scalability of a system. I'm not taking full notes on this example - Niall went into detail on this at last year's ESUG conference.

The basic message Niall gleaned from working on the Kapital system: Meta-modeling is so easy in Smalltalk - that you can actually deliver. Why is meta-modeling so easy? Smalltalk exposes the meta-model - everything is an object, there are very few reserved words. In other words - the language lawyers don't get you down :)

Niall's next example is an insurance system - I'll point you here, to the December 2004 User's Conference, where Niall spoke about this. A nice point:

Ralph Johnson's framework rules:

• build one when you need to
• when you've done something three times

Smalltalk is good for this because everything is an object - nothing resists becoming a framework object. Every type is an object; mix and match generic algorithms with specific overrides. Smalltalk frameworks can be built in an agile way, deferring decisions. C# and Java aren't so suitable - meta data patterns are brittle even in simple cases.

Heh - a question about Lisp and meta-modeling. Niall said that he could easily imagine himself as having come to Lisp instead, or favoring Smalltalk even knowing Lisp better - but such a statement would be respectful, as opposed to the his feelings towards Java.

Lots of good conversation afterwards, which I just didn't capture.