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.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to