Ray <[EMAIL PROTECTED]> wrote: > Damjan wrote: > > BTW I'd choose TurboGears for it's flexibility, but I guess Django could be > > nice when more rapid results are needed (and the problem doesn't fall too > > far from the Django sweet spot). > > Well actually I was thinking of exaclty the same thing, because our > apps are mostly CRUD apps anyway. However I just learned of one very > big killer--lack of support for Oracle and MS SQL Server. That pretty > much shoots Django down from the list, and with it Python.
According to <http://wiki.rubyonrails.com/rails/pages/Framework+Performance>, with Rails...: """ When connecting rails to Oracle the performance dropped to the extent it made any production use of the product useless. ... Oracle. I would bet performance degrades dramatically when Rails connects to Oracle as Rails does not use Bind Variables or cache prepared statements. Not using bind variables in Oracle is the single most common mistake. When running the load test connected to Oracle, does Oracle consume a lot of the CPU? Its unfortunate, as until Rails handles Oracle correctly, its not really fit to be used on it, and I was really hoping to use it there! """ IOW, if these comments are correct, Rails is also _practically_ unusable with Oracle. Meanwhile, Django has experimental Oracle support with a patch (<http://code.djangoproject.com/ticket/1990>, latest checkin is from Jul 31, but it has been around for over a year in some form or other). As to what will mature first, Rails/Oracle performance or the Django/Oracle patch, who knows. I suspect it won't matter much, because "buzz" trumps substance (in the short run, at least), and Ruby on Rails has buzz (according to Tim O'Reilly's reports at OSCON last week, sales of Ruby books have overtaken sales of Perl books recently -- Python books, while gaining relative to Perl, are still below). The one big issue that may preserve Perl, Python and PHP against Ruby's onslaught is -- acronyms. Any of the "P" languages can acronymically be part of a "LAMP" setup, one of the coolest acronyms in years; indeed, BSD, PostgreSQL and lighttpd may already have been handicapped by the un-coolness of acronyms such as BLPP. But Ruby suffers even worse here, since somebody using Ruby instead of a P-language would be a... LAMR!!! If I were on the board of the Ruby equivalent of the PSF, I'd be lobbying hard for the language's name to be changed to PRuby -- with the P being mute, as in Wodehouse's character Psmith. _That_ would remove the acronymical barrier and ensure PRuby's triumph. Alex -- http://mail.python.org/mailman/listinfo/python-list