"The original is unfaithful to the translation." --Jorge Luis Borges
A post with this title could take me one of two ways, and tonight I'm going to follow it down the road paved with silicon. I had a guy tell me this week that the holy grail of software is what he called "freedom from translation" (once again I'm going to leave the literary opportunities in that phrase for other posts, but don't think I didn't want to). The world he envisions is one where you can take functional specs and have that get reliably turned into software. It's the fantasy of CEOs and CIOs the world over.
Regardless of what this says about me, I'm going to come out and admit to you that what gets me most excited about computers is the exact opposite--I love the delicate game of translating things from one layer to another. For example, I love RFCs and have implemented almost all of the mail server RFCs (I stopped with MIME for reasons that will be obvious if you ever read them), and I did it all simply for the joy of it. I know, it's sick. I can't help myself. I find the work of transforming one language, grammar, or protocol into another endlessly fascinating.
I can remember the day I first discovered this love (or became sick, as the case may be). I was a second year CS student, who had to complete an assignment to add a new feature to a toy LISP implementation written in Pascal. I had never really thought about the fact that I could extend the language from underneath--I was used to extending LISP from within LISP, which is the more obvious choice. But as I started to work, I became enamored with the work of understanding how one programming language could sit comfortably on top of another. It's such an obvious thing when you've gotten used to thinking this way--all of software is just translation and reduction--but it was a brand new personal revelation to me at the time.
I'm enjoying watching my students go through the same process as they work on porting Processing from Java to JavaScript. For example, Andor ran headlong into it today as he tried to sort out the proper boundary between code in the library vs. users of the library. A week ago, another student was struggling to understand how to map Java's method overloading onto JavaScript. "What do you mean I have to use the arguments object instead?" When the problem is viewed as being one of mirroring vs. translating, it always results in frustration. One can see the heritage of Java in the design of the Processing API most clearly when you move away from it. Translation gives you that critical distance and perspective.
Translation, if you are to do it properly, requires you to come to terms with the spirit of the original. Expecting 1:1 mappings between two things is necessarily going to end in frustration. What's required is a creativity to see the essence of the original constructed from the pieces of the new. There is almost never a single way to do it because while the interfaces might remain identical, the bodies never can.