4 ms·

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 har

by 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.
  - agentultra 16y ago
    By taking the "it works for me" (relativist) position, you're avoiding the central argument. The OP pointed out that Django's reliance on internal dependencies and import-time side effects is a bad thing. I agreed and added that the internal components themselves aren't bad, but that it's the superior components that other frameworks are using that makes Django bad. There are a lot of people out there who could justify using COBOL by your same logic. I think Mark Ramm was being more prescient than most people give him credit for when he suggested Django could go the way of Zope if it doesn't open up to the wider python eco-system. The Django ORM isn't the best ORM available and I think it hurts Django to not be able to take advantage of better ORMs without having to sacrifice its core features (admin, authentication, etc).
    - nudge 16y ago
      I'm not avoiding your argument. I'm telling you it's fallacious. Technologies don't come and go according to whether they're better or worse than other technologies. They really don't. They come and go according to whether enough people decide to use them, or engage with them, or develop them, and so on. If it were as you say then no-one would be using php, which plenty of people would agree is 'worse' than its alternatives. I mean, you're sort of right. Your argument is just missing a step. It may be that Django's difficulty including other toolkits is a weakness. But that only matters when enough people decide it matters. You can call that relativism if you like. It doesn't make any difference. But it could just be that Django works fine enough. Feel free to point out how wrong I am, but if you do it from a qwerty keyboard (an 'objectively' bad keyboard layout), you'll only be proving my point. Problems are only problems when they're problems for people.

by nudge 16y ago

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.
- agentultra 16y ago
  By taking the "it works for me" (relativist) position, you're avoiding the central argument. The OP pointed out that Django's reliance on internal dependencies and import-time side effects is a bad thing. I agreed and added that the internal components themselves aren't bad, but that it's the superior components that other frameworks are using that makes Django bad. There are a lot of people out there who could justify using COBOL by your same logic. I think Mark Ramm was being more prescient than most people give him credit for when he suggested Django could go the way of Zope if it doesn't open up to the wider python eco-system. The Django ORM isn't the best ORM available and I think it hurts Django to not be able to take advantage of better ORMs without having to sacrifice its core features (admin, authentication, etc).
  - nudge 16y ago
    I'm not avoiding your argument. I'm telling you it's fallacious. Technologies don't come and go according to whether they're better or worse than other technologies. They really don't. They come and go according to whether enough people decide to use them, or engage with them, or develop them, and so on. If it were as you say then no-one would be using php, which plenty of people would agree is 'worse' than its alternatives. I mean, you're sort of right. Your argument is just missing a step. It may be that Django's difficulty including other toolkits is a weakness. But that only matters when enough people decide it matters. You can call that relativism if you like. It doesn't make any difference. But it could just be that Django works fine enough. Feel free to point out how wrong I am, but if you do it from a qwerty keyboard (an 'objectively' bad keyboard layout), you'll only be proving my point. Problems are only problems when they're problems for people.