[stringtemplate-interest] On Pragmatism Violating Purity For The Win

[Joseph Grace]

*Zenaan Harkness* wrote on *Mon Oct 19 19:27:25 PDT 2009:*

*>>"Be strict in what you generate, but generous in what you accept."***>
>I'd change one word - change "but" to "and" :)

*  "Be strict in what you generate, [and] generous in what you accept."

Zen, that's definitely better.  Thank you.  Done.

> Robustness as in accept generously, is more like accepting many inputs,
> even error inputs, even though it might produce error outputs.

That's a common first impression of the "Robustness Principle", but it
definitely does NOT do that.  It originates in networking (TCP/IP)
where generating errors is absolutely unacceptable, hence the "Be
strict in what you generate".  Error tolerance:  0.

However, datagram specs are very strict, so often "errors" are
innocuous (e.g., non-zero values in undefined (zero) fields).
Sometimes they appear to be errors, but really represent backwards
compatible version mismatches (one version's junk is another newer
version's backward compatible bits!).  The Robustness Principle
provides a guideline to pass seemingly errant datagrams ignoring
innocuous variations to enable forward compatibility for such cases
(and protocol designers specifically design to take advantage of
Robustness).

For our purposes, the non-spec data is data which needs massaging
before ST can handle it, so we apply the Robustness Principle and
massage it into StringTemplate using (e.g.) "model.*" or "glue.*".  As
long as the data is discernible, we shape it into a form ST accepts.
Then we process it.  The end result would be an easier to use, more
diversely capable, adaptable, and compatible ST.

This robustness means increased ease of use for ST, and adaptability
to diverse conditions.  It would also mean ST could do its part to
keep workflow moving even model developers are unwilling or
unavailable to adjust model output.  Flexible ST would to non-spec
data by (e.g.) massaging it into ST-compatible form, then processing
it.

> Instant slippery slope, no let's say oiled water slide, it seems..

> [and later]  2) And I can say that native.* looks horribly slippery.

Ack to both. No disagreement here. However, this slippery slope already
exists in the form of formatters, correct? And people use it from time to
time for just this purpose, e.g., for "Truncate string" in java:

http://www.antlr.org/pipermail/stringtemplate-interest/2009-May/001954.html

The difference is that the "model.*" feature would acknowledge and approve
[Robustness Principle] this need with language specific hooks, not chastise
prospects for thinking impurely (but correctly).

Emphasis is on massaging input, and offloading other sticky issues from pure
ST (or a stubborn model). ST becomes the good citizen by generously
accepting whatever the models send its way.

FYI, earlier today, I spent some time reading the list from the first half
of the year. There are a variety of examples of people asking for help
massaging data on its way into ST, or pulling key information from the model
for ST/view access. Those are both expressed needs, especially if the model
is off-limits (as in, if the model works don't fix it or touch it). Here are
two posts. The first requests a minor input massage feature, and the second
(Ter himself) suggests a need for some additional data metrics (data shape
information):

http://www.antlr.org/pipermail/stringtemplate-interest/2009-May/001921.html
http://www.antlr.org/pipermail/stringtemplate-interest/2009-May/001939.html

These issues would be perfect candidates for "model.*" hook customization.
If a "model.*" hook existed, users could develop such features as needed,
and then migrate them into common ST usage only after being proven (or
never). Pressure to change ST would be relieved, so core ST could remain
true to its purity roots. Yet ST would generously accept any discernible
input [Robustness Principle] and become a genuinely good citizen even for
legacy or complex models.

IMO, ST needs to be a good citizen and handle glue issues even if they're
not strictly ST's problem. I believe ST perenially loses converts due to the
purist "Do it in the model!" attitude. By adopting a more accomodating
attitude of

"Do it in model.*!"

We all believe ST's purity is valuable, but if many people can't use ST, who
cares? I believe purist inflexibility is hurting ST for some projects and
crimping its growth. I believe something like "model.*" addresses critical
ST adoption issues and makes ST more accessible, flexible, and relevant to
more projects.

Cheers,

= Joe =
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/stringtemplate-interest/attachments/20091019/bc478576/attachment.html