Why isn't Python king of the hill?

[Geoffrey Gerrietts]

I've spent a lot of time trying to come up with a response to
Martijn's comments and questions. It's taken me more time than I
thought it would. My first cut was approaching a novel in length.
I'm going to try to restrain myself to the salient points this
time. (Still didn't do all that good a job, did I?)

Martijn writes:
> [ deletia ]
> How does Zope's ZEO fit in this picture? I would think it'd
> help scale a Python app across a lot of boxes, right? Zope of
> course has a persistence toolkit; the ZODB. RPC mechanisms
> exist for Zope as well; for instance XML-RPC.  How were these
> not satisfactory? 

We use ZEO to centralize our actual Zope objects. Business
objects, the core of our dynamic model, are managed outside Zope.
In Zope, we have images and DTML content, with a few wrapper
objects around external entities. We use an authentication scheme
that uses Zope's ACL mechanisms but stores user records in a SQL
database.

I've looked at ZODB and ZEO some for my personal edification. If
I'm not mistaken, they provide a great mechanism for object
persistence with key-based retrieval. My evaluation suggested
that ZODB and ZEO were not very good at handling arbitrary
retrieval, or even retrieval at the level of a SQL select
statement. I don't think we should expect them to do that, but
that's a very real requirement for much or most business data.

I don't know a whole lot about Zope and XML-RPC. I've read bits
and pieces on one site or another. It looks pretty easy to use
when Zope is your XML-RPC server, and it looks pretty easy to use
when you're on the client end of an XML-RPC call. Developing a
server seems only slightly more complicated, and looks to be
something that could be automated or abstracted fairly readily.

We use ILU in the place where XML-RPC would be. I honestly can't
give you a compare-contrast as to how the two crack up against
one another, or why we picked ILU. I suspect that we use ILU
because it was available and mature when the site was being
pulled together. Maybe one of the original architects had some
good reusable code generation tools to use with ILU.

I think our deployment benefits from ILU's directory-based
approach. An ILU server publishes where it's running so that
clients can connect to it; that adds a little fault-tolerance and
scalability to the design. On the other hand, ILU's pretty rigid
about a lot of things, so in a few specific spots in our
application, we've sacrificed some of the freedoms that generally
come with programming in Python.

Now I've answered the questions (I think fairly), but I'd like to
take a step back and re-frame my comments.

I like Python and I like programming in Python. I took this job
because I would get to program in Python. Some of my peers don't
share my enthusiasm, which is a shame, but I think they're
learning to appreciate it.

When I think about designing a webapp, though, I don't think
about an app like the one I'm working on now. I think about an
app I worked on a couple years back, one that really deserved to
be a webapp but wasn't.

That app ran out of an office of a half-dozen fairly tech-savvy
librarians. They knew web stuff, but did not know programming.
They had to hire consultants to develop for them, and hire
consultants to do system administration for them.

When I think about designing a webapp, this is the webapp I think
about -- the one I never got to write. For the last year or year
and a half, that mental design has been done in Java. In moments
of weakness, I think that I could get away with using Jython, but
in the end I come back to straight Java. The Java toolkit won't
make development any faster, but it does have other compelling
features.

Some of the features are either lacking or hidden to my limited
vision in Python, notably decimal math and PDF generation.
There's a certain draw to being able to take a single webapp and
deploy it on any of a dozen different app servers that know how
to handle the content, though it's small. But the biggest draw is
that someone who's proficient with Java is not too hard to find.
Someone who's proficient with Python is considerably harder to
lay hands on.

Furthermore, while performance isn't a huge deal to those folks,
their app did show signs of growing to cover a lot more terrain.
It's conceivable that once the app was turned loose, it really
would need to worry about the kind of massive load that starts to
show off Python's seams.

I think that part of the issue here is that when I think about a
webapp, I don't think about an app that will be written and won't
change. I don't think about working on the same app for the rest
of my life, or even for more than a couple years. And I think
about something that's continually growing, and I plan as if it
will be as cool to the rest of the world as I think it is.

For more modest ambitions, the factors that weigh heavy on me may
seem irrelevant or even overweening. :) Meanwhile, I'll build all
my administration tools, glue apps, and prototypes in Python. :)

Thanks,
--G.

---
Geoff Gerrietts <geoff at homegain.com>
I think I'm really speaking only for myself here.