Hacker News Reader

Comment by nudge | Hacker News Reader

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.

View on HN

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".

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."

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.

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.

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.

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).

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.

SQLAlchemy is a great ORM, but I don't think I would say that it's phenomenally better than Django's (at least from a code perspective). Making an ORM have good code is really hard, especially when you support as many databases as SQLAlchemy does. Not only does each database have its own quirks, but their drivers also have their own quirks, and so do the drivers' Python interfaces. And I haven't even gotten into the mess that is dealing with Unicode in Python 2.

Long story short, show me a Python ORM that has clean code, and I'll show you an ORM that either supports just one database or is so buggy as to be unusable.

I do think you should at least take a look at SQLAlchemy's code before saying it isn't clean. I can tell you that SA's code is exceptionally clean and easy-to-follow (so long as you're comfortable with the 'a-class-for-everything' way of working, which is what makes sense in their case).

As for messy code in Django, well that really isn't that fair. Sure, some of the things they do with imports is, frankly, scary, but there are very few cases where this becomes a problem, and when it does, there is always a workaround. Where, in my opinion, Django's ORM falls short is it doesn't really like you to think you're interacting with a database… many things that would be very useful just aren't there (swapping out ORM-generated SQL with a hand-written counterpart, for instance, is next to impossible). The typical solution to this seems to be "well, you can get a database cursor and do as you please"… but there comes a point where this just isn't good enough.

However, if Django's ORM just can't cut it for you on a project for whatever reason, it really isn't that hard to ditch and switch to something else (like SA). Yes, you will lose the admin, and you'll lose the authentication and session components (though these are actually easier than one might assume to get working under another ORM with their 'backends' concept), but you still have an amazing framework without these components.

Reading this article seems, to me, like the guy has taken one brief look at Django's internals before going on to condemn them as ugly in this post. And that's really not cool.

I have looked at SQLAlchemy's code, and I think it's about as clean as can be expected for an ORM. I wasn't trying to put SQLAlchemy down. I'm just saying that you have to apply a bit lower standard for ORM code than you would other parts of the code.

You should be able to use SQLAlchemy with your Django database, they aren't mutually exclusive.

Also, if you think you need a more "powerful" template system, you are probably bloating your template with code that should reside in your view functions written in python instead. HTML templates should be mainly HTML.

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.

Reply on news.ycombinator.com