Feed Sign in with OpenID OpenID

Simon Willison’s Weblog

Code generation vs data driven programming

Via Ned Batchelder, this interview with pragmatic Dave Thomas on code generation closely reflects my own nascent thoughts on the issue:

CGN: What do think the future is for code generation?

Dave: I think that in the long term the larger code generation efforts, the “application generators,” will become a thing of the past. They are there because the underlying technologies and architectures don’t yet support programming at a high level. But I’m betting that languages such as Java and C++ will in the long term be seen as a curious branch in the evolution of computing. I’m hoping that somewhere out there some bright spark is coming up with a way of letting us write applications expressively and dynamically. Once this happens, the need for these kinds of code generators will diminish.

For example, I rarely (if ever) write a code generator that generates Ruby code: there’s just no need, as Ruby is dynamic enough to let be do what I want without leaving the language.

In the shorter term, though, I think code generators of all kinds will continue to contribute significantly to the industry. Java and C# are both such stifling languages that you need to be able to use code generators to make them effective.

We considered using code generators for our current major project at work, and picked up Jack Herrington’s book on the subject. Reading through it, it became clear that many of the problems that code generators solve can be tackled instead using data driven programming techniques made possible by dynamic languages. Since we had already settled on Python as our implementation language the need for code generation became far less apparent, and we ended up avoiding it entirely with the exception of a command line tool for passvely generating basic templates for our admin interface.

If I ever have to work with a less expressive language I’ll certainly consider using a code generator (probably written in Python) to abstract away some some of the tedious repetition. As it is, Python’s rich data structures and clean support for introspection provide an excellent alternative.

Posted 11th February 2004 at 5:39 am

This is Code generation vs data driven programming by Simon Willison, posted on 11th February 2004.

View blog reactions

Next: RSS vs Atom, condensed

Previous: width = str(len(str(len(lines))))

7 comments

  1. I certainly agree, and always go out of my way to avoid code generation. Besides using a dynamic/expressive language, you can avoid code generation by avoiding boilerplate. Eventually the boilerplate will annoy a programmer enough to make a template, and from there it's only a small step to more substantial code generation.

    The other side of the issue is "what is code". Where does HTML generation fall in this? Or Javascript generation? Who among us hasn't generated Javascript? Is fully dynamic generation okay, as opposed to static generation? Is it only okay when you never edit the code? HTML form templates? What about code templates? Project templates? Copyright headers? Well, now I'm just getting pedantic...

    Ian Bicking - 11th February 2004 19:19 - #

  2. You can't really make general statements about things like 'code generation.' Sure, Python is expressive enough that you don't need one for generating strongly typed collections and data access code (referring to my other language of choice, c#), but then there's projects like CheetahTemplate that are incredibly useful.

    rick - 12th February 2004 05:59 - #

  3. Cheetah is more of a template engine than a code generator. You could certainly argue that HTML generation is a form of code generation, but in my entry I was referring to code generation as "automatic generation of source-code" - i.e generating Python. I'm a huge fan of templating systems for generating markup languages such as HTML - heck, I've spent the last few months working on one with Adrian Holovaty as part of the new CMS we've been developing at work.

    Simon Willison - 12th February 2004 07:04 - #

  4. When Jon Udell quoted from the same interview with Dave Thomas, he penned a perfect description of Lisp, the mother of dynamic languages.

    We've always known that dynamic languages are a great way to create "little languages" for specific tasks. But we don't yet fully appreciate that all programming is a continuous process of language invention. And we don't (yet) evaluate programming-language productivity on those terms. .... We are linguistic animals endowed with a protean ability to generate language. Naturally we'll want that same generative power in our programming languages.

    Paul Graham calls it bottom-up programming in On Lisp. Lisp macros are code generators that are baked into the language. Lisp's secret power is the ease with which it can be extended into custom "little languages" which match the domain of the program under development. But code generation is only a part of that power. Functions and lexical closures and data-driven, functional programming are also very powerful tools.

    My dynamic language of choice these days is perl though I'm also a fan of python. I suspect that perl and python and ruby are all interesting precisely to the extent that they have copied lisp power tools.

    It's not really a question of whether to use code generation, but when. Paul Graham's answer to that question is "only when nothing else will do." But as he demonstrates clearly throughout On Lisp, there are problems for which lisp macros are the only solution and they create very powerful tools.

    Parahprased from my response Lisp blazed the trail, (code generation and dynamic languages)

    Eric Dobbs - 12th February 2004 16:37 - #

  5. I think when your designing/developing on a large enterprise level, generated code makes sense. When you're writing user interfaces and services that integrate the database, then data-driven make sense. When you're writing on the fly, I'm not so sure it's helpful until you've figured out exactly what it is you're trying to do.

    Mean Dean - 12th February 2004 18:37 - #

  6. Think of code generation as compiling. Its just a way to make machine understand you and way to speed up things. Currently we generate lot's of C++ code from Python. There are few carefuly tested building blocks, but otherwise that's just solving a business problem in Python. (Or whatever language, becouse what matters is correctly generated C++) P.S. Somehow this blog engine does not support utf-8 properly. My name is not Ģirts Kalni�š.

    Girts Kalnins - 8th December 2004 21:55 - #

  7. Its interesting that you don't mention Lisp having written about Lisp in your blog before (albeit, modulo a few details). Lisp hackers use code generation all the time, but Lisp does that for us :) We call them macros and they are good things :)

    jimX0r - 3rd March 2006 11:07 - #

Comments are closed.

Previously hosted at http://simon.incutio.com/archive/2004/02/11/codeGeneration

A django site