Best reason to do this is to develop your own preference.
No, sorry, developing your own preference is a
good reason to do this, but the
best reason to do this is pretty simple -- If you have two separate-but-similar projects, and you can write them in two separate-but-similar languages, at the same time, you'll be a better coder for it.
Here's why --
* Ruby and Python (and Rails and Django) have lots of "magic", and that's a good thing. Magic saves me thousands of hours per hour -- read it again, THOUSANDS OF HOURS
PER HOUR.
* But real "magic" is invisible to the developer and you won't
learn what that magic
is until you no longer have it.
* When you use a language/framework, you become addicted to it's "magic" and you wind up
needing that magic in everything you do. There's nothing wrong with this, that's just part of gaining mastery over a toolset.
* When you switch to a different language/framework, and your usual "magic" disappears, you're forced to understand a) Where the magic was, b) What the magic was doing for you, and c) Why that magic is important.
* Then, if you want to re-implement the magic, you have to know enough about
both languages/frameworks to make a translation between the two.
A perfect [albeit simplistic] example -- In Rails, the code-logic-that-powers-a-template (Rails: "Controller", Django: "View") automagically guesses what the names of the associated HTML template (Rails: "View", Django: "Template") will be, from the name of the code block.
E.g. A Rails action like UserController#Edit would automatically render /app/views/user/edit.html.haml
This is great and handy and useful!
But, let's say I'm a new Rails developer coming from a PHP background. Once I figured out this magical paradigm, I'll stick my code in my controller, and my HTML in that view file, but would I ever even realize that I can
force the same action to use different templates? Would I truly understand what Rails is doing behind the scenes here, or would I be leveraging the magic without understanding it?
Example part two -- Then, I start a Py/Django project for something. In Django, I define a View and a Template (analogous to a Controller/Action and a View in Rails), but I have to explicitly render the template inside the view, and return it as an HttpResponse() object to the WSGI gateway. Now, looking back at Rails, I'm able to say "Oh, Rails
guesses my template for me from the controller, what a nifty feature!". Using what I know about Python, I then create a new function decorator to emulate the Rails shorthand --
Code:
Old way:
def user_edit(req):
return render_to_response('user/edit.html', {'message': 'Put this message into the template'},
context_instance=RequestContext(req))
My new way, emulating Rails's magic:
@guess_template()
def user_edit(req):
return {'message': 'Put this message into the template'}
Voila, padwan. I have exhibited mastery over both languages that I would not have attained from using a single language alone.
I have created my own magic. This is the difference between someone who codes one thing and sticks with it, versus someone who learns them all.