The iterative nature of a solution should always come out
in the design stage of development, not during implementation.
The algorithms described in the design should aim at minimizing
the number of iterations. For example, the number of iterations
performed by a selection sort on a list of N elements is roughly
N^{2}, while the number of iterations
performed by a heap sort is roughly N * log(N). Note that this
has nothing to do with the programming language. In the design
phase, we have not yet decided on a programming language. Regardless
of what language we choose later, in the implementation phase,
we will prefer the heap sort algorithm over the selection sort.

Note that if N is very small, it doesn't matter much whether
we use a selection sort or a heap sort. However, we should
*never* make such assumptions about the data.
A function as generic as a sorting algorithm is not just useful
to this program. It should be written in a way that it can be
used in *any* program, so that we don't waste
time rewriting it later. So, we decide during the design phase
to use the fastest sort algorithm, and we decide during the
implementation phase to use a compiled language, since sorting is
computationally expensive. Using an interpreted language could
make the sort run for hours instead of minutes.

Regardless of the complexity of a problem, implementation should
always be a fairly simple process of translating the design.
The design of the sorting algorithm tells us
*exactly* what the code must do, so writing
the code in any language should be an uneventful process.