[Cthulhu_]

It does though. Maps and folds - and functional programming in general - focuses on the /what/. For-loops on the other hand tell the compiler / cpu the /how/.

Summing is a nice example. A naive for-loop will just iterate through the list, keep a variable around, add the next item in the list to it. In functional programming (or with a reduce), you tell it to sum in a more concise way - but more importantly, you don't tell the compiler how exactly it should do it. It's trivial with functional programming to make the task (for example) multithreaded or to use advanced underlying cpu tricks, without you as a developer needing to know how exactly it does what you ask it to.

[ridiculous_fish]

Consider product as a counter-example. With an imperative loop, it's easy to add an early-out condition if zero is encountered. But this is harder to do in a (strict) functional language.

[Athas]

This is exactly why lazy evaluation is often described as control-flow. Lazy evaluation permits efficient composition, without doing extra work (although the constant factors become much larger).

[sagichmal]

Yes, that's exactly right. And Go takes a relatively strict stance on making the _how_ obvious to the programmer. It goes out of its way to avoid hiding O(n^k) loops behind language sugar like map or fold, for example.

[kibwen]

> O(n^k) loops

I'm unclear where algorithmic complexity is coming into this. Can you clarify what you're trying to imply?

[Scriptor]

map doesn't do any magic behind the scenes, it goes through a sequence exactly once.

Can you given an example where map might increase algorithmic complexity like that where the imperative version would not?

[sagichmal]

Map hides a loop behind a statement. That's all I meant.

[Scriptor]

You can hide a loop behind a function call in Go, Python, really any imperative language.

What makes map different is that it separates the looping mechanics (incrementing, initializing and appending to the collection) from the actual computation we want to perform on each element. It's just separation of concerns.

[sagichmal]

Yes. In Go, function and method calls are the primarily, perhaps only, mechanism of abstracting computational complexity. That is, when you see a function or method call, you know that "anything goes" back there, and you need to dig and find out what the computer is gonna be doing. Pretty much everything else is implemented "in plain sight"; in the case of fold/map, that means with a for loop, where you see precisely how many iterations you're going to step through.

You're right: map separates looping mechanics from computation. In Go, that's a bit too much obscurity.