Re: [Zope] ArsDigita .. request for comments
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. 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. 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. -- 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"
"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"
On 6 Mar, Andrew M. Kuchling wrote:
Your development technology doesn't matter.
Despite your following (very good) points, this is not true. It leads to conclusions like "Perl is just as readable as Python", "Let's just use C, it can be made as portable as Java", "We should use Lisp for this 3D first-person shooter, we just need a better algorythm than previous C implementations." A better way to phrase this is: Your development technology is only one piece in a larger puzzle. I've recently switched a rather large project from Java to Python -- throwing out nearly 2 years of work in the process -- and I have noticed an immediate increase in development speed. Changing development technologies was a GREAT idea; but only because it was considered within the framework of the developers we had, the skills they had, and the relative advantages of both frameworks. The project had a high dependence on lists and hashes. Changing to python increased performance (all these data-types are native in C, in python; profiling our code shows that it spends most of its time inside java.util.Hashtable), scalability (Java has lots of hard limits; a max of a few thousand interned strings, 32M of RAM per process unless you start diddling command-line arguments, and GC gets unbelievably slow if you do that), reliability (the JVM on Linux is buggy; python is pretty robust if you're not using any crazy native modules ^_^), and last but not least, we get the source to our tools so we can improve them ourselves.
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.
Certainly, nothing is a magic bullet or a panacea that will make all your development problems go away, and I doubt that anyone reading this list believes that. Coincidentally, if you are, and you do, I have a GREAT WAY to MAKE MONEY FAST with NO INVESTMENT!!! It is NOT MLM!! ;-)
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.
This is a great point. Considering the technology within a coherent whole is EXTREMELY important, and the view of some managers that something is just going to be a panacea that resolves everything is depressing. It's not limited to development technologies though -- it's "employee empowerment", it's "diversity training", "thinking out of the box"... bad management transcends the boundaries of space and time =)
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.
In my experience (I admittedly haven't read this particular article) Greenspun's advocacy of Oracle and WebDB is near-rabid and biased toward extremely high-end applications for people with lots and lots of money. What you're referring to as "re-invent"ing, by the way, is referred to by some as 'innovation'. However, I will agree that the time to do that is not necessarily when a large project is nearing a deadline... Finally, I think Zope is a great tool, and for some applications (making a Slashdot clone, for example) it DOES have the kind of killer advantage that can make it worthwhile to switch lots of work in another system to. It all depends on what's appropriate though -- if, for example, your site needs to have access to AdaBase, I don't know if Zope is the best way to go. I have actually seen projects for which CGIs written in C++ were unquestionably the best choice. Examples like that are rare, but they do exist. -- ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/
participants (3)
-
Andrew M. Kuchling -
glyphï¼ twistedmatrix.com -
Jimmie Houchin