12 ms·

> The evidence is in the usage... It's possible it was not adopted because there's a cost involved in every feature that has inconsistent support across runti

> The evidence is in the usage... It's possible it was not adopted because there's a cost involved in every feature that has inconsistent support across runtime. The benefit needs to outweigh that cost. > Putting the expression first makes the language more declarative The case for a specific order makes less sense in a declarative language, not more. And: [1,2,3,4].map((x) => x * 2) Doesn't seem substantially more or less declarative than: [x * * 2 for x in range(1,5)] to me. If anything, the latter example asks more of the reader because it requires an awareness of case-specific semantics. And overall, it's simply never been clear to me what comprehensions buy in terms of readability or semantics over map/reduce/etc, and given JS cultural buy-in on some imported concepts from FP, my guess is that the marginal benefit just didn't seem worth the cost rather than it being a misstep in the specific proposed JS syntax. Also: SQL has its points, but it's not a language I'd generally describe as easiest. Declarative DSLs tend to be largely convenient only in their domain. It may be worth admitting SQL to this discussion I suppose given the overlap between its domain and map or foreach like concepts, but is it really strictly easier to reason about how to do something this particular thing in it (and what it's actually doing) than either Python or JS? I don't think that's as straightforward an argument as you seem to have assumed.

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.

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.