Software development topics I've changed my mind on

> ORMs are the devil in all languages and all implementations. Just write the damn SQL

It depends on what you're writing. I've seen enough projects writing raw SQL because of aversion to ORMs being bogged down in reinventing a lot of what ORMs offer. Like with other choices it is too often a premature optimization (for perf or DX) and a sign of prioritizing a sense of craftsmanship at the expense of the deliverables and the sanity of other team members.

It's not so much optimization but experience that on any sufficiently large project you gonna run into ORM limitation and end up with mix of ORM and direct queries. So might as well...

Starting with raw SQL is fun. But at some point you find out you need some caching here, then there, then you have a bunch of custom disconnected caches having bugs with invalidation. Then you need lazy loading and fetch graphs. Step by step you'll build your own (shitty) ORM.

Same thing for people claiming they don't need any frameworks.

> you find out you need some caching here, then there

Forgive my ignorance, but how do ORMs help with adding caching? Or are you implying they obviate or reduce the need for caching?

They do caching themselves so that some of your queries via ORM won’t hit the actual db.

So, given the main issue with ORM is the object/relational part... (https://web.archive.org/web/20160301022121/http://www.revisi...)

Why is caching not a feature in DB connection pools? I mean, most databases have it on their side, why not have it as an option for the same query sets prior to hitting the db, with configurable invalidations? Or is it, and I've just never thought to look for it.

That would be a result set layer, not a connection pool. Could make sense if you worked with rows, but if you use ORM, why mapping cached row again and again? ORMs cache hydrated objects, which seems to be more efficient.