Why isn't Python king of the hill?

[Geoffrey Gerrietts]

I think a little easier to keep myself on target this time, but
watch out! I bet I start to ramble near the end. :)

Martijn writes:
> How does Zope interact with the business objects? Through
> external methods?
>
> I suppose this could be somewhat comparable with running CORBA 
> servers, right? I don't have much experience in this area, though
> I'm very curious to hear more about how you integrate Zope with 
> this.

I don't want to get into a position where I'm spilling too much
proprietary information, so I'll be a little vague. I apologize
in advance for that.

The answers to these questions are related. We don't have a
really clean MVC separation in our app, though we're trying to
make it cleaner.

The "Model" portion of the architecture consists of an Oracle
database and lots of small object servers. We try to keep the
business logic at this layer of the app, with varying degrees of
success. These servers publish their availability through ILU.

The "Controller" portion of the architecture consists of external
methods. The external methods should ideally handle little more
than convert and validate input, then pass it off to the "Model"
part of the app, through ILU.

The "View" portion of the app is DTML in Zope, served from a ZEO
database.

One of the nice features we have working for us is a "Service"
product that holds a cache of connected ILU clients. These
clients can be accessed from Zope or from our (slightly modified)
external methods, though access from DTML is frowned on. I'm not
sure where we got the Service product, or whether it would even
work with current revs of Zope. I think Digital Creations might
have had a hand in developing that.

I think that answers the question without getting me in trouble?
:)

Martijn writes (quoting me):
> > 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.
> 
> What do you mean with 'arbitrary retrieval'?

I'm meaning something more along the lines of a real indexing and
retrieval engine here. A query might be something like "I want
all objects that have the word 'spam' in any of their
attributes". This compares to key-based retrieval which says "I
want the object with the key 'spam'" or the SQL-style retrieval
which says "I want the objects that contain the word 'spam' in
the column 'eggs' in the table 'bacon'."

Our application doesn't require arbitrary retrieval in its
current incarnation.

Martijn writes (quoting me):
> > Some of the features are either lacking or hidden to my limited
> > vision in Python, notably decimal math and PDF generation.
> 
> Python has reportlab for PDF, which seems to work pretty well:
> 
> http://www.reportlab.com

And Aahz contributes:
> Not quite.  There's currently a PEP for making the default *rational*
> arithmetic; I'm currently working on a module based on the ANSI standard
> for decimal floating-point arithmetic.  There's already Tim Peters's
> FixedPoint for fixed-point decimal arithmetic.

It would appear "hidden to my limited vision" is the appropriate
answer here. :) I didn't know about FixedPoint, which would
address most of my concerns. And I look very forward to Aahz's
implementation of decimal FP arithmetic. :)

To answer an un-quoted question, fixed point or decimal math is
required because dollars are involved. Binary FP's approximations
show up in odd places when you're doing decimal math, which makes
people uncomfortable when dealing with money.

Martijn writes (quoting me):
> > 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.
> 
> What do you mean by this, exactly? Are you referring to the whole
> Enterprise JavaBeans framework (sorry if I confuse any of the
> terminology here) that's been implemented by various vendors? I've
> always been skeptical about how well that actually works, but here
> I'm skeptical without any actual real knowledge. :)

I can't speak to how easy it is to move from one app server to
another. I /can/ speak for how much of the "hard work" is done
for you by some of these enterprise containers -- a whole lot!

I'm not sure how Python and the Python community as it currently
exists could actually /do/ the servlet thing. It's an API, but
it's also a specification of a standard; Sun can get away with
declaring The Standard because they have such tight control over
Java. Python's more open community proves something of a weakness
here -- Zope is "standard" in a de facto sense, but everyone who
sets out to develop a templating language or a content server or
an app server sets out to do it in their own way, with their own
set of interfaces in mind. That means moving between servers
requires a layer of adaptor code in the best case, or a total
rewrite in worst.

Martijn writes (quoting me):
> > But the biggest draw is that someone who's proficient with
> > Java is not too hard to find.
> 
> Are you sure about this? I mean, sure, lots of people are being
> cranked out that can use Java to a certain extent, but is it
> really true that it's not hard to find someone *good* at it?
> 
> > Someone who's proficient with Python is considerably harder to
> > lay hands on.
> 
> But I'd think that anyone who's actually good at Java would be 
> retrainable to use Python in a matter of days.

Java programmers are more numerous than Python programmers.
"Good" is relative. I think "able to work on an app I wrote" is a
decent measure of goodness, and I think it's pretty safe to say
that someone who knows enough Java to pass a programming class
taught in Java could find his way around most of the Java apps I
write. A person coming out of school with a class taught in
Python might not have too much trouble with most of what I do in
Python, either -- but while I know plenty of people who passed
their Java classes, I don't know of anyone who has even taken a
Python class.

I agree that a person could be retrained to use Python, and could
learn Zope. Python's not a terribly difficult language to learn,
and it's a language that keeps on giving the longer you use it.
But I do think that it would be difficult for someone hired as a
consultant to walk in cold and learn enough Python and Zope to
make sense of how the app worked.

My office here is filled with C programmers who learned python on
the job, PHP programmers who learned Zope on the job, Java
programmers who came in cold. They all got up to speed in very
short order.

On the other hand, if the site had been less successful, and the
company could not afford to bring on full-time staff and pay to
have them trained -- if the company needed to hire a couple
contract programmers to come in and change a few things, add a
few things -- the company would have looked a very long time for
someone proficient enough in Zope and Python to come in cold and
make the changes they needed.

And it was a fierce struggle for several months, with three or
four programmers who knew nothing of Python or Zope. Those days
are spoken of with awe and terror; it was difficult enough for
someone like me, who knew his way around Python, to come in and
figure out Zope and our architecture. I can't even imagine what
it must have been like for people who didn't even know the
language.

If the app were done in Java, it would be a lot easier to hire
people who knew at least a little Java and could find their way
around the servlet API and JSP, whether as permanent employees or
temporary contractors. That's just because of the demographics.

Meanwhile, it's also a lot easier -- at least in our area -- to
send your employees off to a three day class on Java or JSP and
servlets, and it's easier to learn all three topics from any
number of widely-published, well-written books. Zope training
involved flying Matt out here from Digital Creations, and the
documentation is scarce.

Martijn (quoting me):
> > 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.
> 
> Are Java's seams that much tighter? I know it's faster, on average,
> though it does seem to consume oodles of memory. And then there's the
> question about closing the seams; it would seem to me that this would
> be easier to do in Python in many situations, because it's just a lot
> more flexible.

Good point and maybe a tough call. I think it's easier to scale
Java, because it's easier for good programmers to write scalable
apps and harder for bad programmers to write apps that don't
scale.

Java's got its warts, too, though. It's a long way away from a
Perfect Language, and it's a resource-hungry monster.

Martijn writes:
> Any larger app will have to grow and change over time, so I
> consider this as well for my Zope/Python/relational database
> apps, which is why I'm interested in your ideas about what
> makes Java more suitable for these purposes. Not so I can go
> and use Java, but for stealing some ideas. :)

Probably the sanest thing either of us could be doing in this
discussion. :)

Let's see if we can come up with a short list -- I don't think
these belong in the PEPs, really, maybe just ideas for people's
projects? Maybe the first idea is some kind of formalized
community that would provide support for these kinds of
discussions? I don't know.

But the ideas.

It would be very good if you could take an object, instantiate it
in the context of a container, and basically have proxies
propagated to all other applications that have instantiated that
container.

Let's put it a different way, more abstract and less tied to
implementation. It would be very good if you could write an
object that conforms to a reasonable interface, and in so doing
"gain" the ability to use the object in a distributed fashion.

Currently, you've got to do it all by hand, and you can't count
on the way you do it one time being re-usable the next time.
There's no /standard/ way of doing it, and there's more than one
way to do it. That's treading into Perl's territory, there....

Here's something I like about the servlet containers (app
servers) that I haven't seen in Zope yet (maybe it's there?):
managed sessions via cookies OR URL rewriting. Some of the
servlet containers even support persistent sessions and sessions
shared across multiple app servers. When you have fault-tolerance
at that level of the application, that's powerful juju.

This is actually three features in one: managed sessions, persistent
sessions, and distributed sessions. Managed sessions means
providing session tracking mechanisms (preferably configurable).
Persistent sessions means that the sessions can survive a crash
and restart of the server. And distributed sessions means that
the same session can be accessed regardless of which server
process is handling the current request. The last two depend on
the first, but sessions could be either distributed or persistent
without also being the other.

Here's another one, one we can beat Java to the punch on: it
would be nice if you could do object storage and retrieval into a
relational database using a simple management framework. The
upcoming Java Data Objects spec is an easy example to look at,
but also consider looking at Apple/NeXT's Enterprise Objects
Framework. I started working on something like this using
metaclasses, and was reasonably successful, but it's a complex
undertaking, and time consuming....


Martijn writes (quoting me):
> > For more modest ambitions, the factors that weigh heavy on me may
> > seem irrelevant or even overweening. :)
> 
> Many people are using Python for rather less modest ambitions,
> however. 
> I'm certainly planning to. :)

And I think that HomeGain is using Python in a pretty significant
application, too. We've got a lot of traffic and a whole bunch of
data. It can work! It just doesn't seem to have all the tools to
facilitate it, and it's not nearly as ubiquitous as other
solutions.

Speaking for myself again,
--G.

----
Geoff Gerrietts <geoff at homegain.com>