I just came back earlier this week from the Smalltalks 2008 conference in Buenos Aires, Argentina. This is just the second year of the conference, and I was very impressed, despite not really understanding very much. Not speaking Spanish is a bit of a handicap when that's the predominant language for the talks. Up here in Canada we don't get Spanish in school - we get French. That's helpful - between French and English, you can guess quite a few Spanish words. But it's not like knowing the language. But what was surprising to me was how much it's possible to get out of a talk where you don't understand either the slides or the talking. Hmmm - now he's making a joke about Microsoft and Web Services... now he's saying this is implemented in Dolphin and too bad that Dolphin's dying...

And there were some very interesting talks. The prize winner was a very impressive Commodore 64 emulator by Gabriel Honoré. It's technically interesting because it reifies many, many aspects of the underlying hardware (at one point it wasn't working, and it was because he'd forgotten to virtually plug it in - it needed a "powerSupply turnOn"). And it was just really cool to watch the graphics and hear the bleeps and bloops just like a real Commodore 64. I'm told by former C64 owners that when you do a "hardware" reset the screen flickers just the right way you'd expect. And the performance was adequate to run at full speed on a reasonable modern laptop.

But there were a lot of other interesting talks too. I won't go through them all, but some of the ones I particularly enjoyed included some work on medical expert systems, another experiment in reworking the collection hierarchy to use traits, the SqueakDBX database driver project, an "IDE" written in Dolphin to ease the pain of a huge .NET and Web Services project, SqueakNOS (Squeak running directly on the hardware), and a tutorial on soccer playing robots. This last one deserves a bit more explanation. Apparently this is a fairly organized activity, with actual robot soccer leagues (e.g. http://www.fira.net ) Unfortunately, they didn't have real robots here, just simulators. But it was still pretty interesting to watch.

Unfortunately, this was a real lightning trip for me. I arrived Wednesday morning after an overnight flight, with the conference running Tuesday-Saturday, and then I flew back Sunday night. This didn't leave a lot of time to explore Buenos Aires, but I did get some opportunity to walk around the city and some time talking to people at the conference We had a social evening at a restaurant, served the traditional Argentinian dish of Asado - the short summary of that is lots and lots of barbequed meat. The following evening I had dinner (Asado) with the group doing the SqueakDBX project, talking about how to make Glorp use that driver cleanly without interfering with the other, incompatible drivers in Squeak. And on Sunday, the organizers took a few of us out to Tigre, by a river delta north of the city, and we rowed out to an island for a barbeque (guess what). So lots and lots of Asado, although a bit different each time. Overall, it was a great trip, and many thanks to everyone involved. I had a wonderful time throughout, and will definitely try to get back to Argentina again, and make a proper stay of it.

This is a comment on the "Inconceivable" entry in Jim Robertson's blog, which I tried to post on the weekend, but apparently it was too late, so I'm just posting it here. See also the comment by Glenn Vandenburg and the original post Jim refers to.

OK, I think I see more of what you're getting at, and where you see the Smalltalk community doing things differently, although it's always dangerous to generalize about diverse communities.

I think the biggest difference is in the expectations people would have of the source code they're seeing. Smalltalk programmers would generally expect to be able to see the list of instance variables and the methods that access them. If they can't see them, but they exist, they'd find that confusing, and they wouldn't think of the presence of the instance variable and accessor methods to be cluttering up the source code. From your comments, it sounds like Ruby programmers would. Perhaps that's also related to tools, because Smalltalk has tools that help organize the source code. There's also perhaps an encapsulation point that people don't automatically put accessors for all variables.

So in Smalltalk, people wouldn't tend to think of having a method somewhere that declares the existence of a number of instance variable that are related in some way and also two accessors for each. They'd expect to see those things, and would probably prefer to do something like annotate the class definition, or the accessor methods, to distinguish those things that are to-many relationships.

In fact, when you talked about generating code, I assumed you were talking about more complicated methods for managing persistence, and being aware of the fact that the variable is a collection, not just accessor methods. The more complicated methods are the sort of thing that Smalltalk people would think of as cluttering up code, and would be likely to do by reflective mechanisms of one sort or another.

And, as Avi points out, if we did generate code, we probably wouldn't do it in such a way as to throw away the intention of the original annotation. But again, that's a bit confusing. If all we're talking about is accessors and a variable declaration, then there are no additional semantics to be taken into account in the generated code. All we've said is that there's an instance variable, we just haven't said it in the normal spot. The fact that it's a collection is irrelevant to the accessor methods or the declaration. You do say that you have the accessors doing a bunch of additional very nice stuff, so maybe they do take that into account, but then we start to get into details.

As far as how hasMany works in the Glorp Active Record stuff that I did, it's just an annotation, so the reflective code takes it into account. So, if you put in that annotation, it's expected that you have a variable by that name (the accessors are optional). It doesn't generate it for you. Reading, writing, and querying against the object works via API's that know about that annotation and take it into account, but which don't generate any code (unless you count SQL). One reason I wouldn't want to rely on extra code in getters and setters is just it's more complicated to make them work if people get the collection and modify it directly. Glorp works by just remembering what the object's state was previously and seeing what's changed, regardless of the mechanism. Of course, other people have done things differently in different frameworks.

For the meta-tricks in general, I'd agree that many of the tricks are very similar. The kinds of things that Ruby and Rails do with reflection are exactly the sorts of things Smalltalkers do with them, and the idioms are very recognizeable.