> Why the obsession with avoiding "programming the machine"?

I think that programmers who think that ORMs improve upon SQL are making the same mistake that I infer from this quote of yours.

Of the two approaches, SQL is the high-level, abstract DSL for doing the business logic you want, and ORMs are the low-level, implementation-specific technologies which you can push around with loops and conditionals.

People who choose ORMs probably do so because they perceive them to be the higher-level abstractions. But that's why I choose SQL.

Personally I use the Rails ORM for simple things as it's just a lot quicker and easier than direct SQL. But sometimes when the query is complex, I drop down to SQL.

Scared is a poor word choice.

ORMs can allow for flexibility in database engine choice. They can also prevent some basic mistakes like Bobby Tables. An ORM may rapidly accelerate development.

Ultimately, the answer may be because an ORM/abstraction library is the better choice.

Why not ask these so-called scared developers why they choose to use ORMs?

I'm not sure exactly what you're seeing but I do see a trend of Postgres products focussed on the frontend app developer e.g. Supabase, Neon.

Those developers are used to dealing with objects and types and SQL is a step further removed from what they're comfortable with.

Because SQL isn't properly composable. You can do simple stuff like parameters to avoid blatant injection attacks. But for any remotely complex branching logic, you're back to string concatenation. This is historically an area ripe for security flaws and bugs. Many devs rightfully seek out tools that provide a layer for composing logic with slightly more sanity.

That said, if you're using a generic SQL abstraction layer, you're not really using Postgres per se. You're using a small subset of it. JSONB documents, full text search, powerful aggregates, materialized views, derived columns, geospatial data operations, time series analytics, statistical inference engines... so much power available with a few SQL statements. It is a shame to see most of it lost behind an ORM.

I think the best we can do is use ORM-ish tools for the basic stuff but always have an escape hatch where you can (safely) drop down to raw SQL when necessary. We shouldn't be scared to use it, but it is a sharp weapon. Wield wisely.

> Because SQL isn't properly composable.

The different approaches have different composition problems. The 'n+1 query problem' is an example of an ORM not composing correctly.

Well that's getting into the quality of the abstraction. Not all ORMs suffer this, most good ones give you a way around the n+1 problem.