Related link: http://www.djangoproject.com/snakesandrubies/
Snakes and Rubies was a meeting held in December to allow developers from the Ruby on Rails and Django projects to present their respective projects and discuss them in an open forum.
If you’ve been reading some of my posts recently, you’ll know that acceptance of diversity in the programming, especially open source, community is really important to me. Maybe that’s why I liked the “Snakes and Rubies” video so much. Or maybe it was David Heinemeier Hansson’s (of Ruby) hilariously opinionated comments during the Q&A portion of the forum. Or maybe it was getting to hear Adrian Holovaty talk about some of the ideas behind Django, what it’s been used for, and what “batteries” it has included.
Regardless of exactly what it was, the “Snakes and Rubies” video was a highly entertaining, extremely informative piece of media. It was well worth the time (3 hours!) I invested to watch it. Up until this video, I had not taken more than a cursory glance at Django. I’m glad this video came along to remedy that.
I’ve been using TurboGears since about a week from its public release and previously had been using CherryPy since around (I think) version 0.7, so those are the Python web frameworks I’m most familiar with. Django takes a completely different perspective from either CherryPy or TurboGears. Django tries to be an all-in-one project, while CherryPy is a generic web framework. TurboGears tries to be an all-in-one project as well, but TurboGears pulls in pieces from different projects (CherryPy, MochiKit, SQLObject, Kid), whereas Django developed its pieces in house.
At this point, many readers will invariably raise mental red flags against Django because it is violating the DRY (Don’t Repeat Yourself) principle because it isn’t re-using existing technology. (I know, they’re not repeating themselves as much as they are repeating work which has already been done. But it’s the spirit of the thing.) One of David Heinemeier Hansson’s comments during “Snakes and Rubies” was something to the effect that code re-use is overrated. That got me thinking. I’m not pronouncing anyone right or wrong at this point. I’m still pondering the thought. I’m merely raising the question, what if re-creating existing code sometimes isn’t as evil as we’ve been taught? What if the proliferation of web frameworks in Python is actually a good thing? I can think of at least a few reasons why it’s a good thing. I can also think of several situations where re-creating existing code can be pure evil, as well. Maybe I’ll blog about it if I can codify my thoughts and get it down into 0 and 1s.
Is “re-inventing the wheel” really as evil as “the experts” say?
Criticism of "wheel reinvention" considered harmful
Nicely put.
I'm consistently mystified by the small group of folks who automatically write off Django because it "reinvents wheels."
Of course, usually somebody brings up the fact that Django's now more than two years old, and the critics fumble around and don't really know how to respond.
But, even if Django *weren't* that old, the argument would be equally mystifying. Web development isn't a wheel. It's a complex problem, with multiple solutions that are fundamentally opinionated. A Web framework is not like a low-level operating-system library, which either does Function X correctly or doesn't.
Frankly, I can't stand the fact that CherryPy, included with TurboGears, by default doesn't distinguish between POST and GET data. That strikes me as a tremendous design flaw. And there's the fact that Kid's template system is several times slower than Django's, because it requires an XML parser even for the most basic templating tasks.
Of course, I'm being subjective. But that's my point. Different strokes for different folks.
If you want to use TurboGears, use it because you like the features better than Django's -- not because of some faulty reasoning that "oh, that framework reinvents the wheel, therefore I shouldn't use it." That's just not logical.
come up with a better wheel
As long as you come up with a better wheel than there was before, reinventing the wheel is perfectly fine, IMO.
Sometimes your wheel needs to be different enough
As with anything in computers, reusing code comes with tradeoffs. You might not get *exactly* what you want. You might also have a harder time dealing with that project's existing community.
If you can pull it off, code reuse (of good code!) is a positive thing because that code has likely had previous usage and debugging time put in on it.
Sometimes, though, you do need to reinvent the wheel because the specs for your wheel are different enough from the wheels already on the market. TurboGears' widgets is an example of that. Lots of people have written form frameworks. But I valued fitting in with the rest of TurboGears and ease-of-use more highly than being able to use pre-existing code.
Each time you consider bringing in code, you just have to make a judgment of the "cost" of that code vs. the cost of rolling your own.