And wouldn't the design of the components also fall under the design pattern issue? What type of bricks, for instance?

Possibly the accepted idioms, either included in the language, or as an external library or a CPAN module, directly or indirectly, force the patterns of their usage on the work?

The perl.com article discusses the iterator in Java and Perl, resulting in this statement,

"In Perl any built-in or user defined object which can be walked has a method which returns an ordered list of the items to be walked. To walk the list, simply place it inside the parentheses of a foreach loop. So the Perl version of the above hash key walker is:..."

"The inclusion of iteration as a core concept represents Perl design at its finest. Instead of providing a clumsy mechanism in non-core code, as Java and C++ (through its standard template library) do, Perl incorporates this pattern into the core of the language." (emphasis mine)

The iterator is simply an example. I'm not interested in dissecting iterators specifically.

However, the article led me to think that Perl developers considered the iterator component mentioned important or reasonable enough to more thoroughly integrate it, given their view of the language's mission.

Maybe it's a pattern-within-pattern-within... question for me, a fractal issue. More global design issues (probably moderated by 'accepted usage' or what becomes idiomatic) containing idiomatic usage of core components, external modules, object usage, etc. Something is Perlish, for instance, and becomes an accepted pattern of usage.