Caveat Lector: I shall indulge here in that most futile of all exercises, predicting the future. Allow me to put on the cloak of Merlin (not to mention his infamous pointed hat), look at the crystal ball, and solemnly proclaim, announce and declare
The Imminent Rise of the Metaprogrammer.
You have guessed right: a metaprogrammer is someone who develops metaprogramming code (metacode), i.e. code that creates and/or modifies programs (included, perhaps, itself).
Metaprogramming is by no means a new game: folks in functional programming (remember LISP?) have been writing metacode for many years. However, it is only quite recently that metaprogramming paradigms have percolated down to the world of mainstream programming (I am not counting in compilers, debuggers, etc.). Languages such as Python and Ruby, and to a lesser extent the new Java with annotations, have built-in metaprogramming capabilities.
Now, what kind of metacode can one write? The possibilities are, of course, endless. Nevertheless, for the sake of simplicity, we can classify metaprograms into two main categories, static and dynamic (for reference, check this synthetic presentation by Aussman and Kessler), somewhat mirroring the distinction compile time versus run-time: in the static category a metaprogram creates, edits. inspects some code, whereas in the dynamic model the same happens while the underlying program runs.
Rails is a successful example of static metaprogramming: it generates a template web project out of thin air (incidentally, I note in passing that there is a Java version of Rails, known as Grails. I shall talk on my experience with Grails in a future posting). There is no question in my mind that static metaprogramming will make further strides in the very near future.
However, my interest and hopes lean more toward the second category. I dream of a new generation of enterprise programs that modify themselves at run-time, to accommodate the ever-changing, often erratic business needs. Those programs will use both pillars of reflection, introspection, to see themselves, and introcession, to adapt and evolve.
In spite of the promises, and the fact that languages like Ruby amply provide the plumbing for sophisticated dynamic metaprogramming, so far (at least to my knowledge) we have only whetted our toes.
So, what do we need to get there? My gut feeling is that, aside the obvious step of educating mainstream programmers to the benefits (and potential marvels) of metaprogramming, two more things are necessary:
You have guessed right: a metaprogrammer is someone who develops metaprogramming code (metacode), i.e. code that creates and/or modifies programs (included, perhaps, itself).
Metaprogramming is by no means a new game: folks in functional programming (remember LISP?) have been writing metacode for many years. However, it is only quite recently that metaprogramming paradigms have percolated down to the world of mainstream programming (I am not counting in compilers, debuggers, etc.). Languages such as Python and Ruby, and to a lesser extent the new Java with annotations, have built-in metaprogramming capabilities.
Now, what kind of metacode can one write? The possibilities are, of course, endless. Nevertheless, for the sake of simplicity, we can classify metaprograms into two main categories, static and dynamic (for reference, check this synthetic presentation by Aussman and Kessler), somewhat mirroring the distinction compile time versus run-time: in the static category a metaprogram creates, edits. inspects some code, whereas in the dynamic model the same happens while the underlying program runs.
Rails is a successful example of static metaprogramming: it generates a template web project out of thin air (incidentally, I note in passing that there is a Java version of Rails, known as Grails. I shall talk on my experience with Grails in a future posting). There is no question in my mind that static metaprogramming will make further strides in the very near future.
However, my interest and hopes lean more toward the second category. I dream of a new generation of enterprise programs that modify themselves at run-time, to accommodate the ever-changing, often erratic business needs. Those programs will use both pillars of reflection, introspection, to see themselves, and introcession, to adapt and evolve.
In spite of the promises, and the fact that languages like Ruby amply provide the plumbing for sophisticated dynamic metaprogramming, so far (at least to my knowledge) we have only whetted our toes.
So, what do we need to get there? My gut feeling is that, aside the obvious step of educating mainstream programmers to the benefits (and potential marvels) of metaprogramming, two more things are necessary:
- a single rock-solid example of applied dynamic metaprogramming
- tools and environments to ease the work of prospective metaprogrammers
Some brave visionary soul must rise up to the challenge: any paladin out there to pick up the glove?
PS Conjecture: the two bullets above will pop up together in a single breath-taking sweep
