> Listen to how people who don't program describe the task of transforming each element of something. In my experience they often say something along the lines

> Listen to how people who don't program describe the task of transforming each element of something. In my experience they often say something along the lines of, "I want y for each x in z," rather than, "For each x in z, I want y." If we're really at the point where we're arguing between which clause order (among other potential variations in expression) is more natural across most natural language speakers, that should about wrap it up. But to the extent that it doesn't, this assertion has the merit that it sounds like an empirically verifiable position. > Ask some random person off the street to read your source code. Which is worth considering, I suppose, in situations where the relevant software is being built by people being brought in off the street. > [SQL] is exactly the domain we're talking about when discussing comprehensions. "Exactly" overstates the case. As I said above, I recognize it's a related domain, but there's plenty of things that are easier to do with Python or Javascript than they are in SQL, even specifically with operations over every tuple in a set. And again, declarative == easier is overgeneral assumption. Take Prolog, for example. Definitely domain-overlapped with SQL, often a poster child for declarative. I quite like it myself, but it's not always a hit at parties. Even hackathon parties.