3 ms·

"However, the slight difference in syntax makes Python dramatically easier to read and write" Please prove it.

xapata 8y ago
The evidence is in the usage. As I said, Javascript decided it was a bad idea, despite its popularity in Python. Your phrasing is a little aggressive, so I'm guessing this is one of those discussions where there's no real chance to change your mind, but I'll give it a shot. Consider one of the most friendly languages, SQL. Python comprehensions follow the same pattern as SQL. SELECT expression FROM table WHERE condition [expression for name in sequence if condition] Javascript put the expression at the end. [for (name of iterable) if (condition) expression] Putting the expression first makes the language more declarative. The easiest languages -- SQL, HTML, etc. -- are declarative, not procedural or functional.
- KirinDave 8y ago
  > The evidence is in the usage. That's not what I asked for. You're asking me to accept a concrete proposition that I obviously don't. To sway me, I'd like proof, not a single example labeled evidence.
  - xapata 8y ago
    Proof? Describe what proof means to you. The fact that Javascript decided not to adopt the syntax seems like good evidence to me. I'm not asking you to do anything. I'm offering you some insights. Normally people pay me for my time, but I suppose I feel like volunteering at the moment.
    - KirinDave 8y ago
      The fact that python decided to use a different syntax doesn't prove that it was good either. What you volunteered to me is a mirror image of an argument you think I presented, then suggested my version was wrong. But I'm not actually advocating for JavaScript syntax here. I just don't think list comprehension syntax, as presented by python, is particularly better in comparison. You said it's much better, then demanded that I agree with you.
      - xapata 8y ago
        Demanded? I ain't demanding shit. Certainly not of a stranger on the internet.
- wwweston 8y ago
  > 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

The evidence is in the usage. As I said, Javascript decided it was a bad idea, despite its popularity in Python. Your phrasing is a little aggressive, so I'm guessing this is one of those discussions where there's no real chance to change your mind, but I'll give it a shot. Consider one of the most friendly languages, SQL. Python comprehensions follow the same pattern as SQL. SELECT expression FROM table WHERE condition [expression for name in sequence if condition] Javascript put the expression at the end. [for (name of iterable) if (condition) expression] Putting the expression first makes the language more declarative. The easiest languages -- SQL, HTML, etc. -- are declarative, not procedural or functional.

KirinDave 8y ago
> The evidence is in the usage. That's not what I asked for. You're asking me to accept a concrete proposition that I obviously don't. To sway me, I'd like proof, not a single example labeled evidence.
- xapata 8y ago
  Proof? Describe what proof means to you. The fact that Javascript decided not to adopt the syntax seems like good evidence to me. I'm not asking you to do anything. I'm offering you some insights. Normally people pay me for my time, but I suppose I feel like volunteering at the moment.
  - KirinDave 8y ago
    The fact that python decided to use a different syntax doesn't prove that it was good either. What you volunteered to me is a mirror image of an argument you think I presented, then suggested my version was wrong. But I'm not actually advocating for JavaScript syntax here. I just don't think list comprehension syntax, as presented by python, is particularly better in comparison. You said it's much better, then demanded that I agree with you.
    - xapata 8y ago
      Demanded? I ain't demanding shit. Certainly not of a stranger on the internet.
wwweston 8y ago
> 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