> ...by far the biggest cognitive problem that they have with this language is understanding what the interpreter is doing at any point in time. Prolog’s attempt at being declarative ... is the problem: how to get a computer to do something without telling it what to do?

I mean, people use SQL just fine without understanding how the DB is going to accomplish their queries.

Maybe Prolog just doesn't have the same level of tooling as SQL for deducing "what's going to happen", e.g. an equivalent to SQL's `EXPLAIN ANALYZE`?

> The traversal of a search space in which choice-points are introduced whenever multiple clauses match the current computational goal and a process of (possibly partial) variable instantiation ... and worse of all, the order in which you wrote your clauses in the program makes a difference to how it gets executed and, indeed, whether any part of the program is reachable.

Some people (more than use Prolog) use Erlang—even the parts like chained binary pattern-matching†—just fine. And some people (still more than use Prolog) use the MLs just fine, too, including functional combinators and passing around monadic bindings, despite this playing utter hell on determining "whether any part of the program is reachable."

† `foo(<<A/32,B/A,Rest/binary>>)` — an Erlang clause-head which takes a binary string, and attempts to unify the variable A with the first four bytes of it, and B with the next variable-A bytes of it, and Rest with, well, the rest of it. I.e. A is taken as a uint32 and used to calculate the bounds of a slice on B, all during the attempt to pick a clause to execute. This is common, idiomatic code.

> That this process of computation is difficult to grok is especially noticable when you try to debug a Prolog program. Computations get undone when attempts at satisfying a goal fail...

People write Solidity code for the Ethereum VM just fine. (In fact, this one is kind of hilarious; Prolog is less popular than even an arcane programming environment like the EVM—where all function calls are implicitly nested MVCC transactions that roll back any side-effects upon their Turing-machine substrate upon any trap or fault, including even rolling back the emission of logging statements and the reservation or nullification of memory.)