He didn't really. The SQL is right there, and this is important.
What I've experienced (unfortunately) across multiple projects is that people who understand databases will write SQL with a nice collection of helper and wrapper functions as needed, and the people that think that databases are mysterious black boxes will reach for ORM. I've seen the ORM-happy teams getting scared at the idea of a million (1,000,000!) rows in a table, and they always neglect to set up even basic indexes or to think through what their JOINs are really doing.
YMMV but that's the pattern I see again and again.
Well, the SQL is always somewhere. If you use an ORM library, even if you use ActiveRecord, you will find some SQL in it. In the end, it always translates to SQL.
In the blogpost, the writer created a User Python object ("O"). A corresponding (R) database row will be mapped (M) to the object. That's basically ORM. Not as heavy as the usual libraries that support relationships etc, but still, ORM.
Good ORMs provide the best of both worlds. Basic tasks such as loading a single object from the database by ID and then writing it back after changes are made shouldn't require you to write any SQL, because everyone already knows what that SQL looks like, just let the ORM do it for you. A query builder component that allows you to programmatically build queries of medium complexity is also essential. And for anything not covered in the previous two cases, it should be possible to just write raw SQL or something like it without the ORM fighting you for it.
My preferred ORM is Doctrine and it provides all of these features. It has its own variant of SQL called DQL that lets you effectively write complex select queries as raw SQL with a bunch of object-specific conveniences built in, and get back an array of objects.
And from my experience, forcing people who know nothing about databases to write SQL will not make them learn about databases, all you end up with is worse SQL and more injections.
Although the worse offenders by far are those which decide ORM = bad and bypass it at every opportunity.
So let's ban ORMs because newbies don't know the entire toolchain. Yes, that will definitely solve it.
Why stop there? Let's ban RDBMS. If you can't contemplate a binary file structure and index strategy perfectly tailored to your application's needs ahead of using an RDBMS, why should we deign to let you use an abstraction layer with clever query planning and algorithms?
It's all too easy to morally 'ban' people from technology and gatekeep it behind wishy-washy nonsense like "ORMs are bad for beginners."
sqlalchemy allows you to separate ORM from SQL and combine them when needed. the idea that 'ORM == you don't have to write SQL and/or you can't write SQL' is, please excuse my strong words here, wrong.
my biggest gripe with sqlalchemy is that sometimes I know what I need to write in SQL (have a working prototype usually) and have trouble mapping the concept to sqlalchemy.core constructs, but that's mostly inexperience.
What I've experienced (unfortunately) across multiple projects is that people who understand databases will write SQL with a nice collection of helper and wrapper functions as needed, and the people that think that databases are mysterious black boxes will reach for ORM. I've seen the ORM-happy teams getting scared at the idea of a million (1,000,000!) rows in a table, and they always neglect to set up even basic indexes or to think through what their JOINs are really doing.
YMMV but that's the pattern I see again and again.