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

[Zenaan Harkness]

On Mon, Oct 19, 2009 at 11:58:40AM -0700, Joseph Grace wrote:
> Principle<http://en.wikipedia.org/wiki/Robustness_Principle> (also

Excellent! Well found.

> However, I still prefer my phrasing of it "Be strict in what you generate,
> but generous in what you accept."

I'd change one word - change "but" to "and" :)


> Zenaan Harkness* wrote at *Sun Oct 18 18:22:26 PDT 2009:*
> 
> > If we added native.if, are there other operators you see
> > being useful in the native.* library?
> 
> I am not looking to add operators other than "if.*" to the core language.
> 
> The ST philosophy is strict separation of concerns.  Even the existing
> "if" is a violation of strict separation in that ST inspects an aspect
> of the model albeit in a very tidy way.  The recognition of a second
> "if" is another step toward such pragmatism.  I believe the
> "Robustness Principle" (strict in what you generate, generous in what
> you accept) explains why these "if.*" are so important even though
> (strictly speaking) they violate the purity of the language.  Add

Robustness as in accept generously, is more like accepting many inputs,
even error inputs, even though it might produce error outputs. As in,
not being so strict on inputs that everything is short-circuited,
therefore making it harder to find errors.

As seen, ST's if is not really necessary at all. It's just a
convenience. This is a different principle, that of flexibility/
featurefullness, which may or may not increase complexity, but of itself
does not affect what data is accepted in a raw state (data processing
aside).


> > Modifying ST into 'platform specific' variants is a significant
> > change if it were undertaken.
> 
> That's not my intent or intended suggestion.  The only supported
> compatibility variant as envisioned would be the one instruction,
> "native.if".  The rest of the "native.*" namespace would be for user
> customizations (unsupported, Use At Your Own Risk).

If allowed, I see users would easily, readily, and pretty much
immediately (for newcomers untrained in the true 'way' of ST :)
add native.or, native.and, native.add and native.sqrt :)

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


> > A native.* library would be good to think/ plan for in advance
> > though, rather than one feature at a time, don't you think?
> 
> I'm thinking of "native.*" more as opening the door to user
> extensions, not as a new part of the language.  Mostly for ease of

And that's the problem.

There users can already extend in renderers, violating ST best practice,
but it's very clear that you are doing that _and_ it is 'ugly' enough
that it just wouldn't catch on as standard practice.

There must be a principle here somewhere 'Robust Design Encouragement'
or some such, which as you are aware, ST holds quite strenuously to.


> The basic existence "if" is a practical necessity, and has been shown
> largely "necessary and sufficient" for ST just not totally practical.

I think you mean 'not totally flexible'. ST if is entirely practical,
and highly convenient.


...
> 1.  Should ST add a single monolithic operator, "ifnull".  Is that
> practical?

Yes. It is practical.

Whether it's called ifnull, or if.null, is almost immaterial to
template authors.

And if we add if[.]empty, that is orthogonal (not directly related)
concern too.


> 2. Should ST then add a clean syntax for multiple "if.*" language
> independent operators?  Is that practical?  What if a common use case

Clean and easy syntax which provides for Violation of Robust Design,
is a problem!


> is to dovetail ST onto an existing system, in a native language, and
> the native language "if" is not found in ST?  What if ease of use is
> compromised without native language friendly "if"?

Here's my 'rub':

We _do_ have before us, an actual, experienced-by-various people on
this list, ST 'limitation' (boolean testing of null and sometimes
empty) for which a simple non-Robust-Design-Violation-encouraging
solution is also before us: ifnull and ifempty, and null= and empty=
in list processing.

1) I cannot say the same for native.*

2) And I can say that native.* looks horribly slippery.

Until these two concerns (non-existent example, and slippery slope
problem) are addressed, I have to NACK user-extensible native.*,
and most probably also native.if. Strong protection against
violation of principles, is trumps here.

best
zen

-- 
Homepage: www.SoulSound.net -- Free Australia: www.UPMART.org
Please respect the confidentiality of this email as sensibly warranted.