On 11/22/05, Beorn <[EMAIL PROTECTED]> wrote: > There are two parts to "ease of learning". One is how easy it is to > get started, the other is how easy it is to keep going. Ruby does > pretty well on both fronts.
One of the things that bothers me about Rails is that you get the "instant gratification" factor with scaffolding, but then you basically have to (and all the documentation, including the book encourages you to) throw it away and rewrite it all; the scaffolding turns out to basically be just for show. To me, that makes it a bit easier to quickly get something basic up and running, but creates a hassle for further development. But anyway... > * more obvious best practices (see above) I think we need at least a little bit of time for this to coalesce, though the documentation already has hints of preferred ways to accomplish particular tasks. > * improve django-admin so it works more like svn or cvs, as a meta > command that would look in the file system for config (environment > variable optional). The sub-commands could be more logically named as > well. I'm somewhat ambivalent about this, although I like the convenience of being able to export DJANGO_SETTINGS_MODULE and work from any directory. But then, I'm usually sitting in screen and can easily switch to another project by popping up a new shell and exporting a different DJANGO_SETTINGS_MODULE for it. > * reduce the amount of config/ code necessary. make the default for > models be that their schema (and admin interface) is generated from the > database schema. this makes it possible to get an admin interface > up-and-running just by pointing to a database. Generating the model from the database is one of the few things that I absolutely cannot stand about Rails, and to my mind it creates a significant and unnecessary learning curve; Django's model system requires you to write a bit more code, yes, but it also has two major advantages: 1. It means that there is one, and only one, standard syntax for specifying models in Django, instead of one separate syntax for each different database backend. This makes Django easier to learn, as it requires no specialized knowledge of particular databases, and also makes Django applications far more portable and Django models more easily shared for learning purposes. This would, then, strike me as a best practice to be enforced by the framework (in addition to being an awfully Pythonic approach). 2. It enforces DRY. In Rails, to take an example, specifying a relationship between two models means that the relationship must be specified twice: once when the tables are created by an SQL statement written by the developer (e.g., by adding a foreign key to the table), and then again in the model code (by use of has_many, belongs_to, etc.). Django's model definitions require model relationships to be specifed once, and only once. This is, again, a best practice and to be encouraged. > * automatically make plural versions of names ending in -y be -ies. > you can always override the plural name if you some other behavior, > it's just that in 95% of the cases this is what you want. English is > the de-facto language in programming, (almost) no matter where you live > in the world (I live in China). Sounds good, but then how far do we take it? Rails claims it's smart enough to know that a model called 'child' should be pluralized to 'children', for example; is this needed, too? > * use standard MVC naming convention for model, views, and controllers > (that's what people are used to) The problem with this is that Django isn't strictly MVC. Better in my mind to call them something else than to call them by familiar names and startle people when the components don't work exactly as their names imply. > * and as you've mentioned before: clearer design philosophy (and I must > say I don't disagree with Ruby's and I don't think we have to be very > different from theirs) AND a screencast I think Django is fundamentally different from Rails in a number of ways, and I also think that there's a lot to be said for not jumping on the "we're just like Rails, but for $OTHER_LANGUAGE" bandwagon. Django should be advertised on what makes Django a useful and elegant framework. While I don't think we could get away with it entirely, it'd be nice to try to avoid mentioning other frameworks by name whenever possible. -- "May the forces of evil become confused on the way to your house." -- George Carlin
