Malcom,
First, thanx for your enlighting feedback. I'm working with Django for 1,5
months now and the direction I read between the lines looks promising.
Then, my reponse on Delta20's email was shot from the hip. My response
therefore was not intended to offend anyone. Working with python for a year,
and having snooped around in RoR and Zope for a while, it was more of a
heads-up towards Django from somebody (me) who just step into the trenches. And
fresh insights can always shed different views on subjects.
Again very pleased with Django as well as with your feedback on the subjects.
Thanx, and happy coding to all!
Regards,
Gerard -Just another sysadmin- P.
Malcolm Tredinnick wrote:
> 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
>
>
>
> >
--
urls = { 'fun': 'www.zonderbroodje.nl', 'tech': 'www.gp-net.nl' }
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
