An interesting Zope 3 Critique from Ian Bicking, who has always got something valid to say. He’s a very pragmatic guy, because all of his effort goes into running code, and this comes out in this post.
He is generally right here as well I think. Adaptation is a really powerful technique which probably (along with generic functions) does deserve to be a first order item in the toolkit, with direct python language support.
Jean-Marc’s critique is way off beam though. I think he’s doing some serious post-purchase justification of Nuxeo’s switch. I can really understand their position, but they are playing to the Enterprise market, and Enterprise means either .NET or Java right now. If every enterprise application were well designed and built, it wouldn’t matter if you weren’t using Java or .NET – but that is, frankly, not the case. And it is quite reasonable for CTOs who have a big Java shop to want code to be written in Java. They have other concerns than what the best technology for the job in hand is. I have been there myself, and it really is fine to make those sorts of distinctions.
I’m in an odd position, as I came to Adaptation first through Twisted. Twisted has the finest architecture I’ve seen, bar none. They’ve made heavy use of Adaptation, but tactically, rather than with the broad strategic sweep within Zope. That probably is the biggest criticism of Zope 3 that is I think fair, and that both Ian and Jean-Marc make. Patterns are about solutions in context, and Adaptation is no different. It’s a really useful pattern, and one that, within a specific domain, has immense traction. It really isn’t a Golden Hammer though.
The ZCML issue is one the twisted guys have come up against a few times too. They had, at one point, their own registry syntax to specify adapters — it was massively simpler, obviously, but it was functionally equivalent to ZCML, and they ditched it. Providing a generic solution for a registry is not a new problem, and in the end I think the solution is to allow packages to provide code that answers the question, not just data.
“Big” architecture, such as the Zope 3 Component Architecture and J2EE in the end seem to cause more problems than they solve. Ultimately “Architecture” at it’s best really is just a pretty random collection of rules of thumb and handy concepts to solve specific use cases, just as it is in meatspace with the built environment. Trying to design software by starting with the solution and working back is just as bad as building a city by laying out a grid and then trying to fit people into it.
Recent comments