6 ms·

The mess Django's in

58 points by niels 16y ago

nudge 16y ago
Not sure I could disagree much more with this. Firstly, I think the power of Django's inbuilt functionality more than makes up for whatever aesthetic problems there might be (I haven't checked) with the underlying code. That's a trade-off I'm very willing to take. Secondly, I'd rather go with messy code and an active bug-fixing and development team than beautiful code that no-one touches. Plus, there's no 'kool aid drinking' going on here. In fact there's surprisingly little razzle-dazzle about Django. All I know is that it helps me build what I want to build, fast, and the documentation is the best I've ever seen for just about anything.
- rossj 16y ago
  It's a blog post on a three year old article - the first comment to the post by Adam starts with the following... (I'm the author of the 2007 article.) I disagree with you about the Django codebase. Overall, it's well-written, well-tested, and extremely well documented, so much so that I consider it a case study of "what to do with a free software project".
- agentultra 16y ago
  You have to drink the kool-aid. Django has managed to develop all of its own components. It's not impossible to switch out one of those components for a better one, but you'll be fighting the framework to do it. That's because the Django framework likes to use the Django components. If you don't drink the kool-aid, you're missing the point. It's a decent framework for what it is and has a large community behind it. Some of the best marketing in a Python project I know about. Just from memory, the last time I looked at the ORM code it was pretty bad. There were functions that ran on for hundreds of lines without comments or docstrings. Plenty of introspection being used to bypass encapsulation. It wasn't impossible to follow, but it did look a little haphazard and "thrown together" (as opposed to thoughtfully planned out and designed). SQLAlchemy otoh, is a really good example of well designed and clean code. As far as ORMs and database interfaces go, they have some very clear ideas and concepts they've built up from. The "mess" I think Django may find itself in is that there are frameworks built on third-party libraries that are easier to use and better to use than Django. Its ORM isn't as great as SQLAlchemy. Its templating engine isn't as great as Mako. For a framework as large as Django I think they will find it harder and harder to keep up with what everyone else is doing as long as they continue to believe that they can "code it all."
  - nudge 16y ago
    Following the conventions of a project in order to take advantage of its strengths is not 'drinking the kool-aid'. If you need custom components and find it hard to integrate them, use something else. Nobody's forcing you to use Django. Your thoughts about the templating engine vs Mako, and the ORM vs SQLAlchemy are subjective. You should recognize this. I don't mean that one is not better than the other. I just mean that 'better' is really 'better for you and what you want to do'. For me, Django is perfectly sufficient. Similarly subjective is the value you put on 'clean code'. I happen to value a community that tests and makes sure it all works. That is also subjective. Don't confuse your preferences with actual problems with something you are evaluating. Django works for me, very well. I didn't drink any kool-aid. If it doesn't work for you, that's fine. But if you think the fact that it doesn't work for you, or meet your standards, means that the project is in a mess, then I think you are the one missing the point.
    - agentultra 16y ago
      I should recognize what, exactly? That you're using relativism as a red-herring? I meant what I said, thank you very much. Not everything is created equal. SQLAlchemy's ORM is just better than Django's ORM. Better in the majority of objective metrics you can think of. The code is well designed, structured, and documented. It supports better features and more databases. It's not just better because "it works for me." I didn't say that the Django project itself "is a mess." It still has a great community and leadership. It still has great marketing and strong appeal for a niche audience. What I did say was that Django may find itself in a mess when competing frameworks provide more than Django can offer because they rely on a community of components that individually are better than those offered by Django. I should mention I base my hypothesis on years of experience developing large and small sites and applications using Django as well as a few years developing websites using other frameworks and using SQLAlchemy.
      - nudge 16y ago
        You're not understanding me. You say A is better than B, objectively. I'm telling you that B suffices for my purposes. Given that, the fact that A is objectively better than B doesn't really matter. That fact's importance is subjective. You find it important. I do not. So you should recognize that what you find as a fault is not necessarily a problem for others, and therefore not necessarily a problem for the project.
- jiaaro 16y ago
  I completely agree. I could care less if the underlying code is messy as long as it is actively developed, and works. The project maintainers on the other hand have an incentive to make the code easy to work on. Especially if they want outside contributers. Not to mention the fact that they themselves (the project maintainers) have to work on it.
- deleted 16y ago
  [deleted]
mdg 16y ago
>Even simple things like setting up and tearing down the database is awkward. You have to actually make an outside call to a command-line script to do it. ... Because I want to be able to do that WITHIN my webapp? As a side note, I wish this guy would of pointed to some specific examples instead of speaking in generalities.
- jerguismi 16y ago
  > As a side note, I wish this guy would of pointed to some specific examples instead of speaking in generalities. It is very hard to give specific examples, most this kind of blog posts are mostly rants without anything concrete to grasp on. I guess it's mostly about what kind of coding/architectural style are you used to. For example, I have done rails several years ago. I liked it, but just couple of small projects. Then I started my next site with django, which I liked very much. I found the django's modular system much better than rails, and it was very easy to add functionality through open-source packages and customize them for my needs. Now I have started contracting project where I fix existing rails project, and it is kind of pain in the ass, because I'm used to django's way of thinking. But I can't give any specific reasons why it sucks, it is just my viewpoint.
- digitallogic 16y ago
  It isn't an issue if all you have is a webapp, but if you plan on interfacing with the database from any other context you're gonna have trouble. Here's an example that should illustrate the point, being unfamiliar with the django code base try to use user input to specify the database credentials.
j_baker 16y ago
I couldn't disagree more that Django's code is horrible. In my experience (which isn't much to be honest), Django's code is a pleasure to read. That said, I do think that a case can be made that Django's architecture has some definite warts. Whether or not they are a huge deal is largely a matter of opinion. For instance, I do agree with the author that Django does have a bit of an overreliance on import-time side effects. I particularly don't like the fact that I can't even import some parts of Django without having a settings.py defined. On the other hand, I don't know how difficult it would be to change it.
jz 16y ago
I've only looked at a small portion of the underlying django code and from what I've seen there were definitely some complicated parts, but it was far from being messy. Perhaps the author is confusing necessary complication with messiness? After all, isn't the purpose of a high level framework to hide the messy details and allow you to express your ideas clearly and efficiently? I have read and understood all of web.py and am currently buried up to my head in rails actionpack routing code, both contain some hairy bits of code. By pushing all these messy details down into the library they allow the application developer to be more expressive and concise. As long as there are tests, comments, and documentation to back up the complicated bits, I don't have a problem with a library or framework not being obvious to understand at first glance.
c00p3r 16y ago
Google uses Django on its AppEngine, at least some parts of it. Seems that it is not so badly written.
barnaby 16y ago
Can't say I agree with this either.
angelbob 16y ago
It sounds like a lot of the complaints are about their ORM layer. I'll point out that Rails (a very comparable project) has a lot of cruft in ActiveRecord, their ORM layer, as well. I can't directly compare it to Django's, but it's a bit of a hairball. Some of it is just that it's hard to write a good ORM layer. Let's hope that Django can also take a Rails 3-esque approach -- make the ORM layer modular, then use whichever you like. That's a surprisingly good way to disentangle the internals of the ORM from everything else. And once you do that, it gets a lot easier to polish up the code, or if necessary replace it with something prettier. I imagine a fair number of the Rails 3 folks will be replacing ActiveRecord with DataMapper, for somewhat similar reasons. I plan to.
Daishiman 16y ago
Completely disagree. Most of Django's components are so simple that you can tear them out and replace them for your own thing. I've done it several times now and I never felt confused about it.
ibejoeb 16y ago
What? How about an example? The Django code is concise, readable, and pretty modular. I rarely read the docs anymore; just browse the code. In fact, I feel like a better programmer for having read most of the Django code. This appears to have been written today, but it reads like it's from 3 years ago.
ubernostrum 16y ago
ORMs are like sausages. You really don't want to know what goes into them.
- kingkilr 16y ago
  Pssh, a lot more love went into the ORM than ever went into a sausage.
  - ubernostrum 16y ago
    You've apparently been eating the wrong kinds of sausages.
kqueue 16y ago
Just because you don't understand the code it doesn't mean it is awful. I am not defending django at all since I use webpy. Saying the code is awful without proving why is just a way to explain to yourself why you are not understanding the code. It makes you relieved that it is not your fault. However it is your brain deceiving itself. Blame it on yourself first then on the code.
- stevenwei 16y ago
  >>> Just because you don't understand the code it doesn't mean it is awful. Disagree entirely. My philosophy has always been that code is more difficult to maintain than it is to write in the first place, so one of the core tenets of well written code is its simplicity and ease of understanding. If you write a convoluted mess that's difficult for someone new to pick up right away, it will probably also be difficult for you to jump back into several months later when you need to fix a bug or add features. Not to mention making it more difficult for third party developers to contribute...
  - kqueue 16y ago
    You are assuming that if you didn't understand the code, then no one can. Hence, if you don't understand it, then it is awful. What I am saying if you want to say a code is awful, then state why it is awful.
stevenwei 16y ago
I mostly agree with the author of the article: ever try to modify the User object to accept an email instead of username for login purposes? It's a complete hack. The thing is, it didn't need to be a hack, but some of the core components are really tightly coupled together when they don't need to be, so it ends up being a hack. This tends to happen a lot when you 'go outside the box' of Django's codebase. For example, everyone says you can 'use SQLAlchemy' in Django. On paper this is true. But then you lose the admin, the user auth system, the messages system, model forms, and all of the other batteries that make Django useful. That said, the alternatives to Django are so incredibly lacking that (for the moment), I'd rather stick with Django than roll my own everything else. Pylons and Turbogears are an ugly mish-mash of third party libraries that don't work well together. In some cases there are good third party libraries (SQLAlchemy is indeed quite an amazing piece of software), but many other pieces are lacking: - Authentication/authorization libraries are terrible. (You want to bury that in the middleware layer and use query string parameters to indicate login failure? What?) - Nothing out there is as good as Django's model forms. - There is no equivalent to sorl-thumbnail, for basic image processing. - The boatload of third party Django apps. Yes, most of these are poorly written and not modular enough either but there are some really useful ones out there like django-pagination and django-compress. Django is far from perfect but unfortunately, taken as a whole, it's still better than the current alternatives.
- henriklied 16y ago
  > For example, everyone says you can 'use SQLAlchemy' in Django. On paper this is true. But then you lose the admin, the user auth system, the messages system, model forms, and all of the other batteries that make Django useful. Using SQLAlchemy doesn't change any of that. For pre-built components, like auth and admin, just go with the flow. You're free to use SQLAlchemy side-by-side with Django's ORM.
  - stevenwei 16y ago
    Really? What happens when you want to start customizing the User model, perhaps linking it to a UserProfile. Perhaps you want to have many Users belong to the same Account? Do you create duplicate representations of your models in SQLAlchemy and Django? What happens when you need to start migrating your database schemas? Forgive my lack of imagination, but I can't think of any way of doing what you suggest without it coming across like a horrible hack.
lionshare 16y ago
SQL and Objects are a problem in the first place. SQL is optimized when working with sets. So unless simple one-record read/write, most queries should fall to direct SQL which is really easy to do in Django and in Python. And for the one-record transactions, the ORM does not really matter that much. Bottom line: SQL is an essential programming skill.

58 points by niels 16y ago

nudge 16y ago

Not sure I could disagree much more with this. Firstly, I think the power of Django's inbuilt functionality more than makes up for whatever aesthetic problems there might be (I haven't checked) with the underlying code. That's a trade-off I'm very willing to take. Secondly, I'd rather go with messy code and an active bug-fixing and development team than beautiful code that no-one touches. Plus, there's no 'kool aid drinking' going on here. In fact there's surprisingly little razzle-dazzle about Django. All I know is that it helps me build what I want to build, fast, and the documentation is the best I've ever seen for just about anything.

rossj 16y ago
It's a blog post on a three year old article - the first comment to the post by Adam starts with the following... (I'm the author of the 2007 article.) I disagree with you about the Django codebase. Overall, it's well-written, well-tested, and extremely well documented, so much so that I consider it a case study of "what to do with a free software project".
agentultra 16y ago
You have to drink the kool-aid. Django has managed to develop all of its own components. It's not impossible to switch out one of those components for a better one, but you'll be fighting the framework to do it. That's because the Django framework likes to use the Django components. If you don't drink the kool-aid, you're missing the point. It's a decent framework for what it is and has a large community behind it. Some of the best marketing in a Python project I know about. Just from memory, the last time I looked at the ORM code it was pretty bad. There were functions that ran on for hundreds of lines without comments or docstrings. Plenty of introspection being used to bypass encapsulation. It wasn't impossible to follow, but it did look a little haphazard and "thrown together" (as opposed to thoughtfully planned out and designed). SQLAlchemy otoh, is a really good example of well designed and clean code. As far as ORMs and database interfaces go, they have some very clear ideas and concepts they've built up from. The "mess" I think Django may find itself in is that there are frameworks built on third-party libraries that are easier to use and better to use than Django. Its ORM isn't as great as SQLAlchemy. Its templating engine isn't as great as Mako. For a framework as large as Django I think they will find it harder and harder to keep up with what everyone else is doing as long as they continue to believe that they can "code it all."
- nudge 16y ago
  Following the conventions of a project in order to take advantage of its strengths is not 'drinking the kool-aid'. If you need custom components and find it hard to integrate them, use something else. Nobody's forcing you to use Django. Your thoughts about the templating engine vs Mako, and the ORM vs SQLAlchemy are subjective. You should recognize this. I don't mean that one is not better than the other. I just mean that 'better' is really 'better for you and what you want to do'. For me, Django is perfectly sufficient. Similarly subjective is the value you put on 'clean code'. I happen to value a community that tests and makes sure it all works. That is also subjective. Don't confuse your preferences with actual problems with something you are evaluating. Django works for me, very well. I didn't drink any kool-aid. If it doesn't work for you, that's fine. But if you think the fact that it doesn't work for you, or meet your standards, means that the project is in a mess, then I think you are the one missing the point.
  - agentultra 16y ago
    I should recognize what, exactly? That you're using relativism as a red-herring? I meant what I said, thank you very much. Not everything is created equal. SQLAlchemy's ORM is just better than Django's ORM. Better in the majority of objective metrics you can think of. The code is well designed, structured, and documented. It supports better features and more databases. It's not just better because "it works for me." I didn't say that the Django project itself "is a mess." It still has a great community and leadership. It still has great marketing and strong appeal for a niche audience. What I did say was that Django may find itself in a mess when competing frameworks provide more than Django can offer because they rely on a community of components that individually are better than those offered by Django. I should mention I base my hypothesis on years of experience developing large and small sites and applications using Django as well as a few years developing websites using other frameworks and using SQLAlchemy.
    - nudge 16y ago
      You're not understanding me. You say A is better than B, objectively. I'm telling you that B suffices for my purposes. Given that, the fact that A is objectively better than B doesn't really matter. That fact's importance is subjective. You find it important. I do not. So you should recognize that what you find as a fault is not necessarily a problem for others, and therefore not necessarily a problem for the project.
jiaaro 16y ago
I completely agree. I could care less if the underlying code is messy as long as it is actively developed, and works. The project maintainers on the other hand have an incentive to make the code easy to work on. Especially if they want outside contributers. Not to mention the fact that they themselves (the project maintainers) have to work on it.
deleted 16y ago
[deleted]

mdg 16y ago

>Even simple things like setting up and tearing down the database is awkward. You have to actually make an outside call to a command-line script to do it. ... Because I want to be able to do that WITHIN my webapp? As a side note, I wish this guy would of pointed to some specific examples instead of speaking in generalities.

jerguismi 16y ago
> As a side note, I wish this guy would of pointed to some specific examples instead of speaking in generalities. It is very hard to give specific examples, most this kind of blog posts are mostly rants without anything concrete to grasp on. I guess it's mostly about what kind of coding/architectural style are you used to. For example, I have done rails several years ago. I liked it, but just couple of small projects. Then I started my next site with django, which I liked very much. I found the django's modular system much better than rails, and it was very easy to add functionality through open-source packages and customize them for my needs. Now I have started contracting project where I fix existing rails project, and it is kind of pain in the ass, because I'm used to django's way of thinking. But I can't give any specific reasons why it sucks, it is just my viewpoint.
digitallogic 16y ago
It isn't an issue if all you have is a webapp, but if you plan on interfacing with the database from any other context you're gonna have trouble. Here's an example that should illustrate the point, being unfamiliar with the django code base try to use user input to specify the database credentials.

j_baker 16y ago

I couldn't disagree more that Django's code is horrible. In my experience (which isn't much to be honest), Django's code is a pleasure to read. That said, I do think that a case can be made that Django's architecture has some definite warts. Whether or not they are a huge deal is largely a matter of opinion. For instance, I do agree with the author that Django does have a bit of an overreliance on import-time side effects. I particularly don't like the fact that I can't even import some parts of Django without having a settings.py defined. On the other hand, I don't know how difficult it would be to change it.

jz 16y ago

I've only looked at a small portion of the underlying django code and from what I've seen there were definitely some complicated parts, but it was far from being messy. Perhaps the author is confusing necessary complication with messiness? After all, isn't the purpose of a high level framework to hide the messy details and allow you to express your ideas clearly and efficiently? I have read and understood all of web.py and am currently buried up to my head in rails actionpack routing code, both contain some hairy bits of code. By pushing all these messy details down into the library they allow the application developer to be more expressive and concise. As long as there are tests, comments, and documentation to back up the complicated bits, I don't have a problem with a library or framework not being obvious to understand at first glance.

c00p3r 16y ago

Google uses Django on its AppEngine, at least some parts of it. Seems that it is not so badly written.

barnaby 16y ago

Can't say I agree with this either.

angelbob 16y ago

It sounds like a lot of the complaints are about their ORM layer. I'll point out that Rails (a very comparable project) has a lot of cruft in ActiveRecord, their ORM layer, as well. I can't directly compare it to Django's, but it's a bit of a hairball. Some of it is just that it's hard to write a good ORM layer. Let's hope that Django can also take a Rails 3-esque approach -- make the ORM layer modular, then use whichever you like. That's a surprisingly good way to disentangle the internals of the ORM from everything else. And once you do that, it gets a lot easier to polish up the code, or if necessary replace it with something prettier. I imagine a fair number of the Rails 3 folks will be replacing ActiveRecord with DataMapper, for somewhat similar reasons. I plan to.

Daishiman 16y ago

Completely disagree. Most of Django's components are so simple that you can tear them out and replace them for your own thing. I've done it several times now and I never felt confused about it.

ibejoeb 16y ago

What? How about an example? The Django code is concise, readable, and pretty modular. I rarely read the docs anymore; just browse the code. In fact, I feel like a better programmer for having read most of the Django code. This appears to have been written today, but it reads like it's from 3 years ago.

ubernostrum 16y ago

ORMs are like sausages. You really don't want to know what goes into them.

kingkilr 16y ago
Pssh, a lot more love went into the ORM than ever went into a sausage.
- ubernostrum 16y ago
  You've apparently been eating the wrong kinds of sausages.

kqueue 16y ago

Just because you don't understand the code it doesn't mean it is awful. I am not defending django at all since I use webpy. Saying the code is awful without proving why is just a way to explain to yourself why you are not understanding the code. It makes you relieved that it is not your fault. However it is your brain deceiving itself. Blame it on yourself first then on the code.

stevenwei 16y ago
>>> Just because you don't understand the code it doesn't mean it is awful. Disagree entirely. My philosophy has always been that code is more difficult to maintain than it is to write in the first place, so one of the core tenets of well written code is its simplicity and ease of understanding. If you write a convoluted mess that's difficult for someone new to pick up right away, it will probably also be difficult for you to jump back into several months later when you need to fix a bug or add features. Not to mention making it more difficult for third party developers to contribute...
- kqueue 16y ago
  You are assuming that if you didn't understand the code, then no one can. Hence, if you don't understand it, then it is awful. What I am saying if you want to say a code is awful, then state why it is awful.

stevenwei 16y ago

I mostly agree with the author of the article: ever try to modify the User object to accept an email instead of username for login purposes? It's a complete hack. The thing is, it didn't need to be a hack, but some of the core components are really tightly coupled together when they don't need to be, so it ends up being a hack. This tends to happen a lot when you 'go outside the box' of Django's codebase. For example, everyone says you can 'use SQLAlchemy' in Django. On paper this is true. But then you lose the admin, the user auth system, the messages system, model forms, and all of the other batteries that make Django useful. That said, the alternatives to Django are so incredibly lacking that (for the moment), I'd rather stick with Django than roll my own everything else. Pylons and Turbogears are an ugly mish-mash of third party libraries that don't work well together. In some cases there are good third party libraries (SQLAlchemy is indeed quite an amazing piece of software), but many other pieces are lacking: - Authentication/authorization libraries are terrible. (You want to bury that in the middleware layer and use query string parameters to indicate login failure? What?) - Nothing out there is as good as Django's model forms. - There is no equivalent to sorl-thumbnail, for basic image processing. - The boatload of third party Django apps. Yes, most of these are poorly written and not modular enough either but there are some really useful ones out there like django-pagination and django-compress. Django is far from perfect but unfortunately, taken as a whole, it's still better than the current alternatives.

henriklied 16y ago
> For example, everyone says you can 'use SQLAlchemy' in Django. On paper this is true. But then you lose the admin, the user auth system, the messages system, model forms, and all of the other batteries that make Django useful. Using SQLAlchemy doesn't change any of that. For pre-built components, like auth and admin, just go with the flow. You're free to use SQLAlchemy side-by-side with Django's ORM.
- stevenwei 16y ago
  Really? What happens when you want to start customizing the User model, perhaps linking it to a UserProfile. Perhaps you want to have many Users belong to the same Account? Do you create duplicate representations of your models in SQLAlchemy and Django? What happens when you need to start migrating your database schemas? Forgive my lack of imagination, but I can't think of any way of doing what you suggest without it coming across like a horrible hack.

lionshare 16y ago

SQL and Objects are a problem in the first place. SQL is optimized when working with sets. So unless simple one-record read/write, most queries should fall to direct SQL which is really easy to do in Django and in Python. And for the one-record transactions, the ORM does not really matter that much. Bottom line: SQL is an essential programming skill.