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.