As our favorite imperative languages gain functional constructs, should loops be considered a code smell?

Question

In allusion to Dare Obasanjo's impressions on Map, Reduce, Filter (Functional Programming in C# 3.0: How Map/Reduce/Filter can Rock your World) "With these three building blocks, you could replace the majority of the procedural for loops in your application with a single line of code. C# 3.0 doesn't just stop there."

Should we increasingly use them instead of loops? And should be having loops(instead of those three building blocks of data manipulation) be one of the metrics for coding horrors on code reviews? And why?

[NOTE] I'm not advocating fully functional programming on those codes that could be simply translated to loops(e.g. tail recursions)

Asking for politer term. Considering that the phrase "code smell" is not so diplomatic, I posted another question http://stackoverflow.com/questions/432492/whats-the-politer-word-for-code-smell about the right word for "code smell", er.. utterly bad code. Should that phrase have a place in our programming parlance?

Answer 1

Why? I vote absolutely no!

This kind of loop:

for x in list:
    ....

is acceptable, and there is nothing horrifying about it.

Answer 2

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

– Donald Knuth

Answer 3

Language history probably affects this: if language X had a 'foreach' construct up until now, most programmers will be used to it. It may take a while for the idiom to change, if at all.

Answer 4

Can we find a more polite word than 'smell'? The phrase 'code smell' should be reserved for what it's intended for: strong clues that something's been coded badly. What we have here is a gentle hint that there may be opportunities for refinement.

The fact that you have access to map/reduce/filter operations does mean that many loops over collections are an opportunity for refactoring. You might get slightly more compact and readable code (as long as the reader groks the concepts). You might get improved performance in future, if you're on a platform that can parallelise such operations.

However there will always be situations where a loop really does mean a loop. You want to do things in sequence, and the loop syntax is the clearest way to write that.

while(c=getchar) {
     // see?
}

Answer 5

It surely is very strongly discouraged to use loops when you use a language like APL, or any language naturally designed to work directly with arrays (from uni-dimensional vectors to hypercubes) without having to deal iteratively with each element. Think at adding 2 matrices: in Math you would simply write M1+M2, as anyone would program it in APL; writing a loop for this is bad programming.
C# is starting to borrow some very powerful features that made APL so efficient like Reduce (f/AVector where operator f is applied between each elements of AVector like AVector[1] f AVector[2] f ... f AVector[n]) or Take...

Answer 6

I don't feel that we should give up loops at all. If you look at what Dare is saying, he isn't recommending that either. After all, almost all the methods on the Enumerable class and in LINQ focus on returning an IEnumerable implementation.

Its all made to be iterated over.

What he is trying to say is that we can have a much cleaner separation of code with LINQ now, in that we can filter, transform, and map items in an enumeration much easier outside of a loop in a more declarative manner, rather than obfuscating the purpose of the loop itself, which is usually to act on a set of those filtered items, transformations, and maps.

Answer 7

I programmed smalltalk 15 years ago. I remember quite a lot of it, but I can't even remember if smalltalk had for-each iteration (so it couldn't have been very important). Since we're reinventing/rediscovering all this stuff again, I believe history has the answer.

Answer 8

@grettke : +1 for this Knuth quote!

All the constructs we have (loops, recursion, goto, regex replacements, function calls, ...) can be used wisely or can be misused to write completely obscure code. Banning one of them would just be useless.

Dogmatic views like "all is a function", "all is an object", etc are more harmful than useful. One would end up force-fitting into a predefined scheme sacrificing clarity (that should be the first and foremost concern while writing code).

Its a deeply nested "loops construct" bad when a simpler "concatenation of function calls" could be used? YES!

It's a long recursive "concatenation of function calls" bad when a simpler "loop" could be used? YES!

So, please, give me the freedom of using what I feel best to express what I mean in my code and blame me for the mess, not the language!

Answer 9

It depends. If the for-loop accurately expresses the intent of the code: "do these things in this particular order, one at a time", then it's all good.

On the other hand, if you really meant "do these things in no particular order, and it's OK to do more than one at once", then you really wanted something functional (e.g. Parallel LINQ).