So in 20 years we've gone from vilifying SQL statements in code, witch-hunted folks who did this and instead invented and propped up clunky ORM implementations, ignored sage advice on the famous "object-relational impedance mismatch" (which the author claims he doesn't "believe" exists - it's not a choice btw) and now, after 20 years of agent orange in the bloody Vietnam of Computer Science, we are presenting why SQL was better all along - showing off windowing functions as examples? This is irony that took 20 years to sink in.

Am I understanding this guy's presentation correctly? (I left around the 20 min mark of the 50 min presentation).

I dunno. I think there is quite a lot of us that have consistently expressed the stupidity that is wrapping a powerful query language in a mediocre, limited, buggy, half baked, shoe horned into OO shit what was I saying?

Oh yea, ORM.

I've always veiwed it as a legitimate (though always over engineered) solution to wrap some repetitive database operations in a consistent manner.

The biggest issue with ORM isn't the solution they came up with, half baked and buggy as they are, but the problem they are actually employeed to "solve": developers afraid of SQL. Whether they can't write it, can't learn it, or just straight hate the string representation in their code, it's the main reason people sign on for ORM.

Then they prop it up with all manner of baseless reasoning.

Theb there is the leakyness. ORMs are usually quite fluid in their language, they make it easy to represent the database in code. The only issue is that it isn't there. It's a separate thing. When you see database code it should be obvious and very far away from business logic. What does ORM do? Mix it all up On purpose. Have fun with all the mocks.

Could you share some good practices for separating db code and business logic? I feel like when I don't use an ORM, there winds up being inline SQL all over the codebase.

[0] https://github.com/krisajenkins/yesql [1] https://github.com/honza/anosql