Second, I find packages like the ones that you mention to be helpful, either as reference or as a source of an actual solution. While I do not always use these materials exactly as they are written, they do, nevertheless, represent “a complete thought.” And, yes, I do find myself using these modules quite a bit because I simply do not have the time to do original coding on my own.

I'm far from adverse to using CPAN modules. Much less looking inside them to see what makes them tick.

One or more of them, Data::Dump, List::Util, Time::HiRes *, are used in almost every script write. And a bunch more LWP, IO::Socket, IO::Select, GD, etc. I use as if they were an integral part of Perl. I use them so frequently that I never have to look up their basic functionality; nor often even their more involved details.

And I've never even considered trying to re-create their functionality using the basic Perl's built-ins (like socket,accept,bind & listen) they use under the covers. They're, (their apis), just so well thought through and simple to use, that messing around with the low-level stuff they encapsulate rarely enters my head. And when it does, it is only to understand how to use them better, or on very rare occasion, to patch my way past a limitation.

But the thing to note is that none of those modules is a framework. Their designs are such, and their apis so well thought through and developed, that they can be used in conjunction with threads or fork or select. They assist the application writer by encapsulating the messy low-level details in such a way as to allow him to be ignorant of them. But they do it without imposing a particular architecture; or requiring that they be masters of all they survey.

The distinction is as between: doing a self-build where you hire an architect to encapsulate your ideas, and individual contractors to enact them; and buying a house from a developer, who offers you choices of, the number of bedrooms, and the color of the bathroom suites & the tiles on the kitchen floor.