What your friend is saying does make a certain amount of sense, especially if the "for loop" in question is a perl style for @array type of loop. In this case, the iteration is not being control by an abstract control mechanism of a numeric count, but is being controlled by the volume of data, the array in this case.

You could translate that into the algorithmic definition of "iterate through the array". The nice part of this is that the neither the size, type nor any other physical characteristic of the data is involved in the algorithm. If the array is empty, nothing happens. If the array contains disparate sized elements--chars, ints, floats, long longs, strings etc.--it doesn't change the code or the algorithm You simply don't need to no how many or what type of data is held in the array. Compare this with a C-language for loop which relies on all the elements being the same size.

Compare it also with using a c-style for loop in perl which requires at least one additional variable (index) and one additional constant (the stop condition)., and has the downside that the number of repetitions of the loop can be affected during the iteration of the loop, by adjusting/corrupting the current values of either the iterator or the stop condition.

In the perl type for/foreach loop, the algorithm is entirely defined by the data, so the statement that the algorithm is the data starts to make some sense.

Similarly, this technique of capturing the algorithm in the data is nicely demonstrated by the common perl technique of using a hash to count the unique elements in an array. It's instructive to try and do this task in some language that doesn't have either hashes or dynamically sized & dynamically grown arrays.

The first thing you need to do is allocate some space to hold the counts of the unique elements. The obvious thing to do is to create an array to hold the counts--but how big an array do you need? There is no simple way to determine this. It could be that every element in the array who's elements are being counted is unique, in which case you need an equivalent size array to hold the counts. Conversly, they could be all the same, in which case you only need one count. In between, the variations are unknowable. You cannot even make one pass to determine how many counts you need, allocate and then a second pass to do the counting.

If you are using C, you might use a recursive routine that starts with the first element, then scans the rest of the array, counting and marking all the similar elements it finds. It then saves the value and associated count on the stack whilst it recurses to find, count and mark the second element and so on until a pass completes without finding any unmarked elements. If the routine also keeps a global count of the number of passes as it recursed, it can now allocate the space to hold the counts and populate it as the recursion unwinds. As you can see, this is a multi-pass process that will consumes prodigious amounts of stack if the array is large and has many unique elements. Even given the speed of C, this is not going to be fast, and as each programmer will have to roll-his-own solution everytime this requirement comes up, it is costly and time consuming to code and carries a high risk of bugs.

The simplicity of doing this in perl is not due to any particular high-level language feature of perl, but is directly attributable to the high-level data-structures that perl provides. This allows the capturing of this complex algorithm directly in the data-structure (hash) used to accumulate the counts.

The real beauty of perl lies in its data types--a strange thing to say about a language that is known as an untyped or weakly typed language. It is the total generality of perls data types, their polymorphic nature and the clever choice of a small number of carefully chosen language contructs for manipulating them that allows (for example) perls arrays to be used as traditional arrays of chars/ints/floats/strings or any combination of them; as stacks, fifo's, lifo's; to be sliced and spliced; and the transparency of the underlying mechanisms to the perl programmer that are the real power of perl.

If you've ever spent time wading through the C++ STL or the Java API documentation trying to figure out whether you need a Bag class or an OrderSet, and UnorderedSet or Vector or which of the many other myriad variations on this theme to capture the particular semantics of your dataset. Or if you have tried to then adapt the resultant code to account for small changes to the operational requirements of the data, and tried to force fit these into one of the provided datatypes; or worse, tried to find or hack the mechanisms to allow you to convert from one of these mechanisms to another, then you will really begin to appreciate the power and flexibility of the perlish way.