Forum OpenACS Q&A: Response to Article on ACS x Zope
"Zope is probably somewhat more complex behind the scenes because it attempts to make the job easier for the 'user' of the Zope web development tool, not necessarily the 'developer'. Zope is great for managing content and users."
Distinguishing between developers of the code and users of the code seems like an odd one to make in the world of Open Source. Not only is ACS (relatively) easy to use; it's also (relatively) easy to see how it's wired together. To my mind, this is a huge benefit for those users who don't like the way a piece of the damned thing works. I haven't worked with Zope, but I have worked with closed-source application servers that are based on a similar idea that the users of the tool didn't need to understand what was going on under the hood. It was a nightmare.
The other side of this argument might be that if you have a good OO system with encapsulation, most developers don't really need to understand how each object works. Perhaps this is different than not knowing how your application server works; I'm not in a position to judge that. Or maybe the argument is that once you understand Zope's OO, then understanding it's source code will be easy. I'm not in a position to judge that either. Regardless, neither of these answers satisfies the underlying aesthetic of ACS. Making the system itself "rat-simple" (in Philip's words) is a central philosophical tenet of ACS, where it is clearly an ancillary (if important) goal for the Zope folks.
In my mind, then, the question is what I get in return for giving up that simplicity. The one argument I have heard so far is superior portability, which the OpenACS team believes can be achieved without sacrificing the simplicity of the system. I won't evaluate this point since I don't have the expertise; I'll just say that it's a point of contention between the two groups. OK, next argument. One of the claims that I've heard in favor of using Python is that it's easy for one programmer to read and maintain another programmer's code. But again, this advantage seems to be nullified by the simplicity (or lack thereof) in the two systems. (And the advantage is usually touted in comparison to Perl, not tcl.) We don't know how development time or scalability compare because Zope apparently doesn't have enough of a track record to provide data. If there are other pros and cons to be considered, I haven't heard them (or understood them) yet.
It may be that you Zope folks believe that OO in general and the Zope implementation in particular will be superior in some or all of these areas (i.e., scalability, reduced development time, portability, ease of maintenance, and simplicity) in the long-run but that it's a theory you're still testing. There's nothing wrong with that. At this point, though, it sounds like your argument is just that--a theory.