I've been programming for 32 years, and for over a decade in Perl.

When I write code the first time, I'm usually drawing on known good patterns that I'm able to recall in the past. Perl's flexibility gives me the options to give the right balance between named and unnamed things, processes versus data, and organization and optimization for various goals, such as efficiency or maintenance.

But after the program is working, I usually think of three other things I also want it to do. At that point, a rewrite has a different goal, and might even result in "oh yeah, I also want to do this and that, so that would better be handled by a different abstraction".

This is a natural part of the learning process, stretching both me as a programmer, and in particular my skills in programming in Perl. It's also partially an acknowledgement that I slowly learn more about the particular problem domain as well, by solving one piece of it, and then realizing what the next problem in the problem domain might be.

Most of the patterns I carry in my head are now "native Perl", but there are still things I recall from Icon and Smalltalk that have no good Perl representation yet. Maybe someday soon. {grin}

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.