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.
Ruby's more extensive skeleton isn't all bad: Ruby generates a lot of empty directories that actually "sell" the notion that this is a framework that can grow with you and has best practices for testing, documentation, using AJAX, logging, staging, where to put vendor-specific stuff, etc. Having such best practices really lowers the learning curve, and gives you a comfortable feeling that the framework can grow with you. It just looks like it's a well thought-out framework. There are very few files you have to change in RoR, and it's obvious which ones they are. All the empty directories just serves as a reminder that "there is a way to do this in RoR", and it'll entice you to learn more about how to do this or that. Without best practices we'll have 10 different ways to do everything, none of them particularly good, and that's a BAD thing. (I'm an ex Zope/ Plone victim.) So, as much as I love Python and therefore want to use Django, I have to admit RoR has a certain "beauty and simplicity" that Django hasn't reached yet. Yes, the screencast is completely necessary (and is why TurboGears could get so much attention even if they launched after Django), but Django also needs to be more lean and mean, with best practices being adopted and improved on. I'd say we do well to learn from RoR in this respect. My other pet pevees to simplify Django: * more obvious best practices (see above) * 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. * 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. * 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). * use standard MVC naming convention for model, views, and controllers (that's what people are used to) * 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 Rgds, -- Bjorn
