[Web-SIG] Re: Just lost another one to Rails

[Martijn Faassen]

Hey,

Not much debate from me here on this front, just a lot of agreement.

Ian Bicking wrote:
> Martijn Faassen wrote:
> [...]
>> One issue seems to be that Python programmers are automatically 
>> allergic to domain specific glue languages like ZCML, especially when 
>> they look like XML. I think this attitude is not really reasonable, 
>> but it's extremely widespread. Jim Fulton looked into a Zope 3 based 
>> bobo a while back; something I haven't studied, but might be a way to 
>> avoid ZCML for some projects.
>  
> In my gut -- and I don't think I'm alone -- ZCML doesn't feel right to 
> me.  It's quite literally a gut feeling, or maybe you could call it a 
> code smell, it just doesn't smell right to me.  Experience might or 
> might not change that feeling, but it's there nonetheless.

Do you think domain specific component configuration/glue languages are 
not right in general, or is it something specific about ZCML in particular?

> [...]
> 
>> This:
>>
>> http://svn.zope.org/Zope3/trunk/src/zope/app/demo/hellopackage/
>>
>> is a documented hello world package in Zope 3 by the way. It creates a 
>> persistent hello world object that can be added through the Zope 3 UI, 
>> with a page template and the like. It's too verbose as a minimal case; 
>> dumping the UI requirement and some stylistic issues could cut it down 
>> a bit more. If you were to add 'hello world' as a template to an 
>> existing object, it'd be a lot simpler still (cutting away all Python 
>> code and just leaving a ZCML snippet to hook up the template, and the 
>> template itself).
> 
> Looking just very briefly, I think the issue is one of approachability 
> and incremental learning.

Agreed completely, very good point. I harped about this on the Zope 3 
list for a while last year.

> There's some big concepts there, and it's 
> unclear where to start.  Interfaces, adaptation, ZCML, ZPT... they are 
> all somewhat foreign, at least to the typical Python programmer.  I 
> think Jeffrey Shell has been trying to create a more linear tutorial 
> with a to-do list, which is probably a good idea.

> A good tutorial -- challenging to make, to be sure -- is one where each 
> step seems clear, relevent to previous steps, and creates something 
> usable.

And where you don't have to say "ooh, this stuff is something you can 
ignore for now", *and* where you don't have to explain a lot of 
irrelevant material as well. My favorite example of this is "Hello 
world" in Python versus "Hello world" in Java. In Java, to new 
programmers, you'll either have to say "well, ignore this class thingy 
for now. Just look at the method. Ignore this too. And that", which 
gives a bad impression of programming. Or alternatively, you'll have to 
explain it all "well, this is a class, and that's to do with object 
oriented programming, which is.." which will confuse and overwhelm new 
programmers entirely.

Zope 3 suffers from the same problem. I think in part this can be solved 
by writing a good tutorial as you say, and in part we need to ruthlessly 
eliminate stuff that we otherwise cannot avoid in the tutorial.

The Zope 3 tutorial as written by Jim Fulton is very complete, but is 
not a good tutorial for beginners in my mind. It introduces functional 
doctesting using tcpwatch before you write your first adapter, or 
something...

I attempted to write something like a simple tutorial in the context of 
Five (Zope 3 in Zope 2). Here they are, in all their magicpoint glory:

http://codespeak.net/svn/z3/Five/trunk/doc/five_interface_tutorial.mgp
http://codespeak.net/svn/z3/Five/trunk/doc/five_views_tutorial.mgp

Most of this can be safely translated to Zope 3, which in fact I did in 
part for a presentation once. It is still too overwhelming perhaps for 
the amount of stuff you end up doing, which isn't that much.

>  I think this is really where my gut feeling about ZCML comes 
> from -- it's intimately tied to other pieces of the code, and often is a 
> prerequesite to making that code functional (at least functional with 
> respect to its real intention, which is usable in a Zope context), and 
> separate files that have to be subtley in sync always makes me 
> uncomfortable.  Of course, that kind of dependency happens all the time, 
> and in an interconnected system you can't expect otherwise.  But I won't 
> try to make it an entirely rational argument, that's not actually where 
> my uncomfortable feeling is coming from.

I recognize the feeling. Python was liberating after having to mess 
about with header files in C and C++ for me, and they are slightly 
similar to ZCML. ZCML and interface files bring the "header file" 
feeling back to Python, which is not good. Even though I also agree that 
this kind of dependency really happens all the time, and you can't 
really expect otherwise in larger systems.

> I also think some concepts are being overused in Zope 3.  Adaptation, 
> specifically -- multi-argument Adapters break my understanding of what 
> Adaptation is supposed to be, and I think they are being used for all 
> sorts of clever, useful things, where "clever" is meant as a pejorative ;)

Can't disagree with you there. I don't think a typical user will run 
into multi-argument adaptation that often though, so I'm not too worried 
about this.

[snip lots more stuff I can only agree with]

I agree completely! We need to get this clear to the Zope 3 core hackers 
though, and I'm not exactly sure how to do that. I mean, I'm sure they 
understand, but I am also fairly certain it's less high on the priority 
list than I think it should be. Then again, there is only so much energy 
available to work on Zope 3 in general, so even if it were high on the 
list, it might still not make fast progress..

> On some level Jim's bobo experiments might be this kind of direction, 
> though as just experiments it's hard to say where that might go.  A more 
> decoupled Zope 3 might be both more accessible and more flexible.  By 
> "decoupled" I don't necessarily mean code changes -- I don't know the 
> details, but I get the impression that what I'm thinking about might be 
> possible right now, that there's been a lot of work to keep Zope 3 
> decoupled in light of the coupling problems in Zope 2.  It's more a 
> matter of perspective, documentation, and packaging.  I suspect this 
> would process would be useful inside Zope as well -- for instance, I 
> think there are users that don't want to use the ZODB at all with Zope 
> 3, but right now there's some trivial dependencies on it (like the root 
> object has to be in the ZODB or something).  If Zope 3 was factored into 
> separate pieces -- traversal, introspection, ZMI, etc. -- it could be 
> both more usable outside of Zope 3 (allowed for incremental adoption), 
> and more usable inside of Zope 3 for people with specific needs or desires.

Yes, this would be good. It's always been a specific intent of Zope 3, 
and has been reached in a large part; personally I've been using Zope 3 
as a "library" to add some of its facilities to Zope 2 for instance, 
with quite some success (Five). It needs to be promoted better though, 
somehow. Zope 3 has a complicated zpackage framework that I don't really 
like (as I think it's a new wheel that nobody will end up adopting, but 
I may be wrong), but it's intended to make packaging individual 
libraries of Zope 3 more easy.

I think another attitude shift related to this that might benefit Zope 3 
is to become *far* more happy to just reuse other people's code than 
it's been historically. The whole idea of "well, it needs to be in ZPL 
and in our repository for us to use it" has got to go somehow. I can see 
where it is coming from, as it makes maintenance and testing more easy, 
but being willing to reuse other projects is the flip side of what 
you're describing.

Sometimes I feel like all these Python web frameworks are sitting there 
and say, there are too many frameworks, why don't you all just use 
*mine*? Never they consider using code written for some other framework. 
:) I am exaggarating, but not that much.

Zope 3's guilty of that; I did it a bit in my reply to Peter, to try to 
make a point. :)

To get a cluster of reusable components all these frameworks can start 
using we need to have two sides:

* more decoupling of the web frameworks, such as Zope 3

* more willingness by the web frameworks to adopt code not in their control

On the good news front, I saw some checkins today indicating Zope 3 is 
gaining more WSGI capabilities, and even Twisted integration now. That's 
exactly what we need more of.

Anyway, I'll try to take action myself in Zope 3 land to improve the 
situation where I can, but I only have so much time and too many things 
to do. :)

Regards,

Martijn