Zope & Python

[Martijn Faassen]

Leon Booyens <leon_booyens at xsinet.co.za> wrote:
> I asked one of our specialists if we should not consider using Zope instead
> of tomcat and Python instead of Java.

> His reply was as follows :

> Do you agree with all these comments ?

No, but I agree with the other reply that nothing you say will be able
to change his mind, anyway, unfortunately. What is in there is a lot of
'common wisdom', some of which seems only to be common among people whose
experience is limited to type & bondage languages like Java. 

[snip]

> I have had a look at the "Zope" application server at www.zope.org, and feel
> that it cannot be considered for use (on the server side) in an enterprise
> application because of the following weaknesses:

Note 'enterprise' buzzword. :)

> The business-logic extensions must be written in Python, which is a fine
> "glue language" for whipping up scripts and small applications in as short a
> time and as few lines of code as possible, but is simply not robust enough
> for enterprise applications.

Counterexample would be Smalltalk, which is a dynamically typed language very
much like Python, with a tradition of business applications. Anyway, 
how does he explain Zope itself if Python is simply not robust enough for
'enterprise applications'? Zope's certainly large.

>  For example, it does not allow compile-time
> enforcement of interface specifications, as C++ and Java do.

And only when you have some experience with languages that don't, like
Python or Smalltalk, you learn that compile-time type checking is not the
silver bullet it is often made out to be by the C++/Java camp. 

Compile time interfaces are nice because:
   
   * you check more during compile time, less during run-time

   * your interfaces can be more explicit in the code itself

   * they can allow more optimization

They're not nice because:

   * you have to please the type checker all the time. Either you:
  
      * break type-integrity anyway (Java)

      * pull in rather gruesomely complex templates (C++) (talk about
        the need for programmer discipline!)

   * it slows development time
  
   * you can paint yourself in the corner; your code gets locked down more
     easily in a design you cannot easily get out of anymore, due to the
     types.
 
> a) It does not even support the concept of private, protected and public
> instance variables and methods.

It does support private methods, if you want them:

class Foo:
    def __this_is_private(self):
        self.__this_too = 1

Just prepend your variable name with double underscore. In daily life,
people make do with a single underscore to indicate something is private.
You can then still break encapsulation (but you can in most languages), 
but you take the responsibility.

In Zope there is in fact a system which makes _methods non accessible
through the web.

> The whole concept of "design-by-contract"
> relies on the availability of these features.  You cannot rely on
> programmers to have the discipline to comply with (nonexistent) interface
> specifications.

Which is why you can write down the interface specifications do they are
existent? You can write unit tests for your interfaces? In the Smalltalk
world testing often takes the place of static type checking; in fact
with static types you should still do testing...

Anyway, if we cannot rely on programmers to have discipline, no amount of
language facilities will induce the programmer to have discipline. An
undisciplined programmer can write severely messy Java code, too. Still,
it's true some scaffolding for the programmer can be helpful discipline-wise.

> b) If we develop web applications in accordance with the Java Servlet API,
> we can upgrade the platform from Apache+Tomcat running on Linux to Sun's
> Java Webserver, or IBM Websphere, or BEA Weblogic (BEA is the industry
> leader in OLTP middleware), or any number of other commercial
> implementations.

Upgrading from an open source system to a commercial implementation? 
Anyway, I don't know much about these, but I'll believe this smooth
upgrade path when I see it. :)

>  What is the upgrade path for Zope?

Zope Enterprise Objects for clustering.

> c) Java allows a wide choice of compilers, debugging and profiling tools,
> modelling tools, middleware, and libraries for everything under the sun.  It
> is a mainstream language for commercial applications, with a relatively
> large pool of programming expertise and with support from most major
> industry players (besides Microsoft). Python may be gaining popularity, but
> is way behind Java.

They said this about Cobol too. Anyway, it's a valid argument in a sense,
but this is in my opinion overestimating industry support, and underestimating
open source support. And any amount of tools can't make Java a quicker
development language than Python. :)

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?