code is data

[Ian Bicking]

Ravi Teja wrote:
> > 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 don't think that distinction is very meaningful.  As a programmer I
have to understand both.  I have to be able to synthesize correct
expressions.  I need to understand the compiler.  I understand the
Python compiler well, and it gives me reasonably good feedback when I
get things wrong, and it has a lot of flexibility along several
orthogonal lines.

We're talking about programming languages, so it's useless to consider
a cognitive perspective without considering 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.

I understand you, but it's very unclear to me how you can make a thin
layer that's not horribly leaky or stunted.  In my experience one or
both are likely in DSLs, and the result is horrible and only useful as
a toy.

If you are really serious about the implementation, sure.  But DSL
almost screams out that it lacks seriousness, and a long-term
commitment to debuggability, generality, and documentation.

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

I understood the distinction you were making.  But you were also
speaking generally about generally programmable syntax, and I don't
think that's a good idea, and it's very unclear how that mixes with
Python.  You can always do:

  model = make_model("""
  my funny syntax
  """)

And you actually get something that can be a close peer to normal
Python code.  But if you are talking about Python and some novel syntax
interleaved, then the details seem to matter a lot, because the
implementation is substantial and potentially invasive.

There are also very *specific* things that can be discussed that are
more conventional, and driven as much by the ease of implementation as
expressiveness.  I think that is much more productive, because I think
the general case is a bad idea.  The 'make' syntax is an example of
this.

  Ian