I'm working on a project for which Zope seems appropriate. However, an outside consultant for our client claims that the major problem with Zope is that it requires Python, and Python is much less stable than something like Perl. I haven't used Zope or Python enough to have counterarguments to this comment. I don't know specifically what stability issues this person may be referring to, but I would like to ask for feedback on this persons comment. Thanks. James W. Howe mailto:jwh@allencreek.com Allen Creek Software, Inc. pgpkey: http://ic.net/~jwh/pgpkey.html Ann Arbor, MI 48103
I have never seen the Python interpreter crash in any way, nor have I heard of it doing so. I havent seen this, but my partner tells me he as seen the Perl interpreter crash. I have seen the Java JVM crash many many times. Some of my Python code has been running 24/7 for the last 18 months. I would say that, as languages or interpreters, Python and Perl are equally and extremely stable. As tools for developing software, Python's object oriented foundation is conducive to the building of more stable _systems_ that Perl. This could be because of the language itself, or because of the programmers it attracts. Most of the Perl programmers I have met are, frankly, obscuritan mess-heads. The concept of structured programming is somewhat anathema to the Perl programmer. I looked over the shoulder of one Perl programmer we had hired, who was having trouble with a database import problem for several weeks. This Perl programmer had written 6 pages of perl code without actually using _any_ indentation. The program was full of nested loops and she was having a difficult time debugging her code. Without knowing any Perl, I cleaned up the indentation, fixed a few glaring problems, and handed it back to her. She had the problem solved at the end of the day. It comes down to this: It is hard to write a program in Python that another Python programmer (or the same programer several months later) wont understand. It is easy to write a program in Perl that another Perl programmer wont understand. As for the outside consultant. Ask them what makes them feel that Python is less stable than Perl, and what exactly that means.
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of James W. Howe Sent: Thursday, March 09, 2000 9:54 AM To: zope@zope.org Subject: [Zope] Zope Stability Question
I'm working on a project for which Zope seems appropriate. However, an outside consultant for our client claims that the major problem with Zope is that it requires Python, and Python is much less stable than something like Perl. I haven't used Zope or Python enough to have counterarguments to this comment. I don't know specifically what stability issues this person may be referring to, but I would like to ask for feedback on this persons comment.
Thanks.
James W. Howe mailto:jwh@allencreek.com Allen Creek Software, Inc. pgpkey: http://ic.net/~jwh/pgpkey.html Ann Arbor, MI 48103
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Hey James, Just in my experience I have never had a problem with the stability of either Python or Zope. I have set them both up on multiple servers (RH 6.0, 6.1) and been pounding away at them for months now. Python 1.5.2 has been out of awhile (a year?) and Zope releases are certainly stable. In fact, having been using Python for web CGI scripting for 4 years now I have never had a problem with the stability of it as a language (run it on NT, Mac, Linux and Solaris boxes). I usually just build it and let it leave it, never needing to look back till I am ready to update it. JMA
I'm working on a project for which Zope seems appropriate. However, an outside consultant for our client claims that the major problem with Zope is that it requires Python, and Python is much less stable than something like Perl. I haven't used Zope or Python enough to have counterarguments to this comment. I don't know specifically what stability issues this person may be referring to, but I would like to ask for feedback on this persons comment.
On Thu, 9 Mar 2000, James W. Howe wrote:
I'm working on a project for which Zope seems appropriate. However, an outside consultant for our client claims that the major problem with Zope is that it requires Python, and Python is much less stable than something like Perl. I haven't used Zope or Python enough to have counterarguments
I think you are safe in classifying this statement as FUD. I've been using Python (outside of Zope) for five years. I even had a non-trivial accounting system that my business depended on running in Python. A bad design decision on my part led to some real problems with memory size and CPU use of the resulting program, but Python never crashed no matter how much data I tried to shoehorn into my badly designed system. Python is rock solid. --RDM
The testamonials continue... I wrote a perl app a few years ago for a customer, about 10,000 lines. It produces a book in postscript from a database of info. They run it once a week. It crashed at random. After 6 months, I couldn't read my own code, comments or not. I ended up rewriting in Python and it has run without a hitch for about 2 years AND I can still read and understand the code. I hesitate to write a thing in perl anymore, and if I am forced to, won't support it. I've had Zope and numerous other programs in Python running without one crash EVER! Believe it! cheers jim "James W. Howe" wrote:
I'm working on a project for which Zope seems appropriate. However, an outside consultant for our client claims that the major problem with Zope is that it requires Python, and Python is much less stable than something like Perl. I haven't used Zope or Python enough to have counterarguments to this comment. I don't know specifically what stability issues this person may be referring to, but I would like to ask for feedback on this persons comment.
Thanks.
James W. Howe mailto:jwh@allencreek.com Allen Creek Software, Inc. pgpkey: http://ic.net/~jwh/pgpkey.html Ann Arbor, MI 48103
-- The two most common elements in the universe are hydrogen and stupidity.
In article <38C7D8EF.E8E2BA4E@kw.igs.net>, JB <jimbag@kw.igs.net> wrote:
forced to, won't support it. I've had Zope and numerous other programs in Python running without one crash EVER! Believe it!
You *can* actually get Python to crash if you're intentionally mean to it. All the ways I know of involve tricking it into blowing the C stack, like: class C: pass C.__init__ = C; C() Not that you could expect that construct to do anything useful anyway; you wouldn't ever see code like that in an application. You have to go out of your way doing really bizarre stuff get it to crash. It's very stable otherwise. :-)
On 9 Mar 2000, Ty Sarna wrote:
In article <38C7D8EF.E8E2BA4E@kw.igs.net>, JB <jimbag@kw.igs.net> wrote:
forced to, won't support it. I've had Zope and numerous other programs in Python running without one crash EVER! Believe it!
You *can* actually get Python to crash if you're intentionally mean to it. All the ways I know of involve tricking it into blowing the C stack, like:
class C: pass
C.__init__ = C; C()
Not that you could expect that construct to do anything useful anyway; you wouldn't ever see code like that in an application.
You have to go out of your way doing really bizarre stuff get it to crash. It's very stable otherwise. :-)
I don't think you need to really get out of your way to crash python. For someone discovering __getattr__ for the first time and wanting to do some simple delegation ... class A: def __init__(self): self.a=[] def __getattr__(self,key): if hasattr(self.a,key): return getattr(self.a,key) else: return getattr(self,key) Wrong but not really bizzare IMO Pavlos
"James W. Howe" wrote:
I'm working on a project for which Zope seems appropriate. However, an outside consultant for our client claims that the major problem with Zope is that it requires Python, and Python is much less stable than something like Perl.
Yeah, and blue people are dumber than green people and orange people are communists. Without even a whim of data (and there is none) this is just straight up ignorance.
I haven't used Zope or Python enough to have counterarguments to this comment.
The perfect counter argument is. "Prove it." If this person asks *you* to prove it, show them the Lawrence Livermore National Labs, the mems-exchange (all multi-million $+ scientific establishments), Jon Udell articles, etc etc. There is a mountain of evidence on your side and nothing on his/hers.
I don't know specifically what stability issues this person may be referring to, but I would like to ask for feedback on this persons comment.
Thanks.
James W. Howe mailto:jwh@allencreek.com Allen Creek Software, Inc. pgpkey: http://ic.net/~jwh/pgpkey.html Ann Arbor, MI 48103
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
At 12:30 PM 3/9/00 -0800, Michel Pelletier wrote:
"James W. Howe" wrote:
I'm working on a project for which Zope seems appropriate. However, an outside consultant for our client claims that the major problem with Zope is that it requires Python, and Python is much less stable than something like Perl.
[...]
I haven't used Zope or Python enough to have counterarguments to this comment.
The perfect counter argument is. "Prove it." If this person asks *you* to prove it, show them the Lawrence Livermore National Labs, the mems-exchange (all multi-million $+ scientific establishments), Jon Udell articles, etc etc. There is a mountain of evidence on your side and nothing on his/hers.
Do you have specific URL's you could point me at for these items. Thanks! James W. Howe mailto:jwh@allencreek.com Allen Creek Software, Inc. pgpkey: http://ic.net/~jwh/pgpkey.html Ann Arbor, MI 48103
"James W. Howe" wrote:
At 12:30 PM 3/9/00 -0800, Michel Pelletier wrote:
"James W. Howe" wrote:
I'm working on a project for which Zope seems appropriate. However, an outside consultant for our client claims that the major problem with Zope is that it requires Python, and Python is much less stable than something like Perl.
[...]
I haven't used Zope or Python enough to have counterarguments to this comment.
The perfect counter argument is. "Prove it." If this person asks *you* to prove it, show them the Lawrence Livermore National Labs, the mems-exchange (all multi-million $+ scientific establishments), Jon Udell articles, etc etc. There is a mountain of evidence on your side and nothing on his/hers.
Do you have specific URL's you could point me at for these items.
I know mems-exchange.org, LLNL can be found from google, they use python extensivly. Jon Udell articles can be read from his page, udell.roninhouse.com -Michel
Thanks!
James W. Howe mailto:jwh@allencreek.com Allen Creek Software, Inc. pgpkey: http://ic.net/~jwh/pgpkey.html Ann Arbor, MI 48103
On 09 March 2000, James W. Howe said:
The perfect counter argument is. "Prove it." If this person asks *you* to prove it, show them the Lawrence Livermore National Labs, the mems-exchange (all multi-million $+ scientific establishments), Jon Udell articles, etc etc. There is a mountain of evidence on your side and nothing on his/hers.
Do you have specific URL's you could point me at for these items.
My main achievement with Zope is part of the MEMS Exchange mentioned by Michel: http://www.mems-exchange.org/z/process/builder/ This is a tool for people to specify the process sequence to fabricate a MEMS device (= micro-electro-mechanical system, aka micromachine or microsystem). They're typically fabricated using the same techniques as IC fab, but in much more varied ways -- hence the need for people to specify custom fabrication sequences. For non-specialists, most of this tool is meaningless, but it's an interesting demo of how much user interface you can get away with on the web using something like Zope. For the record, before we started playing with Zope, I was convinced that complex user interfaces on the web were all-but-impossible. Thanks to Zope, I now believe that complex user interfaces on the web are merely very difficult. We have found no bugs in Python developing this system; we certainly have our share of gripes with Zope, but I think we've only seen two bugs that really affected the reliability of our web site. The first bug was when Zope 2.1 came out, and we made the mistake of going straight from a single-threaded, PCGI, Zope 2.0 installation to multi-threaded, FastCGI, Zope 2.1; things got really flaky. I think we're now running single-threaded, PCGI, Zope 2.1.4 and things are peachy. We really need to step gingerly back into multi-threaded/FastCGI territory to see how it behaves. The other bug was a nasty ref-counting problem deep in the bowels of mxODBC, so can't really be blamed on Zope. Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
I would like to that all of you who responded to my question concerning Zope/Python stability. It turns out that this information won't be helpful for this project (the 'consultant' is probably going to go a different direction), but hopefully I can use this information to overcome objections on future projects. Thanks again. James W. Howe mailto:jwh@allencreek.com Allen Creek Software, Inc. pgpkey: http://ic.net/~jwh/pgpkey.html Ann Arbor, MI 48103
participants (9)
-
Greg Ward -
J. Atwood -
James W. Howe -
JB -
Michel Pelletier -
morton＠dennisinter.com -
Pavlos Christoforou -
R. David Murray -
tsarna＠endicor.com