[Daishiman]

Nobody who builds an ORM thinks that.

An ORM saves experienced SQL users from having to write boilerplate SQL and hack on their own garbage ORM, which is what any large project ends up doing, attempting to compose queries and filters in vain.

I have never ever heard of ORMs as an argument to avoid learning SQL, and AFAIK no author of well-known ORMs holds that opinion.

[andrewingram]

Yeah, my SQL is admittedly rusty due to not hand-writing many queries these days, but my motivation for using an ORM isn't "I can't write SQL", it's that I don't want to be engaging in string building when there are better abstractions available for supporting this kind of operational composition.

The problem with ORMs, as I see it, is that their abstraction is typically too high level and rarely offers you an intermediate layer to let you work around the leaks.

So you often have:

  ORM -> SQL

Which is implemented as:

  ORM -> private query-builder API -> SQL

When what I want is:

  ORM -> public query-builder API -> public SQL-like abstraction -> SQL

[doteka]

Anecdata: in every single company I worked, tiny startups and giant corporations alike, “not everyone knows SQL well” was exactly the argument used to justify the ORM. Every single time, the people who do not know SQL, unsurprisingly, proceeded to write pathological N+1 queries.

I don’t mind much - I get to look like a hero to my manager making their queries orders of magnitude faster. But if someone can’t be bothered to write SQL, they for sure will not bother looking up ways to hint the ORM.

[jtdev]

"boilerplate SQL" is an oxymoron...

Literally every pro-ORM dev that I've ever worked with was so incredibly weak with basic SQL fundamentals that I must conclude that they preferred ORMs simply due to a reluctance to learn SQL.

[yebyen]

There is a strong argument for conceptual compression, the idea that every component has an optimum abstraction layer to understand it at, and with that, less-optimum layers for understanding. An ORM that does its job well allows you to take the complexity and pack it away for another day. We can unpack it later when we need to understand those details, but most of the time we'd rather be focused on the details of a domain-specific problem that we're trying to solve, with intricacies that are specific to the domain, that ideally need not become compounded against problems introduced separately by (for example) a persistence layer such as a database, as that makes it harder for the domain experts by introducing another layer of complexity that they must grok in order to build or spec an appropriate solution.

[Daishiman]

Your industry experience is minimal then.