Zope & Python

[Cameron Laird]

In article <8pt5o3$cbs$1 at newshost.accu.uu.nl>,
Martijn Faassen <m.faassen at vet.uu.nl> wrote:
>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 he's fairly close to the target.  My reaction
to his comments:  "Yes, that's correct; so?"  That is,
while there's valid content to his observations about
Python, I find it all secondary to the Pythonic
advantages (and Java disadvantages) he's neglected.
			.
			.
			.
>> 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.
My reply is somewhat different.  Python is absolutely
suitable for the enterprise.  It need make no apologies.
Bruce Eckel, who has a world-class reputation for his
Java savvy, consistently cites Python for its "scalabil-
ity."  It's the *best* language for the enterprise.

And it's superior to Java *because* it "is a fine 'glue
language'".  Enterprise applications *always* need to
interface to some squirrelly legacy programs which aren't
worth recoding in Java.  This is soooooo much easier in
Python.
>
>>  For example, it does not allow compile-time
>> enforcement of interface specifications, as C++ and Java do.
			.
		[I'll catch up with
		this later.]
			.
			.
>> 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.
I take DbC seriously.  I think Eiffel and Ada have
a lot to recommend them.

I haven't kept up--are the Java DbC systems any 
better than Python's?  They certainly weren't in the
past, but perhaps they've caught up ...
			.
			.
			.
>> 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. :)
Oh, I've seen successful upgrades from open-source to
proprietary.  And vice-versa.  I take the idea seri-
ously.

Does the commentator truly consider, for example, Java
Webserver an upgrade?  What kind of constraints does he
believe that helps relax?  I take scalability and OLTP
very seriously, but the commercial systems cited involve
an awful lot of pain for ... well, what exactly is the
purported gain?  Many of the biggest Web systems in the
world run on AOLServer, Apache, or Roxen--all of which
are open source and rather general purpose.

I repeat:  scalability is indeed important.  The
commercial products above certainly advertise their
scalability benefits.  Which ones do they deliver,
though?
			.
			.
			.
>> 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. :)
Martijn's words are worth repeating.
			.
			.
			.
-- 

Cameron Laird <claird at NeoSoft.com>
Business:  http://www.Phaseit.net
Personal:  http://starbase.neosoft.com/~claird/home.html