Hash: SHA1

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
>>>>> implicit.
>>>> 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
generated view).

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
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to