Slashdot Mirror

You're only talking about the appearance.

Slashdot runs on Slashcode (http://www.slashcode.com/). If you want to, you can change the appearance of it with skins and whatnot. I would also recommend Drupal (http://www.drupal.org/ and Zope (http://www.zope.org/). Hire somebody to create a nice skin for it, and any one of the above systems should be able to neatly handle the backend work.

I checked some of the RoR tutorials out there a while ago, and found nothing that Zope (http://www.zope.org/ wouldn't do for me in the same or even shorter amount of time (old fashioned DTML here, not ZPT, mind you ;) . Zope has a quite a steep learning curve, but from reading the tutorials I would guess the same goes for RoR, and for now, I'll be sticking to Zope.

Cheers,

Uwe

To me it seems like a silly exercise to replicate rails in python or what have you.

1. TurboGears is not a Rails clone.
2. Most parts of TurboGears existed before Rails: CherryPy, SQLObject, FormEncode (and Python of course).
3. Kid is most closely related to Zope Page Templates (from the Python world), not anything from Rails.
4. MochiKit has a certain relationship to Prototype (the Javascript library from Rails), and is compatible with it. However, it's not that the author particularly likes Prototype.

Rails has taught us some important lessons, but they aren't really technical lessons:

1. We shouldn't sit around and say "oh, those poor people using PHP/Java/etc, too bad they don't know about what you can do using X". Instead we should talk more loudly and insistently about the advantages of our platforms. If you do it right people will pay attention.
2. We haven't concentrated enough on full-stack integration. We've been overvaluing decoupled pick-and-choose components. Full-stack integration doesn't have to mean coupling -- it can just be a matter of presentation, and making sure tools are complimentary. Not all of the Python frameworks are coming at it from this direction, but TurboGears very much is.
3. Things like screencasts are nice.

After looking at various pieces of Rails, these lessons have stood out to me, but the particular technology in Rails has not. Sure, there are some good ideas, but nothing radical, and there's good ideas everywhere waiting to be mined. We're not beneath mining other people's ideas, but it does not follow that the result is merely a "replication" in part or in whole.

As for Ruby: I think the two languages are largely equivalent in terms of what you can do. I would not say the same about PHP or Java. As for Rails specifically, I think it is only ahead of Python options in the second derivative. With conscious players the second derivative doesn't mean a whole lot.

• If you want to concentrate on your object oriented approach, stick to databases that can handle objects, like the ZODB (usable w/o Zope if you like).
• If you have to access mass-data from legacy systems (like e.g. master product data), you have to program SQL, since nothing is faster than that. Make sure the results can be converted into something like a list of dictionaries so handling of the results is more natural in an object oriented manner.
• Every good programmer should be able to switch between programming languages and be able to access data stored in legacy systems as well. Sometimes the data comes only via an ODBC connector from an old AS/400, but if that is the source of the master data, you have to live with it.
• SQL databases are not the primary choice to store objects and/or tree like structures. They were designed it the "good ole' times" when everybody though that relational databases were cool. Sometimes it can be much more useful to store a tree in an object persistent storage and put the node data into an SQL DB (for performance).
• For debugging: If you use SQL code in your project you can actually print out the statements before they get send over to the database so you can simply copy them from your logfile (you have a logfile, do you ?) and run them manually to see if they produce the outcome you want. This is often more useful than enabling query logging on the server since digging through thousands of lines of log-messages can be rather time consuming.
• For designing: You can build your queries step by step in a "Query Analyzer" using some example data and then embed the results into your code (including the exchange of fixed teststring with variable names).
• For performance: You might know that you have to run a query 3000 times in a row with different variables (e.g. insert into ...) but you object mapper does not know that fact. Thus you can use one prepared SQL statement and fill in the variables upon execution. This saves a hell lot of time (depending on your database system, some systems are slow either way).

• If you want to concentrate on your object oriented approach, stick to databases that can handle objects, like the ZODB (usable w/o Zope if you like).
• If you have to access mass-data from legacy systems (like e.g. master product data), you have to program SQL, since nothing is faster than that. Make sure the results can be converted into something like a list of dictionaries so handling of the results is more natural in an object oriented manner.
• Every good programmer should be able to switch between programming languages and be able to access data stored in legacy systems as well. Sometimes the data comes only via an ODBC connector from an old AS/400, but if that is the source of the master data, you have to live with it.
• SQL databases are not the primary choice to store objects and/or tree like structures. They were designed it the "good ole' times" when everybody though that relational databases were cool. Sometimes it can be much more useful to store a tree in an object persistent storage and put the node data into an SQL DB (for performance).
• For debugging: If you use SQL code in your project you can actually print out the statements before they get send over to the database so you can simply copy them from your logfile (you have a logfile, do you ?) and run them manually to see if they produce the outcome you want. This is often more useful than enabling query logging on the server since digging through thousands of lines of log-messages can be rather time consuming.
• For designing: You can build your queries step by step in a "Query Analyzer" using some example data and then embed the results into your code (including the exchange of fixed teststring with variable names).
• For performance: You might know that you have to run a query 3000 times in a row with different variables (e.g. insert into ...) but you object mapper does not know that fact. Thus you can use one prepared SQL statement and fill in the variables upon execution. This saves a hell lot of time (depending on your database system, some systems are slow either way).

What's the big difference between this and http://www.plone.org/ ? Haven't Plone and http://www.zope.org/ providing such framworks for years?

Yes I can read. sh klive.sh --install Twisted is not installed, you can download it from Most Linux distributions ships with a python-twisted package. Download twisted python. Go to install it: bash-3.00$ python setup.py install "you need zope.interface installed you need zope.interface installed http://zope.org/Products/ZopeInterface/ And I'm not installing Zope. From the NEWS.txt of twisted - 2.0.0 (March 25, 2005): Major new features - Replaced home-grown components system with zope.interface. That's just STUPID. And this stupid website won;t let me paste the entire process. Reason: Please use fewer 'junk' characters. POS.

"Okaaaay, so when are you moving your code to Linux? (P.S. you're locked into MS products now)"

In what way? In the way that for some bizarre reason I can't port to another platform in the future if I want to? In the way that MS had some kind of ownership over what I've built and what I can do with it? In the way that they are telling me what I can and can't do in the future? I think you may be confusing lock-in with making a choice. In that way, whatever platform and development language I choose, I will always be 'locked in' according to people who use other products. It's a stupid point to make.

"I call bullshit - since when has .NET been the best tool for the job? Have you not heard of Perl, Ruby, Python and even Java?"

I don't do what I do based on fitting the problem around the solution, I find a solution for a problem. .NET fits in with what I need to do infinitely better than any of the other languages you mention. And this isn't a choice I make based on products being made by specific companies or it being open source, or the cool geek technology buzzword of the month. Ultimately, it's not a choice I make by being a blinkered techie that has no understanding of the peripheral business aspects.

Incidentally, I'd compare .NET to J2EE, rather than Java, and maybe point you towards Pythont for .NET and Perl .NET, both of which allow you to write in both languages for the .NET CLR.

Python is a wonderful language, not only for beginners, but very much for them, too. It is syntactically and conceptually clean and provides libraries to achieve most of what anyone needs - maybe with some additional downloads like wxPython ;-)

Clean, simple, rich, powerful, open source, adaptive to the max, with a huge user community and good documentation.

Python provides a smooth introduction and growth pad into programming and OO.

And if you want to go more advanced try developing component-based web applications with Zope 3

<:import foo:>
<table>
    <:for `foo.Users.getSome()` u:>
        <tr><td><:val `u.username`:></td></tr>
    <:/for:>
</table>

Use a CMS like Plone (built on top of Zope). Its built-in document type can automatically convert input documents in various formats (including MS-Word) into something more web-friendly.

...but where's my perl, python and ruby dot net (and I don't mean editor support)?

Right under your nose, if you bother to look:
http://aspn.activestate.com/ASPN/NET Perl and (experimental)Python
http://www.saltypickle.com/rubydotnet/Ruby/.NET compatability
http://www.zope.org/Members/Brian/PythonNetPython
http://www.ironpython.com/Python, again....

Your assumptions are incorrect and obviously based upon the same buzz words most CIOs use to make erroneous decisions regarding infrastructure.

Our Oracle DB requires special utilities and the care of a DBA to back it up and restore it 'properly'. If our DBA gets run over by a bus we are SOL. You can stop the database and backup all the files involved - but it is an ugly proposition not amenable to automation.

I have many gigabytes worth of data in a ZODB - it is one single file, that I can backup while the system is running, and I can do it easily using existing CLI tools. Restoration is simply bringing down the application, copying the backup file into place, then restart the application - a matter of seconds usually. It is as scalable as a conventional RDBMS without the overhead - and the structures stored in it can be defined on the fly with no table redesigns or other administrative and design overhead that gets in the way of delivering working applications to my customers. Object databases are the future of data storage and obviate the need for an RDBMS.

Additionally, the ZODB has the ability to roll-back all changes made from the last packing of the database. You could also couple it with a version control system (such as CVS) to further provide restorability of individual objects back to 0-day if you really needed that level of recall.

Finally, when you hold up javascript next to python - one looks like a cobbled together mess, and the other is elegant (I'll give you a hint - python is the elegant one). For maintainability and ease of programming (and not having to embed said program into my content) python wins hands down.

For what I do these tools function perfectly and make my job a breeze compared to the hassles I've lived through doing things the old 'standard' way. I've used the other tools with varying success (javascript, perl, RDBMSs, java, ASPDB etc.) - and was able to get more done and lower costs and maintenance overhead using the tools I described. This has nothing to do with 'cool' and everything to do with being effective on the job. Have you tried other things than what is standard operating practice? I don't know about you, but I am always trying to find better ways to do my job.

You might try it before you put it down out of hand.

I still use PHP for a lot of personal work and quick stuff, but I've been leaning more and more on Python, Zope, and Plone for building stuff at my day job. If you need to quickly and easily implement role based security, Zope makes it drop dead easy because it's built in and through ZEO, zope apps can be highly scalable. Of course as with most things, use whatever technologies get the job done. For example, my Zope apps live behind an Apache server that I use for SSL as well as access control.

I still use PHP for a lot of personal work and quick stuff, but I've been leaning more and more on Python, Zope, and Plone for building stuff at my day job. If you need to quickly and easily implement role based security, Zope makes it drop dead easy because it's built in and through ZEO, zope apps can be highly scalable. Of course as with most things, use whatever technologies get the job done. For example, my Zope apps live behind an Apache server that I use for SSL as well as access control.

Python is the way go to. For anyone who's built custom sites based on Zope, I think they would agree with me. Python is really easy to use for building big apps for use in web stuff, and Zope provides an easy-to-code-for application server.

To be honest its the first one that has really impressed me. I looked at slashcode, scoop, zope, plone, postnuke, mambo.

When I started using drupal I got the same feeling as when I started using Mac OS X. To continue the OS analogy postnuke and phpnuke are more like windows whereas zope and plone are kinda linux of the CMS world.

• ClamAV virus definition distribution model (use of incremental updates, dns txt field checks for new updates, automatic, etc..) -- compare this to the weekly (!) updates of Symantec (or manually updating slightly more frequently) or even some of the "download a big chunk from a centralized location" method of commercial competitors.
• BitTorrent
• So many things in KDE its insane.. (just check out all the awards, including Software Innovation of the Year - CeBit!)
• Plone, Zope, Typo3 - These content management systems lead the way for both commercial and opensource.. so much innovation going on here
• CUPS - While not glamerous, I have setup lots of print servers and the flexibility and modularlity of CUPS (in my experience) is unmatched.
• The spam fighters: greylisting, spamassassin, amavisd, postfix, dnsrbl, etc.. developed under or made popular due to opensource.. I have yet to come across _any_ non-FOSS solution that comes close to the success and accuracy of the OSS tools for spam filtering

As for the jokes to your comment, I have them covered allready.

This is not about any particular framework. It's about OSS server technology slowly creeping into everyday webapps and beyond. And Firefox/Mozilla Rich Clients in XUL lurking around the corner. Same goes for Flash stuff like Flex or Breeze. MS is fighting those too with new Products like "Office Live Meeting" and such. In MS much fear I sense about that.

Ajax on the other hand is a new buzzword for an ancient technology that usually is called "Doing neat client side stuff with Javascript". Some type A new economy wiseguy over at AdaptivePath brought it up and wrote an essay on rich clients with the assistance of the official web economy bullshit generator. And now - naturally - MS is picking it up. MS is king when it comes to buzzwords (and bullshit) and since they've got it all set up allready they now have a reason to sell more ASP.Crap servers for 10 Bazillon Dollars each.
That's all it is about.

BTW: If you want to check out a wepapp-juggernaught I'd suggest Zope, aka 'What RoR wants to be when it grows up'.

What Ruby on Rails wants to be when it grows up.

It sounds like a more limited (this is not meant as a criticism) version of acquisition used in Zope. Well obviously zope does have the lockin effect.

I don't know if you know it, maybe you get some ideas.

It sounds like a more limited (this is not meant as a criticism) version of acquisition used in Zope. Well obviously zope does have the lockin effect.

I don't know if you know it, maybe you get some ideas.

They might be overkill for a blog, but if you want a python-based CMS you should look at zope and plone. They are both extremely powerful. Unfortunately a lot of people seem to be put off by the steep learning curve and patchy documentation.

PHP "programmers" have a lot to answer for.

Of course, Zope is no better, but soon should be better.

Honestly, folks, databases are like crutches: Pathetic, but you when you need them, there's hardly an alternative. They are the living proof that abstract concepts and computer simulation of those on real world hardware need the strangest type of hacks to be mended together.

On top of that - and this is the worse part - what we call databases today is nohing much more of a historically grown apocalyptic chaos. With one of the crappiest programming languages ever as a cornerstone of its technology. A weedy mumbojumbo of wanna-be virtual machines, wanna-be server daemons, makeshift security layers, obstrusive user management and pseudo operating systems and a bazillion proprietary variants of said programmin language. With features bolted on left right and center. This basically is the case with any current DB in widespread use, be it MySQL, Oracle or anything inbetween.
And if you look at the core of it Database technology and how long it has been that way there isn't much hope that DB's will go anywhere anytime soon.

Then again, if you want to get a glimpse of a possibly brighter future, I'd actually recomend Zope. I consider it's object relational DB a working proof of avantgarde "database" concepts and a prototype of what DBs generally could look like in the future if anyone were interested.

... or I missed their business model completely.

While I understand that you may base a business on for instance ZOPE, here I have trouble to imagine how they want to earn from whom.

In a comment to a German version of the note (at best), someone thought they would later consult with respect to mass migration from IE to FF. Maybe.

CC.

ROR bites. Try zope instead.

Ah. You went to zope.com.

Go to http://zope.org. You will find nary a drop down menu there.

Zope is a reason there are so many python web frameworks today: people try Zope, think, "there has GOT to be a better way" and create a new framework.

Like Zope3?

I remember when I first heard of Python back in grad school. I wondered what would become of it, but didn't have time to deal with it at the time, after all FORTRAN was teh cool, right? Lately, since I started using Zope, which is written in Python, and more recently Plone, which is built on Zope, I've really gained a great appreciation for Python because it really has made building sophisticated logic for web apps a lot easier than some alternatives. Now admittedly, I did not choose any of these because I heard they were easy or even cool, I stumbled into Zope because of an app, OIO, that I thought I could build on for another project. Later I heard about Plone and decided that I could build an easier to use portal for clinical investigators using that rather than PHP based solutions like PHP-Nuke. Python was just the icing on the cake as I discovered how much I could do with it.

Really, try Zope.
Yes, it's a little bit of a learning courve, but (and I did all of them for a living) it be beats Java/Tomcat/Struts and PHP hands down in productivity/maintainability once you get a grip on it.

Can one use Python to do the same?
Not as a applet.
Where would it play its role? The backend or on client machines?
A little interface script on the server connecting to a database (like PHP does now most of the time.) Or to previde a complete CMS. On the clientside either XUL in Mozilla is still a Toolkit to be discovered or a browserindependant Python-client (Python is well integrated with native Toolkits, for example via wxWindows - used in bittorrent).

It is just sad that it's written i Python. I like Python for scripting, but production software should not be written in dynamically typed scripting languages.
Yeah, we all know scripting languages suffer from buffer overflows and other serious flaws. So sgi, NATO and Viacom and gentoo did it all wrong:
http://www.zope.org/Resources/ZopePowered/
http://www.gentoo.org/proj/en/portage/index.xml
The fact that the use of Python is listed as one of the top features indicates that the programmers behind this project are either immature, untalented, or both.
For what reason?

While I'm not one to cast doubt needlessly on new, different ideas, I must admit that while the Ruby on Rails tutorial was spectacularly simple and fast, the fact is that when I decided to move from toy to trying to implement it, I encountered a number of problems.
First, the database that I hooked this framework to was not empty originally. After hooking the framework to that db, the data disappeared...I should repeat that, my data disappeared without my explicit instruction to destroy the data!.
Second, getting this running on linux was problematic because the tutorial was strictly for Windows and thus missed a few bits about linux (not really the author's fault since he admitted that linux takes more work).
I should be honest and say that after I discovered that RoR was truncating my database every time I tried to use it (without notifying me of that fact), I ran away in horror. I now use Zope and won't go back to RoR.

Plone on top of Zope on top of presumably yet more free software... anyone know what OS it's using and whether or not it's using some type of caching system?

Zope plus Plone - if you are looking for a content management system, or Zwiki if you are looking for a wiki solution, or learn Python and roll your own inside of Zope's Management Interface (ZMI).

Before you know it you will have dynamic content coming out of your ears - and you won't have to muck about with a relational database at all (and the ZODB scales better anyway from my experience).

Zope plus Plone - if you are looking for a content management system, or Zwiki if you are looking for a wiki solution, or learn Python and roll your own inside of Zope's Management Interface (ZMI).

Before you know it you will have dynamic content coming out of your ears - and you won't have to muck about with a relational database at all (and the ZODB scales better anyway from my experience).

except for Python, you're right.

I second this. I'm not a big PHP fan, but the Drupal guys (and its cousin project CivicSpace) were very thoughtful in designing a complete drop-in but very extensible CMS framework. Plone with Archetypes is also a good choice, if you prefer Python (and who wouldn't?), and it tends to iron out a lot of the wrinkly parts of Zope that turn people away.

Zope and Plone is the way to go. These tools are RAD for the web, you'll have to learn them, which is hard, but then I guarantee that you'll save LOTS of time !

This is a troll if I ever saw one. I usually don't respond to trolls, but when they get modded "+4 Insightful", I have to.

Zope is a nice application server, but not exactly fast. It has nice abstractions like acquisition to do very complex web applications with only a few lines of code.

Zope is among the fastest application servers out there, and certainly scales better than any Java-based app server I've seen due to its native support for ZEO (server clustering). Boston.com runs a huge Zope cluster on the back-end, and CBS New York does the same. This is pure FUD.

Plone adds more layers of abstraction and makes the whole even slower. It is almost as if the plone designers read a book about advanced OO concepts and wanted to implement every single concept they just learned about in a single application.

Oh, come on. We haven't added any unnecessary abstractions - we have mostly added glue code to tie together other pieces of Zope and CMF code in a better way, and put a standards-compliant, user-friendly UI on it.

Abstractions are your friend. If you want to know everything about how things work, the Python code is available for you to read. Trust me, you don't want to have to think about every single detail about what's going on underneath the hood at all times.

The goal of Plone is to make things Just Work, and from the feedback we get from our users, we have succeeded in this.

The only way to get decent performance out of a plone/zope setup is to put a squid proxy in front of it, but that causes a lot of problems with dynamic content.

The only way to get decent performance on *any* web-based application server system is to put a cache in front. Apache and Squid work well, and we have giant Plone sites out there with Squid in front and dynamic cache invalidation. And what are the "problems with dynamic content" you are referring to? Both Apache and Squid handle expiry dates for web pages and cache invalidation just fine.

Plone is distributed for development, not deployment. It's common knowledge among all developers that you have to spend some time doing proper caching setups for bigger and more complex sites - but that's the case for every system out there.

The documentation is also horrible. If you are lucky it is just incomplete and out of date, but in most cases there is none at all.

There are three books on it out now, and the best one so far wasn't reviewed here. Andy McKay's book shows you most of what you want to know, is available for free (under a Creative Commons license) online. How is that "horrible"?

If you want to do a small application with less than one hit per second, go ahead. But for a big site: forget it.

It's actually the other way around. If you want to do a small site, Plone's workflow support, schema-based content type definitions, metadata engine, reference support, superior multilingual support and server scalability makes it a tad too complex for small projects, and we usually recommend other systems for people who just want a blog or a forum system.

For bigger organizations like Oxfam America, Credit Muncipal de Paris, Rice University's Connextion project, Clear Channel's racing sites and the USDA Forest Service - you *need* a proper tool to keep the content up-to-date.

Plone is that tool. Take your trolling elsewhere.

Disclaimer: I'm one of Plone's founders, so I'm biased. The claims put forth by the parent poster have nothing to do with reality, though.

Zope doesn't come with SOAP support as standard. There is some work (like the SOAPByCIGNEX module) being done to allow it to be available as an add-on.

There was a recent discussion about it on the Zope-dev mailing list.

Zope doesn't come with SOAP support as standard. There is some work (like the SOAPByCIGNEX module) being done to allow it to be available as an add-on.

There was a recent discussion about it on the Zope-dev mailing list.

http://zope.org/Members/EIONET/SOAPMethod/

I assume you dislike PHP. What would you recommend instead?

Zope

• The reason I'm not taking you seriously is because you don't even seem to be aware of the arguments for and against dynamically types languages. I mean, you havn't even mentioned unit testing yet.

Please. I mentioned unit testing in my first reply, where I wrote:

• The uncertainty involved in the dynamic typing/late binding model of such languages is compensated for through unit testing.

I also linked to an interview with Guido van Rossum where he talks about this very topic, so if you think I'm ignorant of the issues involved, you must be purposely ignoring what I'm writing. Thanks for trolling again.

• This has already happened for languages like Eiffel where verification of object contracts is now automated. These methods are becoming available for Java too.

Sorry, but interface contracts have very little to do with static type checking.

A pre-condition is typically something like whether a value is within a range, or that an argument is not null, or an array has a certain length, or that an instance is of a certain class at runtime; not whether it's an integer or a string.

Design by contract, being unrelated to static type checking, is therefore a concept that is equally applicable to both statically- and dynamically-typed languages, the main difference being that in a dynamically typed language, the checks may only occur at runtime.

There is nothing preventing dynamically typed languages from doing automated type checking. This and this make a good start. The latter is similar to Java 5.0's annotation system.

As for unit tests consisting of type checks, you will probably find that the overlap is larger than you think. Even if a method in Java returns a StringBuffer object, the Java interface can never explain what the contract is: whether it's allowed to return null, whether it always returns a different instance, what that object is supposed to contain.

You will find that in Python, for example, the checks are more or less the same; if the method returned Fnarg instead of the expected object, your test will fail -- unless Fnarg happens to behave like what you wanted, in which case everything is all right. As for input, regardless of the type of language, throwing garbage at functions is always useful; with dynamically typed languages, you might just end up throwing a little more garbage.

Unit tests are supposed to be simple and quick to write. Languages like Python are known to support much more rapid development. Even if you add 20% more checks, you'll still come out on top. Ever worked with lists and maps in Java? They're not first-class objects, so they're a nightmare to manipulate. Such structures are extremely common in tests. (I have been writing Java and Python unit tests every day for four years, so I know where the differences are.)

(As an aside, if in your mention of Eiffel you're referring to design by contract, the concept was invented for Eiffel, so saying it's "now automated" is like saying the Eiffel tower is now made out of steel.)

• Every single language you've mentioned there are NOT maintainable. Why? Cause they're all interpreted dynamic languages. It's fun and all to write in these languages and get stuff done with them but as soon as you spot a bug you have a hell of a time to ... blah blah ... not suitable for production systems.

This is a myth, and has been proven false countless of times, such as by these guys, or these guys, or even these guys, or, God forbid, you may have heard of these guys.

First, the term "interpreted dynamic language" is vague and misleading. Interpretation has nothing to do with code maintainability. (You can interpret C, and you can compile putatively interpreted languages such as Java and Python to native code; indeed Java has been natively compiled for years, and the fact that it is just-in-time compilation is irrelevant).

And what does "dynamic" mean? Do you mean a dynamically, as opposed to statically, typed language? Do you mean runtime introspection? Self-modification and metaprogramming? Runtime name resolution? What? I suspect you mean a combination of these. Python, Perl, Ruby, JavaScript, PHP, Haskell, Lisp and OCaml have these features. C++ can be considered a "dynamic" language, as can Java, C#, etc. So why do you claim that these languages are not maintainable?

These newfangled languages are more rapid to develop in than lower-level languages. Maintenance is simpler because the languages are simpler, higher-level and more easily maintained. For example, the absence of a separate compile/link cycle means I can get from changing a source line to testing the source line quicker.

In many cases, reproducing or debugging a bug is simpler in, say, Python than in C, because the infrastructure itself is simpler. Pure Python, for example, does not have memory access violation errors; there's no way your Python code can read or write an invalid pointer, write beyond the end of a buffer and so on; a whole class of pointer errors, most of which have security repercussions, are annihilated by this feature. Similarly, Python uses exceptions, so nobody can forget to check and propagate a function's error return value.

More often than not, errors that surface in these languages are high-level problems, which is good, because those are simpler than the ones involving someone forgetting to call free() on an allocated buffer or accounting for overflow when shifting a bit mask.

The uncertainty involved in the dynamic typing/late binding model of such languages is compensated for through unit testing.

Oh, and JavaScript, a "dynamic language", is being used by Google in a production system, and Google is known to use Python and Ruby in their systems. I suggest you call them up and tell them their languages aren't suitable.

You would use Zope as a dumb, albeit journaled and transactional, file storage, though the files themselves will be stored in an opaque (object database) format; in other words, the only way to access the files will be through WebDAV (or FTP, which Zope also supports).

Zope is written in Python, so you avoid the PHP stack and its evils. Unlike PHP, Zope is designed around object-oriented concepts such as encapsulation.

For example, to interface with a database you typically create (again, through the web) a connection object, then an SQL method describing the data (a pure SQL script with a few special HTML-like tags for specifying parameter slots) and finally a page template which calls the method.

The upshot? You just decoupled the data from the presentation in a very elegant way, and you decoupled the data operators from the data source. Abstraction is the key.

Plone, in turn, abstracts much of Zope away to provide an elegant, extensible GUI for managing user-oriented content. It has a workflow system, a component system, WYSIWYG article editor support etc.

(The workflow system allows complex flows such as "both John and Jane must review and accept the article before it can be published, and after they've reviewed it, spelling wizard Bob must look over it before it for typos; but users Jack and Jill are trusted users who don't require John or Jane's approval to post articles.)

Unlike most other CMSes, Plone/Zope have no external dependencies -- no MySQL needed, for example.

And Zope supports PHP and Perl scripting