What does he not understand?

an ORM is a library to map objects onto a relational database. They're not a substitute for databases themselves, but a substitute for a DB interaction library.

ie: To use an ORM you must use a relational database. Things like mongoose exist, but they're not ORMs since they don't map objects to a relational database.

I see what you mean. I thought he was mocking the idea of wrapping the old uncool relational model in a fashionable new OO API.

What is substituted is not the relational DBMS but the relational model. ORMs are supposed to let you think in terms of objects instead of sets of tuples.

No, turns out most sql work involves extracting data from the resulting sql statement into objects. So you don't end up passing 5 params from the sql result everywhere.

ORMs do these automatically, and go beyond.

That's true for some basic CRUD operations and that's what ORMs should be used for.

But people tend to just blindly copy everything into an object model and perform operations on those objects that could just as well have been done in a set oriented way with a lot less code causing a lot less network traffic.

Obviously there are scalability downsides and not everything is easier to express in terms of sets, so I try to be pragmatic. You can of course do set operations through an ORM but that's not its purpose and the performance implications are sometimes tricky.

Most orms have something equivalent to HQL/LINQ. HQL allows you to use set operations, which then gets translated into its equivalent sql statement. Thus no extra objects get transferred across the network.

However there is one thing, most ORMs by default transfer the whole object. What is you only need a few variables?