[gte910h]

The differences between python and ruby aren't the important thing in this question. The languages are different (ruby: better syntax, python: better libraries). The important thing is "Are you the type of person who will excel with very strong strictures on your work" (Do rails) or "Are you a person who sometimes disregards the rules to do work more expeditiously" (Do python)

[danieldon]

You have that completely backwards. If you are coding your Python like that, you are doing it wrong and almost certainly drawing the ire of the people you work with.

[gte910h]

I mean, they get really pissed off when we hack a view 2 days before a deadline instead of just not delivering it. I mean people LOVE when you don't deliver.

Hacks are not good. Hacks should not be done all the time. But sometimes, shipping is more important than beauty and elegance. Hacks you put up while you get the real, good code in place is next to godliness when working in multicomponent systems under tight deadlines. Rails just isn't as good when you need to do that sort of thing. It doesn't have that flexibility, by design!

When I write the hacked up glue code first so they can do their stuff while I write mine, they f-ing love that. It lets them do their job!

I do things "the right way" 99% of the time. That buys me incredible flexibility to use utter crap code that's otherwise functional that other 1% of the time when required by the job.

[danieldon]

I don't presume to know your work environment, but personally I work on my own projects and do contract work and, in my experience, taking on debt is usually a sign that there's a problem with the requirements and estimates, so I usually change those before making the code less maintainable (which, IMO, is usually a case of treating the symptom).

Regardless, I'm weary of claims that controller-level (django view level) code is a major pain point in Rails. In some ways it's actually easier since you can make fewer decisions by making them resource centric, but even deviating from that is as simple as map "/path", :to => "controller#action".

Rails/Django controllers/view and routing/urls aren't as elegant as micro-frameworks like Flask and Sinatra or not-so-micro-frameworks like Padrino, but they aren't anything close to serious stumbling blocks (though maybe routing to a very small degree in resource-centric Rails 2). Every blocking issue I've had with either framework has been on a deeper level. In Rails pre-3, it was usually configuration-related when trying to do something too unconventional. In Django, it's when trying to deviate from the overall Django philosophy and use something other than the included batteries.

[gte910h]

I'm not arguing for systemic mortgages worth of debt. I'm arguing for using your credit card occasionally cause its easier than constantly going to the cash machine.

Use case:

iPhone dev "can you do this"

Ruby dev "Sure, takes a sec to rejigger things to allow that"

A few minutes/hours later "Done, and its perfect"

Alternative

iPhone dev "can you do this slightly differently"

Django dev "Like that?" [Just mocked up the entire thing in pure text, django happily returns it]

iPhone dev "thanks"

Django dev "I'll go make that work right now now that you can integrate your code

I have a real problem with the inability to provide a good enough version now when its more valuable than a very good version later, especially when there is room in the schedule to deliver both.

I work in an integration based environment, where the turnaround on the backend development is the maximum schedule issue, not the overall development scheme. I don't want my software development effort to look like the execution of a python program in a GIL bound multiprocessor environment. I want the thing done asap, if that means I'm paying the backend guy to redo his code 3 times cause the prototype is valuable and speeds up final time, I want the flexibility to do that.

I'm Excited that rails 3 promises to help part of this (as you correctly surmised, it is mostly rails 2 code and coders and turnaround issues I've dealt with), but I haven't yet seen it very much yet at all.

Schedules, requirements and all that are great, but if you can put a little hustle in at the end when there is something big on the line and get paid for that, you have very happy customers and very fat wallets. Non software people like delivery and there is a modicum of debt that sometimes requires.