"Andrew M. Kuchling" wrote:
Jimmie Houchin writes:
So to scale with Philip you develop with AOLserver/Tcl/ACS, buy big, expensive hardware, buy big expensive database. ie: throw lots of money.
Actually, that isn't quite the point. He isn't actually arguing for AOLserver's superiority over every other system, and somewhere (but I can't find exactly where) he suggests instead:
Your development technology doesn't matter.
This is true, he doesn't necessarily argue for the superiority of AOLserver vs. the world, and that is not what I said either. However, he strongly advocates for AOLserver, which is fine it is good work. But he and others who follow have also advocated against extending AOLserver for tools other than Tcl/ACS. He says, after all, what for? Jimmie>> Start off with a highly scalable, multi-threaded, high quality webserver Jimmie>> with an embedded scripting interpreter. In his case AOLserver with Tcl.
I wish more managers knew this. You can build interesting applications in Zope. You can build them using Java servlets, or CGI, or WebObjects. No tool is going to magically solve all your problems, and solving them will require familiarity with your tools, hard work and careful effort, no matter what you use.
This is true, but it isn't wrong to want to do your job with a tool you enjoy. In the event that there are multiple qualifying ways of doing a job within reasonable means of quality, I think a tool you like and enjoy would potentially help and enable productivity. There is not necessarily any magically programming language or tool. However, some are better than others. Programming well, requires effort and work.
We had a manager here who was quite enamored of Java, and early on we wrote some stuff in Java servlets. He viewed our Zope work as just stopgaps on the way to Java code that would carry us into the long-term, but every time I asked "What problem would be solved by rewriting all our Python code into Java?", there was no clear answer. Unfortunately, far too many people in business computing follow a similar management-by-white-paper-and-press-release style.
Similarly, Greenspun argues that you shouldn't re-invent databases; it would require a tremendous amount of work to add to your home-grown system all the features that existing databases have -- fancy query optimization; storage across several devices; on-line backups; federated operation; etc... So use an existing system; Greenspun's preference is Oracle, but he doesn't argue it like a law of nature.
Because something requires effort, even tremendous effort doesn't mean it isn't worth it. Because something may duplicate features of another product doesn't mean it isn't worth it. Linux did all of this. Tremendous work and effort to somewhat duplicate available software. At some point the efforts which could be perceived as a duplication of existing software may at some point supplant and exceed the currently available existing systems. Subsequent versions of many existing software packages can also fall into this same description of tremendous effort, to duplicate the features of existing software. But this is generally for a reason. Some times to improve certain things, performance, add features, interoperability, portability, etc. I'm sure Oracle has done this. I'm sure Philip has. In his forum and other writings Philip has openly argued against most any potential competing database to Oracle. In his argument he believe the price of Oracle isn't/shouldn't be a problem. However, to many people it is. Even though his webserver of choice is db agnostic, his software ACS isn't. It is very much hardwired to Oracle. Talk to the people involved in the ACS port to PostgreSQL. Any advancement of technology will come at a price of tremendous effort and duplication of current capabilities and features. Sometime it's worth it, sometimes not. Philip is right on many of his points. How much has software really advanced from the capabilities in Lisp from so many years ago? Very debatable. As I said his book is a very good read, great material. I like many of the business ideas and practices of ArsDigita. I have populated my library with many of his book suggestions. I have absolutely nothing against Philip, ArsDigita, AOLserver, ACS, Tcl, etc. AOLserver/ACS is a great tool and toolset. However, in the discussion of comparing AOLserver/ACS (really ACS) to Zope it basically boils down not as much to features but to design/architecture of each tool and scalability. Some people will prefer the ACS way over the very OO way of Zope, some the opposite. If you are agnostic on such, then scalability may become an issue. AOLserver/ACS and Zope scale differently. Philip has a distinct view scalability. Farms, clusters, no. Single machine, multi-processor, yes. Database == Oracle (his other uses were also big $$$dollars). Hence scalability == $$$dollars. AOLserver/ACS currently scales better than Zope. Zope may not currently be the best choice, or a choice, for Amazon, Ebay, etc. But I think it can someday. Because Zope is reasonably db agnostic (it does like transactions), it may be a better solution for many people than ACS since it is tightly linked to Oracle. If your money and data is somewhere else you would have to port. In their forum I made comments that it would be great if ACS were decoupled from it's specific database dependency. The db connectivity could be abstracted and an appropriate database api could be created. This would enable other database users to use ACS. No interest from ArsDigita. Instead there are various peoples rewriting ACS for their db of choice. As far as I know all hardwired. :( There is definitely room for both to be successful, and others like Enhydra. Then there would quality choices for users of various backgrounds and personal preferences. There is most definitely a give and take among the choices out there for languages, webservers, app servers, etc. As for me, when surveying the landscape from my world view and perspective, the other options primarily potentially beat Zope "currently" in scalability/performance. But for me Zope won other areas. I like Zope, I like ZODB. If I don't have to use an RDBMS, I won't. However, I do hope for ZODB to improve to the robustness and scalability of the RDBMSes. For some uses it is. As I read the paper today and see 1 ghz Athlon machines becoming available, Zope horizons are looking better. Go Moore go. :) Jimmie Houchin
-- A.M. Kuchling http://starship.python.net/crew/amk/ One has no wish to be devoured by alien monstrosities, even in the cause of political progress. -- One of the Tribunal, in "Carnival of Monsters"