[Zope] can zope port to java/dotnet?

Dylan Reinhardt zope@dylanreinhardt.com
Wed, 12 Mar 2003 20:45:47 -0800

At 07:15 PM 3/12/2003, =?gb2312?q?Chen=20Fu?= wrote:
>I like zope for its pure OO framework. is it the only
>work among the CMSs take this design? If it is true,
>why not any other clone in java, c# or cpp?

If people who programmed in c# or java cared about using good tools, they'd 
have switched over to Python by now.  :-)

>I agree Python is a good language, but it faces many
>challenges also like relative slow speed

Python code won't execute as fast as assembler, but you'll finish your 
project a lot faster and have an easier time maintaining it.

>, short of
>programmer(compare with java cpp)

Python is today poised where Linux was about 6-7 years ago... most people 
have barely heard of it and only a few have found out first-hand how 
utterly it eclipses just about everything other choice in a wide range of 
applications.  Six years ago was a great time to be building your 
credentials as a Linux guru... now is a great time to be investing your 
time in Python.

>and short of elite
>programming environment (like MS visual studio).

There are overpriced IDEs for Python too.  :-)  Anyway, 90% of the problems 
solved by IDEs just aren't problems in Python.  Turn on syntax highlighting 
in Vim and you've got pretty much all the environment you could possibly 

>Some articles explain why the zope can't port from
>CPython to JPython. But how about a rebuild in pure
>java/cpp/c#? is it possible and deserved?

A more important question is why you'd bother.  Why waste important 
development time achieving barely any more performance than you might have 
gotten out of a memory upgrade?  Besides, who want to recompile every time 
you upgrade a product?

Evaluating Python (or Zope) for its speed of execution is asking the wrong 
set of questions about this kind of software.  Performance matters *some*, 
but not nearly as much as development cost, maintenance cost, and time to 
market.  If you work in an environment where software gets validated or 
audited, you just can't beat Python for its clarity.  When push comes to 
shove, it's usually a lot easier to get more hardware than more hours of 
good programming talent.

If you want to improve Zope's performance, you can start by delegating 
more.  Proxy aggressively.  Serve all static content (especially images) 
out of Apache.  Do more load balancing.  Upgrade to ZEO.  Once you look at 
the big picture, there are very few situations where tweaking low-level 
code is the most efficient way to conceive of improving 
performance.    Just because Zope *can* serve as an all-in-one tool doesn't 
mean that's the best way to use it.

There are situations where writing the smallest, fastest thing possible is 
critical... most web apps just aren't in that domain.  If you're having 
performance problems in a web app, your time is almost always better spent 
tweaking the graphics than just about anything else.

My $.02,