3 ms·
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
by xapata 8y ago
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." The latter is more common among people who've been programming in certain languages, not the average person. I don't have systematic data collection for this, just personal experience. But the Javascript decision adds some evidence, in my view.
> it's simply never been clear to me what comprehensions buy in terms of readability or semantics over map/reduce/etc
Ask some random person off the street to read your source code. They're more likely to get the gist of code using comprehensions than code using map/reduce/etc.
> SQL ... convenient only in [its] domain.
Which is exactly the domain we're talking about when discussing comprehensions.
- wwweston 8y ago> 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.
- xapata 8y ago> empirically verifiable I'd love to see the data. > software ... built by people ... off the street Programming is such a rapidly growing field that I think the majority of software will be written by programmers with less than 1 year experience. For a time, anyway. Maybe in 20 or 30 years the growth will slow.