Happy 20th Birthday, Django

Software is multilayered and you can prefer some layers over others.

I am huge fan of Python and Django. I despise PHP with the force of a thousand suns but I give enormous credit to Laravel as a well-designed framework that makes life bearable when working with PHP.

I've preferred Django for a few reasons:

* I've always preferred Python over Ruby. Explicit imports, namespaces and the "only one way to do something" philosophy have felt more scalable. In general the language does not promote as much implicit magic

* Django reflects the same philosophy: more explicit definitions, a slight bit more configuration and ceremony but easier debuggability.

* The Django docs are, to me, some of the best there is in documenting the framework extensively but also teaching good practices. I've always felt the Ruby docs to be lacking in the latter department so you see more drift in Ruby projects on how to approach the same problems

* Django has felt much stable over the years. Migration between major versions is a breeze.

* The Python library ecosystem is much larger

* The Django admin and Rest Framework are some of the biggest timesavers I've seen. Rails has similar projects but they don't quite make it

Unless you're doing a GIS or project with scientific computing I would not let these factors go above personal preference, as Rails is still an excellent framework.

It's not that Django has/had any reputation for those things -- it's that Django had no reputation at all since it was a nascent project with no track record. That means it had no proof points for being stable or secure. At the time I adopted it (~Nov 2005), the public release of the Django project was only a few months old, and indeed breaking changes followed soon after (the so-called "magic removal branch"). As I recall, there were also various template escaping security issues at that time.

> Also, how on Earth did the ML PhDs decide physically segregated databases for each user were a requirement?

I worked at several labs at top academic institutions, on everything from supercomputer MPI work for multi-agent sims to image pipelines for large weather simulations, and one thing I learned is that being a good coder is orthogonal to being a good researcher. In that particular case, the person who wrote the code made the assumption that the "customers" would not allow their sensor data to be stored alongside the data from other customers, and separate databases with separate passwords was the solution they came up with. Somehow they did not notice that the terrible ergonomics of this solution meant there was probably a better way. Once I ripped out MySQL in favor of Postgres (since it had proper security) and removed the cumbersome middleware layer performance improved by over 100x.

I think the ORM is fine. There's always some friction coming from mapping rows to classes and objects, but you can always drop down a layer and just pull raw tuples.

What I'm not a fan of, is the query DSL. Normally, the developer works to figure out how to express their problem with SQL; then the DB engine works to figure out how to map that SQL to the data it has on disk. Now Django adds another layer, which is completely unlike SQL, has its own unique pitfalls, etc; sometimes I find myself just dumping the raw SQL, working on that to get the result I wanted, then working that back to the DSL.

I think SQLAlchemy gets it right. The query language is a thin veil over SQL, and mapping to objects is an explicit and clear operation. What does feel clunky to me, is setup: SQLAlchemy expects you to bring your own glue; Django is vertically integrated.