Greg Wilson has grumbled about the lack of a Python response to Ruby on Rails before, and I didn't find his arguments compelling then either. Ruby on Rails was the right tool at the right time--at least a good tool. It didn't become popular because a committee or dictator decided it would be popular. It became popular because people liked it. You can't decide to make a specific Python tool popular by fiat.
I've read a few good blog posts on the subject. Christopher Lenz makes some credible criticisms of Django. The problems he describe sound like the sorts of problems that Zope ran into years ago. Using Python as your configuration language? Yikes. (Almost was bad as using ZCML <0.5>.) Speaking of Zope, cguardia asks why Zope doesn't count in Greg's list of web frameworks. Ian Bicking has a better explanation of the problem.
Ian's comment on Greg's blog: Getting a good story together for new users is important. That story probably should not start with “analyzing what framework is best for you.”Regardless of who the winner is or why you would care, the Django team should make sure it understands the lessons Zope did learn about de-coupling components, configuration, and separating policy and mechanism. Update: Adrian Holovaty address my concerns in one of the comments. They make not like Zope's solutions to these problems, but Lenz's post made me wonder if they appreciated the problems yet.
Posts
11 comments:
One word: Momentum.
Pythoneers for as strong and as dedicated group we are, we are fractured... Over 10 years since 1991 and we still aren't as well know or adopted as Perl.
I say from an outside view NOT chosing ONE solid framework makes the Python movement un-sure of itself and un-marketable.
Internally, bickering about implementations is fine (who's got the biggest... um... wheel of cheese...) But for _the_ world facing view, something where outsiders are looking in, this view of ambiguity in frameworks is completely unacceptable Jeremy.
If you use Python as your configuration language, you've got no way to check that your configuration is correct without running it. In every distributed system that uses Python config files, this has been a problem. You push a config change out to a bunch of machines only to discover some oddball error that causes it to fail.
Is this view of ambiguity in frameworks acceptable in C, C++, Java, PHP, or Perl? There are multiple frameworks for all of these languages. Why does a programming language have to have one web framework? (Maybe we should require them of operating systems.)
Jeremy: Rest assured that we Django developers are keenly interested in decoupling components. Keeping things decoupled has been a design concern from Day One, years before Django was even open-sourced. The core components *are* decoupled -- Django is just a collection of components nicely packaged together. It's all about the packaging! Christopher Lenz's comments were exaggerated in places.
It's only "shortcut" functionality, which is purely optional, that makes assumptions about one or more components being used. Frankly, I'm wary of overengineering things so that every single bit of "convenience" functionality would be able to be plugged into any other bit of code. At some point, you've gotta decide that glue is glue. At some point, you've gotta decide that an 85% solution is good enough. Diminishing returns, and all that. (In a reference to the Django tagline: Yes, we're perfectionists, but we have deadlines.)
There's a difference between decoupling and overengineering. I think we've struck a pretty good balance between the two. But, of course, we're not perfect, and I personally would like to see us, among other things, make the small changes necessary to be able to distribute Django's pieces separately. This is something we've wanted to do for a long time -- it's just a matter of finding the time and resources. Stay tuned.
Also, regarding Python config files: If you're worried about incorrect configuration, just write your configuration in INI format -- or whichever non-Python format you prefer -- and use your "real" Django settings file to parse that.
I don't think Python syntax for configuration files is so bad. Using a module for configuration isn't good, and I think that's more of the problem for Django. The other danger to a config file is you enable people to put in funny environmental dependencies.
Personally I'm -0 on Python config files, and took them out of Paste in favor of crufty .ini files (and I think that was a good choice, ini's lameness can be a feature at times), but I can understand why someone would go the other way as well.
There was a recent project (and maybe past projects as well) that read Python-like files, but did so statically -- i.e., executing no code, but having the ability to express any Python literal. Maybe Cerealizer? -- anyway, I think that would be a good compromise.
I don't see where having to execute your config file is any less stress than having one that is a simpler format. Really all you're doing is exchanging a full-featured language for a simpler one -- and while this can be a feature, in my experience any software project of significant size quickly outgrows the limitations of say the .ini file format.
As for error checking, it's still possible to make an error in a "flat text" config file that goes undetected. Ah, but you say it's easy to write an INI checker that validates that your config file is correct? Well, you can do that with a python-based config file . . . in fact, you could use unittest.
PHP is a good point. There is no dominant PHP framework yet it is one of the most pervasive web application platforms to date.
Second of all - the Python community can debate internally forever and respond to Rails all we want but your tax dollars are not being spent on developing applications with Django and Ruby on Rails. The U.S. government and their contractors are spending hundreds of thousands of dollars on Plone/Zope applications and training.
These agencies include NOAA, the Navy, and NASA. And that's just in the U.S. and doesn't includE the private sector:
http://plone.org/about/sites
Do any of the other frameworks in question have those kinds of proven case studies?
And if Django is the chosen framework as an answer to Rails and the Python Web Shootout then shouldn't it support Oracle and/or SQL Server?
I'm not sure how Adrian can say that Django is decoupled. Lenz does a good job explaining why Django is *not* decoupled despite the repeated proclomation of Django dev's. If it's so decoupled, why does so much stuff break and stop working as soon as you use a different ORM?
If its so decoupled, how come its considered impossible or way too hard to make Django compatible with other ORM's?
I'm inclined to agree with the Zope/Plone people though, if developers are looking to choose "the" Python framework, Zope/Plone have been around the longest, have a huge audience, have multiple books written on both, large lists of people using the product, the support of multiple companies, etc.
Is Zope/Plone perfect? Nope, plenty of people have horror stories, just like we see with any other framework. The Django folk say, "Drop what you're doing, help us make Django better." Why? Why don't they help make Zope 3 better?
I know they have their reasons, but it'd be great if there was some consistency in what they say, and what they do.
could you perhaps describe your problems with django-modularity in more details?
as Adrian mentioned, Lenz's comments very often exaggerated.
for some reason, the favourite example of why-django-is-monolithic is the ORM.
please understand that you _can_easily_use_a_different_ORM_in_django.
for example, you could use ZODB, and still use django's url-mapper, django's templating system for example. i call this modular.
yes, it's true that django ships with several "applications", one of them being the admin, which depend on the django-orm.
so, at the end, the question is what do you call django and what not.
the django 'core' is modular.
the applications written using django usually depend on what they use.
so, if there is something in django that's too 'coupled' in your opinion, please tell us which part.
Gábor: If features like the admin interface are dismissed as mere bundled applications rather than part of the core system, then what's left of Django after you exclude the 'bundled apps' isn't very exciting.
Michael: hmm.. could you then tell me how do you think it should be? like to have an universal admin-part working with any 'database mapper'?
if you don't depend on a specific database mapper, how can you do any admin-stuff? after all, you could use an object-db or a xml-db with django, which have completely different semantics than a usual object-to-sql mapper. how should all those be modifiable from a single app?
Post a Comment