Fencepost errors, ...

By definition, that pretty much violates the "works for you" part of my comment, doesn't it?

That depends on who finds the bug and when. I know I can write a C-style for loop correctly, most of the time, but I don't trust myself to write it reliably all of the time, and so I try to avoid them whenever possible.

There is really only one interpretation you can place on for my $element (@array) and very few ways it can go wrong whether you know Perl or not. On the other hand for ($i = 0; $I < $numOfElements; ++$i) {...} requires a lot of interpretation even if you know C and there are many places it can go wrong. One of the reasons Perl seems to work as expected first off more often than C (and I know this to be true from personal experience) is that you can avoid exactly this sort of issue the vast majority of the time in Perl.

Some Perl idiom is just weird and non-obvious to the non-Perl programmer, but much of it is understandable without arcane Perl knowledge (and simply pulsates with succinct power).

---

Perl is environmentally friendly - it saves trees

I don't want to get hung up on loops as that is just one C-style construct under discussion. Also, I don't want to be in the position of having to defend C. Especially on a site called "PerlMonks".

That said, I agree most of what you said above. Although, I think that people who natively think in C don't have any problems reading

for ($i = 0; $i < $BLAH; ++$i) { ...}
[download]

. For a native C thinker to make a mistake with that construct is pretty rare.

But when you have the luxury of perl and you aren't forced to use C constructs, why not use

for my $foo (@bar) { . . . }
[download]

I agree completely. It's the better solution. But my point is I wouldn't wring my hands over using the C construct if you don't normally make mistakes with it.
--
I used to drive a Heisenbergmobile, but every time I looked at the speedometer, I got lost.