5 ms·

Can you explain why you think it makes O(n) blocks trivial to identify? How is such identification made easier by manually writing out a `for` loop applying a

by h_r 7y ago

Can you explain why you think it makes O(n) blocks trivial to identify? How is such identification made easier by manually writing out a `for` loop applying a function foo to each element rather than writing `map foo myCollection`?

tfha 7y ago
The way many people read code, it's much easier to overlook three characters than it is to overlook three lines with indentation.
- h_r 7y ago
  That's quite an interesting, if frightening, take on it. Assuming a developer knows what `map` does, then I wouldn't have very much confidence in their reading comprehension if they somehow mentally skipped over the main higher order function being called on a three word line of code. Would anyone expect such a developer to read and parse several more lines of code more reliably, in order to understand the algorithmic complexity? Seems unwarranted to me...
  - tfha 7y ago
    Humans make mistakes. People code review after exhausting days or late at night. Or sometimes they skim more than they intended to. You want to make problems in the code obvious everywhere that you can. In programming, if you miss an important detail the repercussions can be high. In a million line codebase every idiom that's slightly more complex than it needs to be is going to result in dozens of additional bugs, sheerly because of the increased surface area for making mistakes with that idiom.
    - h_r 7y ago
      I agree with everything you've said here but being mentally exhausted doesn't make it more likely that you can read even more lines of code in a more reliable fashion. I think the clue to your thinking, for me, is in your description of the `map` HOF as "slightly more complex". Having years of experience with both paradigms, I've found that grokking a call to one of these fundamental building blocks (map, filter, reduce, fold, etc) is nearly instantaneous. We've all experienced reading prose where the author was excessively verbose when the same point could have been made succinctly. It feels the same way reading for loops once you get over the learning curve of these very basic functional constructs. You have to keep repeating that boilerplate endlessly and it's very tedious to keep writing and reading it.
    - ernst_klim 7y ago
      > Humans make mistakes. Yeah, and it's much easier to make mistake with a loop than with a map or filter.
kjksf 7y ago
In every mainstream language I can think of `map foo myCollection` creates an intermediary map. Memory allocation is so expensive that making that copy is often more expensive that calling `foo` on each element. Sometimes making a copy is exactly what you need and there's no way around that cost (but hold that thought). But I've also seen `sum map foo myCollection` so many times (especially in JavaScript). Here you have a short, neat but also extremely wasteful way of doing things. I see it so frequently that I assume that many people are unaware of this cost (or completely disregard performance concerns). If you were to write this imperatively, it would be obvious that you're making a copy and maybe you would stop and re-think your approach. But there's more. If you're paying attention to performance, an easy way to improve performance of `map foo myCollection` in e.g. Go is to pre-allocate the resulting array. For large arrays, this avoid re-allocating of underlying memory over and over again, which is the best a `map` can do. In imperative code those costs are more visible. When you have to type that code that does memory allocation, you suddenly realize that the equivalent of `map` is extremely wasteful.
- LandR 7y ago
  >> In every mainstream language I can think of `map foo myCollection` creates an intermediary map. Language support for Transducers can fix this, you can compose functions like map / filter / reduce over a collection and only hit each item once.
  - erik_seaberg 7y ago
    Even Java can do this. You only pay for another Collection<T> if you actually #collect the elements of a Stream<T>.
- Gaelan 7y ago
  Is Rust mainstream? If so, this code: numbers.iter().map(|n| { ... }).sum(); Compiles to a plain loop, with no allocation.
  - steveklabnik 7y ago
    (You want for_each not map, by the way)

by h_r 7y ago

tfha 7y ago

The way many people read code, it's much easier to overlook three characters than it is to overlook three lines with indentation.

h_r 7y ago
That's quite an interesting, if frightening, take on it. Assuming a developer knows what `map` does, then I wouldn't have very much confidence in their reading comprehension if they somehow mentally skipped over the main higher order function being called on a three word line of code. Would anyone expect such a developer to read and parse several more lines of code more reliably, in order to understand the algorithmic complexity? Seems unwarranted to me...
- tfha 7y ago
  Humans make mistakes. People code review after exhausting days or late at night. Or sometimes they skim more than they intended to. You want to make problems in the code obvious everywhere that you can. In programming, if you miss an important detail the repercussions can be high. In a million line codebase every idiom that's slightly more complex than it needs to be is going to result in dozens of additional bugs, sheerly because of the increased surface area for making mistakes with that idiom.
  - h_r 7y ago
    I agree with everything you've said here but being mentally exhausted doesn't make it more likely that you can read even more lines of code in a more reliable fashion. I think the clue to your thinking, for me, is in your description of the `map` HOF as "slightly more complex". Having years of experience with both paradigms, I've found that grokking a call to one of these fundamental building blocks (map, filter, reduce, fold, etc) is nearly instantaneous. We've all experienced reading prose where the author was excessively verbose when the same point could have been made succinctly. It feels the same way reading for loops once you get over the learning curve of these very basic functional constructs. You have to keep repeating that boilerplate endlessly and it's very tedious to keep writing and reading it.
  - ernst_klim 7y ago
    > Humans make mistakes. Yeah, and it's much easier to make mistake with a loop than with a map or filter.

kjksf 7y ago

In every mainstream language I can think of `map foo myCollection` creates an intermediary map. Memory allocation is so expensive that making that copy is often more expensive that calling `foo` on each element. Sometimes making a copy is exactly what you need and there's no way around that cost (but hold that thought). But I've also seen `sum map foo myCollection` so many times (especially in JavaScript). Here you have a short, neat but also extremely wasteful way of doing things. I see it so frequently that I assume that many people are unaware of this cost (or completely disregard performance concerns). If you were to write this imperatively, it would be obvious that you're making a copy and maybe you would stop and re-think your approach. But there's more. If you're paying attention to performance, an easy way to improve performance of `map foo myCollection` in e.g. Go is to pre-allocate the resulting array. For large arrays, this avoid re-allocating of underlying memory over and over again, which is the best a `map` can do. In imperative code those costs are more visible. When you have to type that code that does memory allocation, you suddenly realize that the equivalent of `map` is extremely wasteful.

LandR 7y ago
>> In every mainstream language I can think of `map foo myCollection` creates an intermediary map. Language support for Transducers can fix this, you can compose functions like map / filter / reduce over a collection and only hit each item once.
- erik_seaberg 7y ago
  Even Java can do this. You only pay for another Collection<T> if you actually #collect the elements of a Stream<T>.
Gaelan 7y ago
Is Rust mainstream? If so, this code: numbers.iter().map(|n| { ... }).sum(); Compiles to a plain loop, with no allocation.
- steveklabnik 7y ago
  (You want for_each not map, by the way)