3 ms·

just checking to be sure, your example is essentially original.filter(...).map(...).sort(), which in python would be `sorted([... for x in original if ...], ..

by zardeh 10y ago

just checking to be sure, your example is essentially original.filter(...).map(...).sort(), which in python would be `sorted([... for x in original if ...], ...)`. I'll agree that sometimes the functional/chainable approach is nicer, but often it also isn't necessary

kbenson 10y ago
> just checking to be sure, your example is essentially original.filter(...).map(...).sort() Yes, a method chaining format (such as Ruby and JS, and which can be enabled with a module in Perl) does approximate the control flow I'm referring to, The only different to the feed operator in Perl 6 is that the feed works on a per-item basis, allowing the list to be lazily generated, which also means it's a closer approximation to how you would code it in a for loop, as statements are done in succession on each item. E.g. my @source = 1..Inf; my @elevensies = ( @source ==> map { $_*11 } ); my @odd-elevensies = ( @elevensies ==> grep *%2 ); my @root-of-odd-elevensies = ( @odd-elevensies ==> map *.sqrt ); Although in this case the left feed operator may be clearer. > which in python would be `sorted([... for x in original if ...], ...)`. > I'll agree that sometimes the functional/chainable approach is nicer, but often it also isn't necessary Well, the example I gave was simplistic and to show direction. A more complex example would require a comprehension of a comprehension, which is where I start to have real issues with the format, and which is not represented from that example, which wasn't meant to illustrate that particular problem.
- icebraining 10y ago
  Your example translated to Python is also lazily generated (it uses the lazy equivalent of list comprehensions, called generator expressions): source = count(1) elevensies = (x * 11 for x in source) odd_elevensies = (x for x in elevensies if x%2) root_of_odd_elevensies = (math.sqrt(x) for x in odd_elevensies) To me, the examples seem fairly equivalent, with the exception that Python's is, in my opinion, more readable for a newbie, since it doesn't require knowing map() or grep() - just for loops and ifs.
  - kbenson 10y ago
    I was aware of generators in python, but I wasn't aware of the lazy lest comprehensions, which is very nice. I agree list comprehensions in the simple form are easier for a newbie to recognize, but I also like the way map and filter make you think about your actions, and think they are clearer in the less trivial cases (as I mentioned above). I say "filter" because while I am completely familiar with that terminology, I accept that it's an unneeded departure from the common terminology for that task.
    - icebraining 10y ago
      Well, map and filter may be more clear in certain cases, but I still don't see how they are more powerful. Seems like you can do a 1-for-1 translation between the two.
      - kbenson 10y ago
        Oh, that's because you must have missed a few comments back where I agreed with you and backed out on any claim they were strictly more powerful. ;)
        icebraining 10y ago
        Ah, uh, sorry ;)

by zardeh 10y ago

kbenson 10y ago

> just checking to be sure, your example is essentially original.filter(...).map(...).sort() Yes, a method chaining format (such as Ruby and JS, and which can be enabled with a module in Perl) does approximate the control flow I'm referring to, The only different to the feed operator in Perl 6 is that the feed works on a per-item basis, allowing the list to be lazily generated, which also means it's a closer approximation to how you would code it in a for loop, as statements are done in succession on each item. E.g. my @source = 1..Inf; my @elevensies = ( @source ==> map { $_*11 } ); my @odd-elevensies = ( @elevensies ==> grep *%2 ); my @root-of-odd-elevensies = ( @odd-elevensies ==> map *.sqrt ); Although in this case the left feed operator may be clearer. > which in python would be `sorted([... for x in original if ...], ...)`. > I'll agree that sometimes the functional/chainable approach is nicer, but often it also isn't necessary Well, the example I gave was simplistic and to show direction. A more complex example would require a comprehension of a comprehension, which is where I start to have real issues with the format, and which is not represented from that example, which wasn't meant to illustrate that particular problem.

icebraining 10y ago
Your example translated to Python is also lazily generated (it uses the lazy equivalent of list comprehensions, called generator expressions): source = count(1) elevensies = (x * 11 for x in source) odd_elevensies = (x for x in elevensies if x%2) root_of_odd_elevensies = (math.sqrt(x) for x in odd_elevensies) To me, the examples seem fairly equivalent, with the exception that Python's is, in my opinion, more readable for a newbie, since it doesn't require knowing map() or grep() - just for loops and ifs.
- kbenson 10y ago
  I was aware of generators in python, but I wasn't aware of the lazy lest comprehensions, which is very nice. I agree list comprehensions in the simple form are easier for a newbie to recognize, but I also like the way map and filter make you think about your actions, and think they are clearer in the less trivial cases (as I mentioned above). I say "filter" because while I am completely familiar with that terminology, I accept that it's an unneeded departure from the common terminology for that task.
  - icebraining 10y ago
    Well, map and filter may be more clear in certain cases, but I still don't see how they are more powerful. Seems like you can do a 1-for-1 translation between the two.
    - kbenson 10y ago
      Oh, that's because you must have missed a few comments back where I agreed with you and backed out on any claim they were strictly more powerful. ;)
      - icebraining 10y ago
        Ah, uh, sorry ;)