[Zope3-dev] Number of languages in Zope 3

[Ken Manheimer]

I'm heading out (almost immediately) to vacation for a few days, so
won't be able to follow this further, but i wanted to point out
something i noticed in this message, and can't resist throwing in my
own perspective...-)

On Wed, 9 Apr 2003, Joachim Werner wrote:

> But that exactly is my point: If you are a designer and get to know the 
> basic bath-based ZPT/TAL syntax then you have some promising success at 
> the very beginning (adding a here/title works fine). But as soon as you 
> need to use something a bit more advanced you have to learn another, 
> different syntax. And this process is much more time-consuming and 
> frustrating than having to learn an only slightly more complicated 
> syntax at the beginning.
> [...]
> I don't know how current Zope first-timers get along with ZPT, but 
> considering that ZPT is much more complex in syntax I can't believe that 
> things have become better now.

If we accept that (1) having more complexity up front is better for
learning the language, or that (2) ZPT is more complex, then i have to
ask you, might ZPT be exactly what you're suggesting?  That is, a
higher hurdle to start, but less steep and surprising learning
thenceforth.

I actually happen to think that ZPT appears to be more complex up
front, but is a lot _less_ complex overall, because it is much more
regular.  dtml design choices involved enough expediency that it
doesn't behave _regularly_ - it is

  (a) too unconstrained, and

  (b) has a lot of special rules

These characteristics make the language full of emergent behavior,
where it's hard to predict how something will fail or succeed until
you try it, and then it can be hard to tell where it goes awry.

(Examples of what i mean:

 (a) too unconstrained: you can intersperse dtml code in html without
     regard for the html code structure, enabling you to emit invalid
     html fragments that can obscure where your results are off, in
     bizarre and often unfathomable ways.  To me, this is exactly like
     the freedom of 'goto' in a programming language - ill behaved and
     a cardinal sin.

 (b) having a lot of special rules: eg, needing to refer to some
     variables with "_['sequence-item']" because 'sequence-item' is
     not a valid python name; the implicit "expr=" entailed in using
     double quotes around a value; there's *tons* of these.
)

zpt is quite different - the rules are much, much more systematic and
regular.  They are constrained to play cohesively with html/xhtml/xml.
Pretty much all are explainable by first principles, instead of
incidental nuances provided as shortcuts or to correct for
incongruencies in the language.  This makes for a more structured
language, with some more overhead starting out, but the rules and
understandings all carry over consistently, so that you don't get
unexpected complexity as you progress.  This is when more complexity
up front can be ok - when it means a more regular, predictable
language in total.

I think it's much worse to require people to take on irregular, quirky
languages (which is where i would put dtml - even those who love the
quirks have to admit they're quirks!-) versus requiring people to get
some grasp of regular and comprehensible languages.  The foundation in
python - a particularly regular, comprehensible language - is not an
accidental or incidental thing.

I don't mean to make this a tirade about the virtues of zpt over dtml.
Rather, i want to focus on how complexity is "moved around". Having to
learn another language within a language (ie, python expressions
within zpt/tal) is costly, and i can see the merits of reducing the
need for it.  It does *not* automatically follow, however, that we can
eliminate python expressions in tal and thereby reduce tal's
complexity.  We have to base our decisions on the functionality that
must be available, and see how much can be achieved with path
expressions *short of making them contorted*.  You can move complexity
around, and sometimes reduce the learning burden with cogent, cohesive
choices.  Ultimately, though, necessary, complex functionality demands
expertise.

--
Ken
klm@zope.com