Cincom Smalltalk Stuff

After a drought, I seem to have stumbled into a high-blogging period.

One of the things people use as a reason not to use Smalltalk is that they "can't find developers". I find it odd that we can simultaneously have developers who can't find Smalltalk jobs and Smalltalk jobs that can't find developers, but even leaving this aside, I've never seen this as a huge issue. My point of view is that the hard skill is programming, and if someone is actually a good programmer they can pick up Smalltalk fairly easily. People talk about these very long learning curves, but my experience from projects I've been on is that good people can pick things up much faster than you'd expect.

Bob Lewis of InfoWorld agrees with me here. The relevant quote is right at the end...

Which is the same thing I tell hiring managers who insist on experience with a specific programming language: A competent programmer can learn a new language quickly. An incompetent programmer who knows a language will remain incompetent forever.

A few times lately I've seen Alan Kay's maxim that "Simple things should be simple. Complex things should be possible" quoted. I'm actually not sure I agree with that, or at least I don't think it goes far enough.

Now, I should say that it's a start, and it's a real shame that so few products can live up to it. For example, Gosling apparently admitted this about J2EE recently . The problem is that if you follow this maxim with what I'll call the "wrong attitude" you can end up with "Microsoft usability". What I mean by that is that the underlying product is hideously complicated, but you have pretty bits to handle the really simple cases. So simple things, at least a few of them, are simple because you have wizards to generate them for you. Anything beyond that counts as complex. It's possible, but it sure won't be easy.

Part of the problem is the discontinuity between the simple and the complex. One of the nice things in Smalltalk is that the barriers in "dropping down a level" are relatively small. Simple things are simple, but simple things are also incremental steps towards complex things. Another way of putting this is that magic should be avoided. If the underlying system can do something, the user ought to be able to do it, as easily as possible.

I certainly wouldn't claim that VisualWorks, or Smalltalk in general is somehow the ultimate in this regard. We have lots of excessively complicated or just bad. One thing that helps Smalltalk though is the aesthetic of simplicity. It's by no means universal, but code being complicated is considered a valid criticism and there's just that much more pressure to simplify.

And in the end we get that much closer to the ultimate goal, which is after all the point of software. "Simple things should be simple. Complex things should also be simple"

Some people were working on updating the Glorp Smalltalk/X port last weekend, and had a request for the ability to file out real old-style chunk format from VisualWorks. I've had people request that before. Fortunately, that ability does exist, you just need to load the FileOut30 parcel, which clearly isn't well enough advertised. In addition, that parcel adds the ability to read and write "ENVY" chunk format for both VW/ENVY and VisualAge, and to read and write Dolphin fileouts. In both those cases it should do a reasonable job of maintaining application/package structure and method categories, although when loading methods with more than one category it will arbitrarily pick the first one.

A good part of that was actually written for, or at least because of, Glorp. At Camp Smalltalk in Essen it seemed like we every person was working in a different dialect and we spent far too much time translating code back and forth. So I extended the FileOut30 goodie to be able to handle these other formats, and got it pushed into the release. This is also the basis for producing Glorp ports. The GlorpUtilities package has a very simple UI that knows enough to file out the Glorp code for various different dialects into different directories. It's crude, but it works. (For VA there's an additional script that you can use to file in, version with matching version numbers and export to a .DAT).

My talk for Smalltalk Solutions was a tutorial called Using Glorp. In contrast to some of the previous talks I've done, this one concentrates more on how to use Glorp and less on how it works internally or the rationale for design decisions. It was tricky, as you might expect from something with hands-on exercises that requires everyone to have a database. I was hoping we might be able to use wireless access and give people access to postgresql running on my laptop, but that didn't seem to work out.

In the end, enough people were able to get going using Access on the Windows machines. That had a few entertaining aspects. I had to hand-wave a bit - "Let us assume that a real database would not cause an error if you did a read before starting the transaction, and just do it afterwards".

I also had to go fairly quickly through some of the later material. I wasn't sure how fast things would move, so I had some extras, and also people asked a lot of fairly advanced questions in some of the early sections. So the ordering was interesting, but I was pretty happy with the amount we got covered.

The slides are available here and the exercises are here . I note that the code in the exercises is VW-specific, it includes a (very minimal) GUI. The slides and such are PDF.

I'm finally back home after Smalltalk Solutions and a vacation detour through Los Angeles. Unfortunately, we also managed to pick up a nasty virus in California, and I've been completely useless for the last 3 days.

Many people have talked about various conference sessions and their impressions of them. I'd just like to say that from my point of view it was a great success and I'm extremely happy. I'd like to thank everyone who participated, and hope to see you all again next year.