-----BEGIN PGP SIGNED MESSAGE----- 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. - -- =================================================================== 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 iD8DBQFEGD5f+gerLs4ltQ4RAnCjAKDb/6AM4phxLZhHnSPH554Ysv8CIwCfRIUo 8+DrkkvhQFQDB8WGCSC70j4= =X/7J -----END PGP SIGNATURE----- _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com