« About Homes and Design – an interview with Marianne Graves | Main | The Demo Ghost spares nobody – V8 miraculous surviver »
Railing sketches – metaprogramming Ruby for fun and profit
By vahagn | September 30, 2008
These are some thoughts about the Railing track that I attended Monday at JAOO 2008.
I’ve been playing around with Ruby on Rails for some 5 months now, and have gotten steadily more eager to find out what exactly this Rails magic is that developers rave about and big companies often mention when introducing their Rails-killer to the world.
Now having worked with ORM I know what ActiveRecord does. The more interesting question is: how?
Expressed by the words of Neil Ford in his talk (”Meta-programming Ruby for fun and profit“), “More powerful languages are able to mimic the functionality of less powerful ones“. Ruby is an interpreted language with meta-programming capabilities. Meta-programming does two closely related things: 1) gives a program the ability to treat itself or other programs as strings; 2) gives a program the ability to generate code.
(This is none other thing than the “program as data” concept in Computer Science; programs receiving other programs as input and generating other programs as output. At least intuitively, this does sound like a very powerful feature; but what is the practical value?)
One example given was the ability of Ruby to mimic the Java interface construct. Interfaces serve as separation of contract from implementation, helping one to enforce a contract (at compile-time) for various different implementations.
Creating an interface module in Ruby to achieve the same effect would look like this, in pseudocode:
module Interface
if method X is not implemented in a class:
throw a Runtime error
Then, one would import the above module before the class declaration, and the contract would be enforced.
(“But wait!” – I asked Neil after his talk. “Doesn’t the value of the contract lie in the fact that it functions before runtime – already at compile-time, you get an error?” “True”, was his response. “Here’s where we pay back for the freedom we get with the dynamic languages; if you create a module Interface, you will also automatically get a number of tests that you will have to run. That way, you are more guarded against runtime errors in your code”).
Another example was logger functionality: suppose you have code that you closely monitor by logging it. The code is interspersed with logging messages here and there; they grow to clog up and dominate the code.
In Ruby, you define a class with a filter (a regular expression) in it; suppose you wish to log all methods that start with “persist*”. You pass “persist*” as input to the filter and specify how you want to log the output. Problem solved.
I am still to be convinced that dynamic typing can totally compensate for features of static languages (such as interfaces in Java). It seems to be a question of personality and habit; if you are a programmer with enough discipline to run unit tests on all your models modules, and classes, then the Ruby way might be your way. On the other hand, if you would like your programming language take over some of that responsibility, you could stick with Java.
One thing I am not in doubt about is the answer to the question: “When is one programming language more powerful than another?” Before Neil’s presentation I might have sought the answer in the way a programming language treats objects or integers; or how many paradigms (functional, declarative, concurrent, etc) it supports; etc.
After today, my answer is going to be: “That language that is able to treat itself as data, dynamically”.
It’s “Programs as Data for Fun & Profit”, and it’s Ruby.
October 12th, 2008 at 6:23 am
Give Lisp a look. By your definition, it is the most powerful language. To Lisp there is no difference between code and data, they are both the same . Evidence of this is it’s “weird” syntax. While Ruby is very dynamic it will never match, due to its nature, the power of Lisp.
PS: I am a Ruby fan and earn my bread with it.