This continues the "agile content development" thread that has been mentioned here and elsewhere. In the vein of that thread, I'd like to suggest a replacement for "through the web" (TTW) programming. I'm going to call it "through the book" (TTB) programming.

Through the book programming is almost too simple to describe. Instead of creating an alternate programming environment for people with less experience ("scripters", "site developers", "content developers"), I suggest they use the same environment that the people with more experience have and we make that environment more self-consistent via documentation, repeated patterns, and code generation.

Documentation: for Zope 3, this is Jim's tutorial, Phil's book and others of the ilk. Zope 2 is a bit of a lost cause in this respect; because it's not self-consistent, documenting Zope 2 is a process of documenting a litany of exceptions, which is impossible, because new ones are continually found at a blistering pace.

Repeated patterns: Python is the poster child for repeated patterns; this is why it's often referred to as "runnable pseudocode". For Zope 3, interfaces and adaptation are self-consistent patterns that extend Python in simple but important ways. Zope 2 is also a lost cause here also due to its organic growth process and inability to figure out what it wanted to be.

Code generation: often just starting a project is the very hardest thing to do. Projects like Ben Saller's "Skeletor" aim to make this easier by generating template projects for various tasks. This could work for both Zope 2 and Zope 3.

The benefits of this pattern are these:

• We don't need to create and maintain as much software (just the skeleton generators) as we would if we created a framework solely for "scripters".
• Solutions created by a "scripter" would not need to be scrapped and started over once the scripter "becomes a developer" (which is just the natural order of things even if you believe there is a difference in the first place).
• We follow the lead of Python, which is an environment which "scales" from simple procedural programming to behemoth object models without requiring a developer learn all of its concepts at once.

Problems:

• There is a temptation to prematurely generalize a problem and solve it in a core framework, making its solution difficult for new users to understand because it's by nature quite fuzzy. I'd point at the variety of tasks performed in the ZMI in Zope 2 as an example as well as maybe even things like the addform/editform configuration in Zope 3. The solution? It's good to have these kinds of things live outside the core framework entirely; once they've been beaten on for a reasonable amount of time (this could be years) and have proved useful and self-consistent, integrate them. This is really just a matter of being discerning.
• TIMTOWTDI... ex: do I put this logic in TAL+TALES expressions or in a view class? One solution is to choose technologies that make these distinctions clearer (maybe don't use TAL). The other is to clearly document best practices. The former is easier.
• New users won't use it because it doesn't have a GUI. No way to solve this one without writing a set of GUI tools, but another option is to just say "oh well" and move on with life.