code is data

[Ian Bicking]

Ravi Teja wrote:
> Fredrik Lundh wrote:
> > Ravi Teja wrote:
> >
> > > Web frameworks, which seem to be the rage now in Python community could
> > > have benefited tremendously from Macro capabilities since they have a
> > > lot of boiler plate.
> >
> > they do?  methinks you haven't done much web programming lately...
> >
> > </F>
>
> You blogged on Django. Let's use that. Don't you think model creation
> in Django can be represented better, given that it is done often
> enough?

Actually, no, it's not done that much.  Creating and managing tables
isn't something done lightly.  It's essential to building a new
application, but (at least in my experience, in similar systems) the
database models stabalize early and you don't spend that much time with
them.  Especially not with the DSL aspects.  I add and remove methods
often, but I am loathe to add and remove columns.

Now, this might seem like I'm being pedantic, but in my experience lots
of seemingly obvious DSLs end up not being that obvious.  XML
generation, for instance.  It's nice to have a good syntax -- and you
can get a pretty good syntax in Python (e.g., HTMLGen, stan, etc).  But
efforts that go further are generally misplaced, because it's actually
not a very hard or common thing to do, even when you are slinging
around lots of XML.

Or... maybe to be more specific, the hard work later on goes into
*code*.  If you are enhancing your model, you do so with methods on the
model classes, and those methods don't effect the DSL, they are just
"code".  You create some raw XML in the beginning, but quickly it's
just a matter of gluing those pieces together, using functions instead
of DSLs, and that's just "code".

> Let's take an example from the official tutorial
> from
> http://www.djangoproject.com/documentation/tutorial1/#creating-models
>
> class Poll(models.Model):
>     question = models.CharField(maxlength=200)
>     pub_date = models.DateTimeField('date published')
>
> class Choice(models.Model):
>     poll = models.ForeignKey(Poll)
>     choice = models.CharField(maxlength=200)
>     votes = models.IntegerField()
>
> I don't use Django and I made this up quickly, so please don't pick on
> subtleties.
>
> @Poll:
>     question: char length 200
>     pub_date('date published'): date
>
> @Choice:
>     poll -> Poll
>     choice: char length 200
>     votes: int

That doesn't look that much better.  How do you create it
programmatically?  I know how to pass a variable to
CharField(maxlength=200); can I pass a variable to "char length 200"
just as easily?  Can I use **kw?  Can I read it from a CSV file and
construct the class that way?  Maybe, but only by recreating all the
native patterns that I can infer easily looking at the Django class.

> The following is my rationale. Annoted variables, symbols and code
> layout visually cue more efficiently to the object nature than do
> explicit text definitions. Of course, this is only sensible when there
> aren't too many of any of those. In that case, the cognitive cost of
> notation outweighs the representational cost of text.

Words are great.  Python is light on symbols, and that is good.  Python
is not perfect when it comes to expressing data structures (the more I
think about it, the more PEP 359 grows on me), but real DSLs are
questionable to me.

Even the Lisps stick to an incredibly homogenous syntax (far more
homogeneous than Python) to make macros feel familiar.

> Representational minimalism is troublesome in general code (ala Perl),
> but not so in a DSL where the context is constrained.

Constrained context is a step backward!  How do you add methods?  How
do you do looping?  How do you write *code*?  If you aren't going to
allow those things, then just make a parser and build the structure
from the file, and make it a DSL implemented entirely external to
Python.  That's completely okay, though in my experience it's not very
satisfying for something like a model definition (see MiddleKit for an
example of an ORM that doesn't use Python code).

  Ian