And yet for any but toy-level (and logic/relational math research) programming, you have to pay attention to how it works under the hood.
I remember university classes in Prolog. Solving logical puzzles tended to be declarative, but trying to write any actual program involved shifting to the mindset that you're dealing with a regular programming language with a built-in DFS engine underneath (the same way programming in JS involves learning you have a hidden event loop running in the background). For practical use of SQL, you need to be able to choose between equivalent queries based on how the database engine actually turns them into lookups.
> And yet for any but toy-level (and logic/relational math research) programming, you have to pay attention to how it works under the hood.
Maybe 30 years ago. It's really not so important nowadays. Computers are fast.
> For practical use of SQL, you need to be able to choose between equivalent queries based on how the database engine actually turns them into lookups.
Maybe there are some cases where you need to, but there are also million-dollar businesses that have succeeded while only ever writing their SQL queries as naively as possible. The notion that all non-toy practical uses need to understand such low-level details is just utterly false.
I remember university classes in Prolog. Solving logical puzzles tended to be declarative, but trying to write any actual program involved shifting to the mindset that you're dealing with a regular programming language with a built-in DFS engine underneath (the same way programming in JS involves learning you have a hidden event loop running in the background). For practical use of SQL, you need to be able to choose between equivalent queries based on how the database engine actually turns them into lookups.