Loop Construct Need Discussion

(Discussion moved from TheRightWayToDoWordyBlocks)

Does a language really need to support native loop constructs such as DO...WHILE(condition) and DO...UNTIL(condition)? These are loops that will always execute at least once because the condition is tested at the bottom of the loop.

Both can be replaced with something similar to the following:

 var reloop = true;
 while (reloop) {
    ...
    if (<condition>) {reloop = false;}
 }

I don't see a frequent need for such DO loops in my code such that perhaps the language can be kept simpler by using the above style for the few times such is needed.

A quick check of one project shows it to be 90% for, 7% while, and 3% do... while. Strictly speaking we don't need any loops. So it's really a question of convenience. --AnonymousDonor

[Some language designers favour having one or two kinds of loop, and agree that constructs like that above are appropriate. Others favour more kinds of loop, to avoid needing constructs like that above. It's a matter of convenience and preference. There is obviously no logical basis for stating that one approach is better than the other. A good compiler turns them all into the same code anyway.]

Or get Lisp and roll-your-own loopers :-) I'd lean toward keeping the language sparse of such unless either it's commonly needed, and/or the cost of not having it are high (bulky or confusing work-arounds). DO-loops don't qualify under either. Also note that flags can help split up complex conditional logic into simpler parts for easier reading and/or finer-grained comments, somewhat similar to what ThickBreadSmell discusses. -t

[What is a "loopers"? In general, loops should be deprecated in favour of mechanisms like map, filter, fold, unfold, etc. However, learning loops is so trivial -- except for a rank beginner -- that I can't imagine any benefit to not having a variety of kinds of loops in a production language. Anyone who can't immediately learn, read -- or even recognise intuitively -- a new kind of loop shouldn't be a programmer.]

Careful of NarrowStaffSelectionFactors.

[Careful of hiring unqualified idiots.]

I've seen plenty of programmers I'd consider "not very bright" otherwise get good reviews. The work world is about getting the job done (or perceived as done), and is not an IQ test. Strengths in other areas can increase ones (perceived) value enough to plenty compensate for lack of intellectual strength. People skills, diplomacy skills, "common sense", and domain experience matter to those who write the checks. Further, in semi-well-run shops, developers will help each other out to compensate for each others' weak areas.

---

CategorySyntax