[djur]

This reminds me of the attitude held by some Go developers (and Rob Pike) that the reason people want map/filter/reduce and similar generic functions on containers is because they want "less code", and the counter is that a for loop is "more explicit", "clearer", "less magical", and so on.

But for someone who is used to languages where these constructs (or list comprehensions) are idiomatic, they are perfectly clear and explicit, and using a for loop instead adds complexity.

[yen223]

If you're interested in what the code is trying to achieve, then `map`, `filter` and the like is clearly more explicit.

If you're interested in what actually gets executed (if you're trying to optimize for performance, say), then the `for` loop is clearly explicit than the abstract counterparts.

It depends on what what you're looking for.

[lmm]

> If you're interested in what actually gets executed (if you're trying to optimize for performance, say), then the `for` loop is clearly explicit than the abstract counterparts.

In what language? GCC will happily not just optimize away your counter variable but perhaps even replace your whole loop with an SIMD operation; I suspect the Go compiler will do the same.

Also, if you're trying to optimize for performance then looking at what code gets executed is (to first order) useless; the dominant factor is cache efficiency and you can't see cache hits/misses by reading the code.

[yen223]

`map` can compile to wildly different things depending on what you're mapping over.

Cache efficiency is important, but so is not running O(n^2) algorithms when you didn't mean to. The latter has an outsized impact on the performance of a program, and explicit loops makes it very clear when something's up.

[lmm]

> explicit loops makes it very clear when something's up.

Disagree. Explicit loops hide the essence of what's happening beneath a pile of ceremony. It's easier to spot accidentally O(n^2) code in map-style code where it's a lot clearer what the code's doing.

[baby]

My 2 cents: I like functional programming style but it’s annoying to have both. I like that in Golang there’s usually one way to do it, even if it’s more code. Eventually most codebases look like they’re all part of the same codebase and it’s much easier to read. In Rust people alternate between for loops and map and it really takes a while to get used to the different ways people write rust.