-----BEGIN PGP SIGNED MESSAGE-----
Jim Fulton wrote:
> Martijn Faassen wrote:
>> Shane Hathaway wrote:
>>> Jim Fulton wrote:
>>>> Shane Hathaway wrote:
>>>>> +1. When I learn a skill, it is at first completely explicit, and
>>>>> as the skill becomes predictable and reliable, it gradually becomes
>>>>> implicit. If I kept everything explicit, I would hinder myself
>>>>> from building higher level skills.
>>>>> So explicit is better than implicit until a sufficiently tight
>>>>> abstraction comes about. Take memory management: yesterday it was
>>>>> explicit (malloc/free); today it's mostly implicit (garbage
>>>>> collection). Garbage collection is both an abstraction, since
>>>>> programmers no longer manage memory directly, and an indirection,
>>>>> since programmers now use APIs that call malloc and free. We all
>>>>> agree GC is good, so explicit is definitely not always better than
>>>> Thanks for explaining "Explicit is better than implicit,
>>>> except when it's not."
>>> Admittedly, I should have posted that in my blog, not here. :-)
>> I appreciated you making it explicit, Shane, even though I already
>> knew and fully agree. :)
>> I sometimes express this principle as "magic is bad unless it's
>> perfect magic". Do post it on your blog.
> Yes, it is a good thing to know, except that it is incomplete and
> obscures an important point. Magic always has the downside that it
> hides things. Often, as in the case of garbage collection, the benefit
> outweighs the cost. Too often though, people introduce magic
> (aka abstraction, indirection, automation) when the benefit doesn't
> justify the hiding. One should always approach magic with skepticism.
> This is an important design principle. The "explicit is better than
> implicit" is a guide, not a rule never to be broken. It's something we
> should start with. Does that mean we never provide automation? Of
> course not.
I wonder if there isn't a sore spot which is driving a lot of the
discussion here, but isn't being mentioned: the experiment in form
definition (browser:addform / browser:editform). The interesting thing
about that experiment is that it *almost* worked, as magic; its failure
was not in what it made easier (generating a view from a schema *and* a
policy), but in what it made harder (changing the behavior of the
Developers who are the only admins for the sites they deploy are *not*
representative of the intended audience for ZCML; they are much more
comfortable with "back to Python" as a solution than more traditional
admins / integrators would be. "Big" directives, with clearly
documented knobs for specifying policies, are likely to appeal more to
folks sho are *not* inclined to write Python.
The fact that such developer-admins are the primary users of ZCML so far
is due to the small size of the Zope3 market to date.
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope3-dev mailing list