How does Perl mix OOP with procedural and functional programming?

Perl is a laid-back language. It goes to great lengths to let programmers do whatever they want, in whatever way is convenient to them. This contrasts sharply with languages like Java and C++. For instance, Perl is happy to allow the programmer to automatically create variables if they were not previously declared (though this is not encouraged, and can in fact be prevented with the use of the highly recommended "use strict" pragma). If you want to shoot yourself in the foot, Perl will give you ten bullets and a laser scope, then stand by and cheer you on.

Perl is, therefore, a great language for abusing methodologies. Don't cringe. It's OK. Accessing internal object data, changing classes on the fly, and redefining methods on the fly are all allowed, for example. The Perl way is that programmers should be allowed to break the rules in the interest of coding, debugging, and execution efficiency. If it helps get the job done, it's OK. Thus, Perl itself can be the programmer's best friend or worst enemy.

Why would anyone want to mix OOP, FP, and PP, if it means breaking the rules? Let's step back and consider the question. What are OOP, FP, and PP? They are just programming methodologies, bundles of concepts, stacks of rules that exist to serve the programming team. OOP, FP, and PP are tools, and every programmer's first job is to know his tools. If a programmer fails to utilize the FP Schwartzian transform in sorting a hash, but writes his own Sort::Hashtable, or fails to reuse the Sys::Hostname module and instead writes procedural code to obtain the system's hostname, that programmer has wasted time, effort, and money, and has reduced code quality and reliability.

A programming team can become complacent with the tools it knows best, and this is just about the worst thing that can happen to them. Using only a subset of the tools available in an industry as exciting and innovative as the computer programming industry guarantees that the team will become useless in a few years. A programmer should be able to mix any methodology whatsoever if it makes him more efficient, his code better, and the team more innovative. Perl recognizes and encourages this attitude.