4 ms·

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 t

by 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]

by nudge 16y ago

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]