I disagree with both of you. I think you're underestimating what can be done in SQL--recursive queries and correlated subqueries are not part of most competent

I disagree with both of you. I think you're underestimating what can be done in SQL--recursive queries and correlated subqueries are not part of most competent developers' "standard toolkit"--but I think you're illustrating the problem with the OP's point, which is that most competent developers get through joins and outer joins (usually inheriting a lot of weird mythology like "joins are expensive") and can select/project and that's about where the skills end. So while I disagree with you in principle, in practice most people's SQL skills are inadequate even for an analogy to functional programming. I would not say that the thought process I use when writing SQL queries is "more like" my thought process when doing functional programming than imperative programming. In truth, the similarity is all in what isn't present: I'm not deeply worried about what the machine is going to do with my request and how it's going to process it. I remain cognizant of what's "really happening" to the extent that I want to avoid obvious performance pitfalls, but it doesn't become the overriding obsession that it is with procedural programming. With declarative programming I worry much less about whether the result is correct, and this is the primary benefit to me.