Liquid Development

The Way of Meta

V. 0.0.1

Exploring Metaprogramming in Ruby

I have been a fan of metaprogramming techniques for a long time, but I have been able to fully indulge into this deplorable habit only after having taken up programming in Ruby.

What's the deal with this metaprogramming thing?  There are lots of tutorials and introduction out there on the web, so I am not going to go into the historical details here, but I will give you my own personal definition of metaprogramming. 

Metaprogramming as Deep Magick

Metaprogramming has meant different things at different times, but at any particular time what metaprogramming seems to mean, is the ability of somehow getting into the inner working of the language that you are using, so that you can produce what is sometimes referred to as "deep magick".  It does look and feel like magick, because when you go 'meta' with programming, you are moving outside the realm of everyday modelling, to step into the world that defines the very rules of ordinary programming.

Many of the concepts of object orientation feel like metaprogramming the first time you see them.  I clearly remember the sharp feeling of power and magick the first time I saw C++ operator overloading in action as a young man.  It felt like I could plunge into the core of the language, inside the very definition of the metaphysics of programming and change the way I could represent the world, on a whole new level.

Metaprogramming considered Harmful

The term metaprogramming covers lots of ground, and it represents more a philosophical focus than a specific set of techniques.  The capabilities of Metaprogramming can be potentially so powerful and far reaching that can also be completely devastating.

If you are able to tweak the underlying layer on top of which you build your representations, you can change the semantics of all the relationships that you have built between your 'ordinary' conceptual objects.  This can add new features (aspects) to your program, or it can simply make it wrong, breaking its intent, or it can make it totally unworkable and inconsistent.  It could also cause unforeseen interferences between your meta-code and the program, between two different sets of code, or within the libraries your code relies on.

Metaprogramming on the Leash

So, is Metaprogramming a good or a bad thing?  I would say that it is good if used parsimoniously, when no other conventional technique can yield the same elegance and results.  It should also be used when it can help removing duplication in your code, while adding clarity to it.

However it should be used in a very controlled way.  Metaprogramming almost always involve some degree of run-time creation and customisation of code that gets injected into the realtime machinery of your program.  The code generated by your 'meta-code' is usually invisible to the debugger and you will not have any chance to inspect it and debug it from the inside.  I leave it to you to decide how dangerous and error prone this can be.

All your metaprogramming code, once verified that it is working, should be abstracted away into a set of more rigid mechanisms, with a precise name and meaning that can be put under test and documented.  All these mechanisms should also support ways to output the code they generate and to probe the realtime looking for potential lexical conflicts.

A simple example of 'controlled metaprogramming' is the attr_accessor mechanism in Ruby.  When inside a class you declare a symbol as being an attr_accessor with

you are using a metaprogramming technique that generates a @my_symbol attribute, and both a getter and setter method for that attribute.

Metaprogramming Protocols

Playing with the laws of reality can become a very messy thing very quickly; even more so when you are not the only one doing it.

What happens if you override the method_missing mechanism of the Object class to implement your flavour of metaprogramming, only to discover that a library you were using was leveraging on the very same technique and you just interfered with it?

You will soon start applying your meta-code as a sequence of patches that assume the presence or the absence of other libraries and become rigidly dependent on which libraries are present and ion their loading order.

When you start playing with metaprogramming you will soon come to realise that you don't even need third party code to mess things up.  You will probably perfectly manage to bring havoc on yourself within a few visits to the metaphysics underlying the Kernel and Object classes.

A Metaprogramming protocol could be the only way to get things in order at this point.  A metaprogramming protocol offers an orderly way to access to some of the more dangerous and interference-prone mechanisms of the meta-layer.  Rather than acting directly on the meta-mechanisms, you ask a meta-framework to do it for you, while specifying exactly what you need.  The meta-framework will take care of registering your request and to handle the interference between similar requests coming from different libraries.  The meta-framework will usually act as a kind of multi-dispatching system with a call-back mechanism on its callers.