Forum OpenACS Q&A: Response to Article on ACS x Zope
procedural from functional from multi-paradigm, ... Nor should they need to. They don't know Python from Perl
from Tcl. They don't know SQL. They just want to build a website. "
You can build significant websites with the ACS without doing any programming whatsoever, that's one of the toolkit goals.
Now ... there are some significant problems with the current implementation. Presentation isn't split out from the guts for the most part. But a primitive templating system using ADP pages (which allow the embedding of Tcl variables and code snippets in a way not all that different than done in DTML) exists and is being adopted for more of the toolkit in the upcoming ACS 4.0. Admin pages used for customization tend to lag the data model. New features like templating aren't backfitted to legacy modules in a timely fashion.
This, though, is an arsDigita resource problem, not a design methodology problem per se. New features tend to fall out of client sites and are integrated just well enough meet contract needs - that's my impression from the outside, at least. Recently, aD has hired toolkit engineers whose job is to address this (and other) problems. They won't be tied to client development contracts but will be free to concentrate on core technology. Three cheers!
Despite these flaws, if you're willing to stick with the vanilla presentation style, much can be done from the admin pages in a matter of an afternoon or so.
Customization's still primitive, but growing in usability from this point of view. Certainly the goal is to make it increasingly possible for non-programmers to build ACS-based sites. And to increase the level of customization possible without digging into and hacking the code.
So I don't quite see your point in regard to the Zope vs. ACS debate. Does Zope provide a greater level of out-of-the-box customization than the ACS? I'm curious.
Whether or not, it's a matter of design goals and implementation completeness, not Zope's OO design vs. the ACS thin layer atop an RDBMS approach. Either paradigm can lead to a similar level of customization.