code is data

[Ravi Teja]

> 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".

> 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.

I am looking at it from the cognitive perspective. You are looking at
it from the compiler perspective.

I think you are talking about full blown DSLs like SQL which try to be
self contained for a given domain. The ones I am referring are only
thin layers on Python.

> Words are great. Python is light on symbols, and that is good.

Agreed. When I came to Python from Perl, I loved the clean syntax.
Scalars, arrays, hashes occur too frequently in Perl code that using
symbols to denote them causes more noise than cognitive assistance. On
the other hand, using symbols to denote an occational special construct
is helpful (as in decorators).

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

Yes! The parser friendly, "everything is a list" syntax does help. I
did consider that to be an essential feature to enable dynamic macros.
However I changed my mind when I saw Logix macro syntax.

> 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).

I agree that constrained context is a step back in terms flexibility.
But it is a strategic step backwards, in this case to trade for
representational benefits. The extent of constraints is a judgement
call. And proof of utility can only be emperical.

However I think that you are seeing my sample differently than I meant
it. I did not mean to create a special syntax file that would be parsed
as a text file such that it would loose all the benefits of Python. It
is just a thin layer over Python code for specific representational
benefits. Kay Schluehr does a good job of identifying it as such in his
reply.