4 ms·

Sure it does. For can be used for any of the following. * Mapping (producing a data structure of the same size/type) * Filtering (producing a data structure o

Sure it does. For can be used for any of the following. * Mapping (producing a data structure of the same size/type) * Filtering (producing a data structure of the same type buy smaller) * Side effects * Collecting (producing a different data structure) If you're incredibly unlucky or foolish a for loop might be doing more than one operation at a time! Assuming you're only using the return types, map, filter, and collect are very clear about having only one purpose. If that's not telling you more I don't know what is.

deleted 10y ago
[deleted]
mannykannot 10y ago
That's a fair point about map being constrained in the top-level structure of what it returns, but what map actually does depends on the function that is being mapped, and includes the possibility of more than one operation at a time - and if your language allows side-effects it can do that too. The point is that you have to look at the 'blah, blah, blah' to know what is happening (actually, the point of my original post is about extravagant claims of what simple examples demonstrate...)
- Zak 10y ago
  Sometimes you can use bit-shift operations instead of multiplication and division, but you probably shouldn't unless you're an optimizing compiler or in a situation where you're doing the job of one by hand. Likewise, you probably shouldn't use a side-effecting function with map.
  - mannykannot 10y ago
    Exactly - the mere fact that map is being used does not automatically make things better; it can be abused just as a loop can (if using a side effect in a map would be a bad idea, the reasons for it being so would presumably apply to the equivalent loop.) A more useful question is how can map, used properly, make things better, and I stand by my claim that the simple examples of the sort given in this article, and articles like it, fail to make that case.
    - Zak 10y ago
      I think map implies a data transformation without side effects. When I read 'map' in code, that's what I'm expecting. I expect I can replace 'map' with a parallel version that doesn't guarantee the order in which the elements will be processed and not change the semantics of the program. I expect that if I want to swap in an alternate function, I only need to be concerned with its ability to handle the inputs, produce the outputs and be a logically valid transformation. I have no such expectations of a loop until I've read and understood its body. I hardly have any expectations of a loop at all until I've understood the whole thing. And that's how map, used properly makes things better. It communicates what kinds of things the reader should expect it to do and not do. It reduces the cognitive load of reading the program, as if, for example, you're scanning for where a certain side effect happens, you can skip the function called by 'map' on your first pass through. It shouldn't happen there; maybe it could, but it should be pretty far down the list of places to check.
      - mannykannot 10y ago
        I don't think you are giving yourself enough credit here: it is you who has chosen to adopt good practices, not map that is obliging you to do so. Mea culpa: I have to admit that I have sometimes used side-effects in map to modify the members of a list returned by a function reading data from a stream.

deleted 10y ago

[deleted]

mannykannot 10y ago

That's a fair point about map being constrained in the top-level structure of what it returns, but what map actually does depends on the function that is being mapped, and includes the possibility of more than one operation at a time - and if your language allows side-effects it can do that too. The point is that you have to look at the 'blah, blah, blah' to know what is happening (actually, the point of my original post is about extravagant claims of what simple examples demonstrate...)

Zak 10y ago
Sometimes you can use bit-shift operations instead of multiplication and division, but you probably shouldn't unless you're an optimizing compiler or in a situation where you're doing the job of one by hand. Likewise, you probably shouldn't use a side-effecting function with map.
- mannykannot 10y ago
  Exactly - the mere fact that map is being used does not automatically make things better; it can be abused just as a loop can (if using a side effect in a map would be a bad idea, the reasons for it being so would presumably apply to the equivalent loop.) A more useful question is how can map, used properly, make things better, and I stand by my claim that the simple examples of the sort given in this article, and articles like it, fail to make that case.
  - Zak 10y ago
    I think map implies a data transformation without side effects. When I read 'map' in code, that's what I'm expecting. I expect I can replace 'map' with a parallel version that doesn't guarantee the order in which the elements will be processed and not change the semantics of the program. I expect that if I want to swap in an alternate function, I only need to be concerned with its ability to handle the inputs, produce the outputs and be a logically valid transformation. I have no such expectations of a loop until I've read and understood its body. I hardly have any expectations of a loop at all until I've understood the whole thing. And that's how map, used properly makes things better. It communicates what kinds of things the reader should expect it to do and not do. It reduces the cognitive load of reading the program, as if, for example, you're scanning for where a certain side effect happens, you can skip the function called by 'map' on your first pass through. It shouldn't happen there; maybe it could, but it should be pretty far down the list of places to check.
    - mannykannot 10y ago
      I don't think you are giving yourself enough credit here: it is you who has chosen to adopt good practices, not map that is obliging you to do so. Mea culpa: I have to admit that I have sometimes used side-effects in map to modify the members of a list returned by a function reading data from a stream.