I remember about 6 years ago I was in a huge debate with the Iwethey croud where I claimed cursor-oriented (semi-procedural) database manipulation was "better" because it closer fit the way (most) humans think. Others complained about such approach not being machine-optimizable because it loses its "mathability". My POV was that being human-friendly was more important than auto-optimization. (Many OO'ers even say they want to "wrap the persistence mechanism[1] and ugly SQL strings" to avoid having to deal with SQL.)
After thinking long and hard, I decided that the "anti-imperative" people were generally right. However, what sold me was that I realized SQL sucks as a relational language. It is not relational algebra itself that is necessarily human-unfriendly, it is SQL's view of it. Thus, I set out to create what I feel would be a more human-friendly (and meta-friendly) relational language that allows one to better decompose big problems into many smaller ones and reference the parts by names instead of the run-on nesting of SQL. SQL is fine for small, simple queries, but gets ugly real fast as things get trickier.
[1] RDBMS are far more than just about "persistence".