Meta Programming with a Barf Bag

Day one of the Open Source Bridge conference was action packed. I'll probably have to write a few posts, but I'm going to start things out with notes on my favorite talk of the day "Spindle, Mutilate and Metaprogram: How far can you push it before there be dragons?" by Markus Roberts and Matt Youell. Yes the picture is them wearing colanders on their heads.

This talk was 2 hours long so it is hard to cover it in all its glory. The crux is that programmers are generally very inhibited by the orthodoxy of each particular language community to the detriment of the code they are writing. Done properly, applying the magic of meta programming simplifies problems and makes code more understandable. Markus especially seemed to wipe his boots on some of the taboos. They mentioned ActiveRecord and jQuery as examples of effective meta magic.

The talk began with a gameshow where 3 volunteers were shown code snippets and the first person who could identify what language it was got a point. The first program looked like C but was in fact Ruby. Another looked like assembly language but was Perl, they even threw some Cobol in there, but it turns out it really was Cobol. :) Each time after they revealed what the real programming language was they showed the code that allowed them to mimic the other languages. It was really a cool way to start a presentation about meta programming.

At one point they showed some C that had been made to look like another language (I don't remember which). Somebody from the audience pointed out a memory leak. Markus responded by pointing out a table in the back where they had barf bags laid out and recommended he get one because there was going to be some spectacularly intolerable displays of metaprogramming. There was lots to learn about how you can shape your own destiny in a programming language if you are willing to amp up your level of meta skulduggery. Tomorrow when I see Markus and Matt again I'll ask about their slide deck, because it would be fun to share some of their code examples.

To ORM or Not to ORM.

Sara Taraporella recently added this very interesting post to her blog. In this post she argues for a separation between domain models and ORM models. There is a pretty lively discussion in the comments that I found useful.

For me it is situational and so for the most part I think being somewhere between these extremes is nice. Something that keeps me from having to do lots and lots of transformations but also keeps me from having to touch too many files when something changes. Active Record is the poster child for combining ORM with the domain, and in the situation where you have complete control to define and change your DB it is great, though I think it comes at the cost of testability. In the comments Clinton Begin describes a situation where other applications need to consume the same DB and require changes. In this case or in the case of a legacy DB you might find yourself gravitating towards the opposite end of the spectrum, which is what Sara is advocating. Complete separation of these concerns.

I recently attended a talk by Drew Olson at the Chicago ruby user group about Data Mapper (among other things). Data Mapper is definitely a step away from the the purity of active record. With active record your DB schema describes your domain model and so you stay DRY. Data mapper says you need an explicit mapping. This buys you flexibility at the cost of being explicit and potentially redundant in describing the relationship between the domain and the database.

I see Active Record as one extreme and Sara's perspective as the opposite. Datamapper is a step towards the middle, and with the changes in Rails 3 the door will be open for people to use data mapper instead of active record. So it appears that Rails is mellowing in its old age, going for a less extreme worldview. Or maybe the world has moved towards rails' view of the world. In the end a little of both are a good thing, I think.