> People expect a map/filter method

Do they? After too many functional battles I started practicing what I'm jokingly calling "Debugging-Driven Development" and just like TDD keeps the design decisions in mind to allow for testability from the get-go, this makes me write code that will be trivially easy to debug (specially printf-guided debugging and step-by-step execution debugging)

Like, adding a printf in the middle of a for loop, without even needing to understand the logic of the loop. Just make a new line and write a printf. I grew tired of all those tight chains of code that iterate beautifully but later when in a hurry at 3am on a Sunday are hell to decompose and debug.

▲

kace91 4 days ago | parent | next [-]

I'm not a hard defender of functional programming in general, mind you.

It's just that a ridiculous amount of steps in real world problems can be summarised as 'reshape this data', 'give me a subset of this set', or 'aggregate this data by this field'.

Loops are, IMO, very bad at expressing those common concepts briefly and clearly. They take a lot of screen space, usually accesory variables, and it isn't immediately clear from just seing a for block what you're about to do - "I'm about to iterate" isn't useful information to me as a reader, are you transforming data, selecting it, aggregating it?.

The consequence is that you usually end up with tons of lines like

userIds = getIdsfromUsers(users);

where the function is just burying a loop. Compare to:

userIds = users.pluck('id')

and you save the buried utility function somewhere else.

▲

tuetuopay 4 days ago | parent | prev | next [-]

Rust has `.inspect()` for iterators, which achieves your printf debugging needs. Granted, it's a bit harder for an actual debugger, but support's quite good for now.

▲

williamdclt 4 days ago | parent | prev | next [-]

I'll agree that explicit loops are easier to debug, but that comes at the cost of being harder to write _and_ read (need to keep state in my head) _and_ being more bug-prone (because mutability).

I think it's a bad trade-off, most languages out there are moving away from it

▲

nasretdinov 4 days ago | parent [-]

There's actually one more interesting plus for the for loops that's not quite obvious in the beginning: the for-loops allow to do perform a single memory pass instead of multiple. If you're processing a large enough list it does make a significant difference because memory accesses are relatively expensive (the difference is not insignificant, the loop can be made e.g. 10x more performant by optimising memory accesses alone).

So for a large loop the code like

for i, value := source { result[i] = value * 2 + 1 }

Would be 2x faster than a loop like

for i, value := source { intermediate[i] = value * 2 }

for i, value := intermediate { result[i] = value + 1 }

▲

tuetuopay 4 days ago | parent | next [-]

Depending on your iterator implementation (or, lackthere of), the functional boils down to your first example.

For example, Rust iterators are lazily evaluated with early-exits (when filtering data), thus it's your first form but as optimized as possible. OTOH python's map/filter/etc may very well return a full list each time, like with your intermediate. [EDIT] python returns generators, so it's sane.

I would say that any sane language allowing functional-style data manipulation will have them as fast as manual for-loops. (that's why Rust bugs you with .iter()/.collect())

▲

maleldil 4 days ago | parent | next [-]

Python map/filter/zip/etc. return generators, so they're lazily evaluated.

	▲	tuetuopay 3 days ago \| parent [-]
		Thanks, I was not sure, hence the "may". Comment edited :)

▲

Capricorn2481 4 days ago | parent | prev [-]

Clojure transducers as well.

▲

kace91 4 days ago | parent | prev [-]

This is a very valid point. Loops also let you play with the iteration itself for performance, deciding to skip n steps if a condition is met for example.

I always encounter these upsides once every few years when preparing leetcode interviews, where this kind of optimization is needed for achieving acceptable results.

In daily life, however, most of these chunks of data to transform fall in one of these categories:

- small size, where readability and maintainability matters much more than performance

- living in a db, and being filtered/reshaped by the query rather than code

- being chunked for atomic processing in a queue or similar (usual when importing a big chunk of data).

- the operation itself is a standard algorithm that you just consume from a standard library that handless the loop internally.

Much like trees and recursion, most of us don’t flex that muscle often. Your mileage might vary depending of domain of course.

	▲	empath75 4 days ago \| parent [-]
		There's also that rust does a _lot_ of compiler optimizations on map/filter/reduce and it's trivially parallelizable in many cases.

▲

lenkite 4 days ago | parent | prev | next [-]

This depends on the language and IDE. Intellij Java debugger is excellent at stream debugging.

▲

const_cast 4 days ago | parent | prev [-]

Just use a real debugger. You can step into closures and stuff.

I assume, anyway. Maybe the Go debugger is kind of shitty, I don't know. But in PHP with xdebug you just use all the fancy array_* methods and then step through your closures or callables with the debugger.