On Wednesday 04 October 2006 13:25, Trey Harris wrote:
> I read it as "yes, you *can* put strictures on the using code into a
> library, though I wouldn't do it and would say that any module that does
> so shouldn't be released on CPAN for general use. But even if you can do
> that, you *must* always be able to turn the strictures back off."
> chromatic, is that a fair paraphrase?
Yes.
> I don't have any problem with that sentiment--if I were you and needed to
> enforce some style on other programmers who work with me, I'd just tell
> them to use my library and not unuse it. It's a human problem, not a
> technical one, if they insist on unusing it by nefarious means.
Very much so. It seems silly to put up barriers such that clever people have
to use ugly and hackish tricks to do clever things while attempting to use
technology to solve the social problem of other people doing really bad
things. If you violate my first law of software development ("Don't hire
monkeys!"), then you should at least follow its corollary ("Train your
monkeys well and watch them very carefully. Note how unfulfilling your life
is for violating the first law.").
> That philosophy doesn't present any problems with DBC checks, which as I
> mentioned before probably have to handled as a program-global flag rather
> than as a lexical pragma anyway. (I'm toying with the notion of
> "jurisdictions" that packages could subscribe to across which a set of
> contracts would be enforceable, allowing them to do DBC while still using
> or being used by code out in some other lawless jurisdiction. Code that
> doesn't explicitly join some jurisdiction would by default be lawless,
> thus living by the philosophy chromatic's espousing. I think that could
> be made to work, though jurisdictions would have to be at a package, not
> scope, level. I need to think about it more, though.)
That sort of thing ought to be quite possible, but the less work we spend on
giving people the illusion that this discipline is inescapable and perfectly
capable, the more time we'll have to tell them how to avoid hiring monkeys,
which actually fixes more problems in software development than anything else
I've ever seen.
-- c
