Jon Udell has a piece in the latest Infoworld cites the recent series of interviews with Guido van Rossum by Bill Venners. Jon talks briefly about the pre-J2EE days when it was generally speculated that most Java servers would be prototypes in portable code, and then compiled to native code. This apparently has not happened, and Java application servers continue to run happily in the JVM.
Of course you dare not build the application server itself in a high-level language like Python. Not, that is, unless you're a quiet revolutionary like Zope Corporation's Jim Fulton, architect of the Python-based Zope application server. [Udell, Jon. "Shipping The Prototype", Infoworld 06 Feb 2002. 07 Feb 2002.]
I'm in the process of wrapping up an intense little customer project - that is on schedule - done in Zope. The project is interesting because we took a different route to development than usual. Many of the custom Zope applications that my team develops are SQL backed, and are fairly analogous to many PHP sites: scripts and templates and SQL code making up the bulk of the application. This time, however, we've done entirely custom business objects written in Python and stored in Zope's object database. As I mentioned recently, this is sometimes a tricky venture in Zope 2. But it's paid off. We're on schedule, and this includes responding to a fairly significant change request from the customer at our first milestone meeting. I expected this change to push the deliverable date for the project back a couple of days, but the architecture absorbed the changes (fairly) easily.
An interesting bit from this project is that we need to store some fairly flat data in order to accommodate these changes. My boss kept saying "Oh, we'll just stick it in Gadfly [a simple pure-python relational database] or something." Instead, I made the decision to use BTrees, and represented the data needed as small Persistent Python objects; to speed up the requisite queries, I added a couple of BTrees to act as indexes. My boss's (valid) concern is that an object database like the ZODB just doesn't have the same memory and write optimizations as most relational databases. I'm hoping this project will give us better footing to do more pure Python Business Object based development in the future (where it fits the bill) as we start to look ahead to Zope 3.
Considering the architectural implementation, the requirements, the short time frame, and the very large possibility for expansion if the project in question actually gets used, I could not imagine doing what I just did in anything but Python, and with any application server but Zope. Fundamentally, I could have gone with the servlet based WebWare and delivered the same business objects, but I would have been on my own when it came to persistence, security, and user management.
Jon Udell says "the classic phased life cycle of software development -- design/develop/test/deploy -- is dissolving into a continuous process." While the mode of development (at least, on project's that I maintain) vary from project to project, it's quite something to be able to show a milestone release instead of a prototype and be able to respond to changes in a timely manner; instead of showing the prototype, getting feedback, and using that feedback to make the "real project". In the last six years, especially, I have never seen one "throw-away prototype" (encouraged by some development processes) actually get thrown away.