Less loops, less bugs
In programming, it’s a known fact that the more lines a program has, the more bugs it has. Several studies reached this conclusion in the past and some of them even went as far as trying to predict the average number of programming mistakes per line. The number is not important, but the conclusion is, and it has led to the creation of the motto "less code, less bugs".
An intuition I have, without any proof, is that we could also conclude "less loops, less bugs", and I’ll explain why. Loops are the most complex constructions programming languages have. It’s obvious that a list of ordered steps are easy to understand and follow. Those are the typical sentence sequences in the form "do this, then do that, later that other thing". Increasing in complexity, we have the if/else constructions. Those are more complex but, unless the bodies are very long and nested, you can still mentally trace what you are doing when you read a program from the top to the bottom. Loops are a different thing, however. A loop requires planning and does "more" than what is writen. Except for simple loops, many times you can’t read the loop and know what it does. You need to trace the loop behaviour, in your mind or on paper. There’s a condition on when to stop, and variables that change its contents based on previous steps, until the loop stops and concludes its assigned job. Most programmers at least put comments above loops to indicate what they do, and in which variables they leave the desired result. Some others go beyond that and explicitly write the loop invariant, so as to have the proof that the loop does what it says it does, like if the loop involved some kind of "magic".
In any case, it’s obvious that writing a loop requires planning and reading it requires an extra effort. This difficulty makes loops, in my opinion, more error-prone than any other programming construction. So, basically, we have "less code, less bugs" and "less loops, less bugs".
My three favourite programming languages are, in no particular order, C, C++ and Python. I like each one of them for a different reason. However, from those three, it’s Python the one that fits better with both goals. What allows you to have less code? A large standard library. Programming languages with large standard libraries or a large set of unofficial libraries or modules let you program closer to the problem definition and cuts code/time costs in two ways. First, less code needs to be writen to accomplish a given task because there may be a function or object that abstracts the behaviour you’re looking for. Second, when large abstract libraries are available, you don’t have to design them. Smaller design, less code, less bugs, less time, smaller cost.
And, finally, if the language allows you to have functional-programming-like constructions, or is itself a functional programming language, you can avoid writing too many loops. In C++, the "functional" header includes templates for common loops, so you can avoid writing them. Many C++ programmers will tell you not to write a loop if that is already present in the standard library. Going a little beyond, but not too much, I’d tell you to avoid writing a loop if you can do the same as a series of sequence transformations. Transform the elements from one sequence into another sequence, copy or remove elements if they match certain conditions, etc. Python’s list comprehensions and lambda functions allow you to do this. A series of sequence transformations many times let you perform the equivalent job a loop would do, but in the shape of the simplest constructions: a sequence of sentences.
There will always be exceptions to both mottos, but I think they should be taken into account when writing any program and choosing the appropriate programming language to do the job.