Chris Baus

Meta programming vs programming

In retrospect, I set my expectations too high for IronPython. I wanted the best of all worlds: seamless integration of .NET and CPython. IronPython doesn't offer that, but there are enough valid use cases for IronPython to deem it a 1.0 release.

For instance if you have a large .NET codebase, and you want to provide a scripting solution, drop IronPython.dll into your project, and bam you have a full featured, modern scripting language with almost no work. That's pretty damn cool.

My consternation with IronPython came from the fact that I spent my weekend free time doing a lot of Metaprogramming, rather than programming. When I say metaprogramming I don't mean writing code that generates code per se. I mean working on frameworks and platforms rather than writing an actual application.

It is easy for developers to get caught up in metaprogramming. It offers the lure and guise of productivity. For instance, "If I can get WSGI working in IronPython then I can leverage a ton Python middleware and .NET frameworks and I'll be so much more productive that I can go wine tasting instead of writing the authentication layer." But after 8 hours of reading PEPs, debugging regexs, patching socket code, and following stack traces, not only have you not tasted any decent Bourgogne, you are no where near having a working authentication layer.

Metaprogramming has its place, but you have be honest with yourself. Note to self: unless your users are other developers, at some point you have to stop metaprogramming and start programming.