The original summary wasn't a bad summary and Gerard's reactions were also tongue-in-cheek. But it's important to realise that Cal's presentation was at the end of a very long day of talks and he was largely focused on being entertaining. Hopefully people won't take it as unquestioned gospel.
I have a long-ish blog post in the future about some of the more concrete points in his talk, but it was generally very well done and relatively accurate, if you realised what the back-story was and where he was joking (something that didn't come across nearly so clearly in the keynote at the start of day two, for example). So, just in case anybody was going to use this list as something to base actual judgements of Django on, (a) don't do that; watch the video to see the context and the smiles and do your own research and (b) here's some background information. I actually enjoyed the talk and I was the target of two of the jokes. It wasn't at all a bad presentation for the final talk of a long day. On Wed, 2008-09-17 at 01:34 +0200, Gerard Petersen wrote: > Sorry, couldn't help myself ... My 2 cents ... > > > - Python sucks, especially significant whitespace (I agree heartily. > > Only Django keeps me using Python.) > Disagree! Cal's a PHP user. You have to realise he's not really smart enough to use Python. He struggled a bit. The guy builds websites, not banking software, after all. :-) > > - Django could be a lot smarter about scaling the DB (sharding, > > denormalization, etc) > Questionable Yes and no. The most important thing to keep in mind here is the answer to a question Jacob asked at the end of the keynote. I don't know if that was in the video or not, but Jacob asked, effectively, "should a general-purpose framework be striving to do this as well as meeting the needs of the big fat middle of the user-curve?". Cal's answer was sensible: "I'm not really sure. Possibly not." However, it's always been a goal of Django's (if I can treat the framework as a living being for a moment) to provide ways for people who want to do some of this stuff to do so. Probably not by default inside the framework, since it's so domain-specific, but certainly have the hooks available that can be used by external code without requiring core patches. Realise that the undeclared background to the talk was along the lines of "could Django be used to build something like Flickr", but, as he mentioned, targeting one of the top 100 websites is actually too narrow once there are more than 200 websites (the majority of websites are then not in the top 100). > > - Inefficient session handling > Clue by 4 The reality is that there's more than one session model around. For better or worse (and there really are both advantages and disadvantages), Django uses server-side sessions. There's a big sweet spot for applications that use client-side sessions -- which are usually implemented via signed cookies -- and that's something that will almost certainly be supported in the future. Again, Cal was pointing out something that was indeed correct -- there are other ways that are more appropriate sometimes -- but that doesn't mean Django's current handling is per-se incorrect. > > - Django's template language sucks (verbose) > Disagree! That was one of the joking points. The video probably lost the back-and-forth between Cal and Simon, too (I didn't hear it live, either, and I was sitting maybe 25 metres away). It wasn't a real point. > > - ORM produces bad SQL > Not so far (after 1,5 months) Again "bad" is oversimplifying. He mentioned three things. Firstly, that he would have preferred to see "select *" in some cases. The reasons were a bit borderline and introduces a lot of extra processing in Django, so the performance win would have to be fairly extreme and I'm, frankly, doubtful without seeing lots of numbers. It's an idea that somebody might want to play with, but not a no-brainer. His second point was that the SQL needed to be printed out prettier and use neater aliases, etc. The latter point was addresses about five months ago. The former is a job for whatever debug tool is displaying the SQL, not for the backend that creates the SQL (the database server doesn't need linebreaks). A nice pretty-printer for displaying SQL would certainly be useful -- and already exists in a couple of debug middlewares. The final point was that if you do qs.exclude(foo=True) for a BooleanField "foo" and have an index on foo and are using MySQL, the index doesn't get used for the SQL. The answer is to write qs.filter(foo=False) or use a database that has a proper Boolean type for columns (MySQL simulates booleans using integers). The particular example he had was a tongue-in-cheek poke at something that is a flaw in MySQL and happened to be noticeable in Pownce. We do need to document that case for MySQL users. It's not practical to work around it in Django, since it would tie various layers of the code together much more tightly for one single case on one particular backend that is trivial to work around in any case. It's about as relevant as saying "Django doesn't do transactional work properly when using SQLite". One of those trade-offs you make when choosing the database backend. > > - SQL query debugging is hard in Django > Clue by 4 See the above point. It's basically "yes, but it's an add-on that needs to be written, not a flaw in the framework". We're believers in encapsulation, loose-coupling and relatively simple maintenance. > > - Lack of threading > Not into performance yet Wasn't the point that there was a lack of queuing and delayed handling (e.g. sending out 10,000 emails)? Threading isn't an issue on a high volume website, since you scale horizontally to multiple CPUs and even multiple machines in multiple data centres. Threading is pretty irrelevant at that point. There's certainly no solid queuing system, although that's not really a Django problem and is something that is best solved by a third-party app (and something I'm getting pretty close to having to do myself). Cal also made a point about a lack of ability to synchronise with something like a global external counter. For example, when assigning a photo id to a photo in Flickr. That's a missing piece that would be interesting for somebody to work on. > > - No deployment tools > Questionable Reasonably valid. Deployment can be hard for beginners and even experience people when database changes are involved. Rapid development can also be hard if you don't have a bit experience in planning things out first and, even then, you end up having to do some database munging by hand. > > - Database migration is painful > True! But also work in progress that really has multiple solutions at the moment and they are working to converge on one idea for some point in the future. > > - Not trendy enough > Get a pair of Gucci sunglasses maybe that'll help! > > - Needs more frequent releases > Possibly > > - Dev team needs beards. > Show me some pictures > > - Wants a pony. Literally. > How about some rollerskates .. ;-) All the above were, of course, part of the comedy routine. We have enough beards for any healthy development team. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
