|laziness, impatience, and hubris|
If I were you, faced with Guru2's opinions, I would ask him for
Take notes and come back and post his answers.
You will then likely as not, get a refute (or two:) of his criticisms for Perl. And a refute of his choice of true OO (unless its Smalltalk, Ruby or Eiffel).
Whence you have heard both sides, you may then be better placed to make your own decision as to what is important.
It is possible, though quite difficult, to write OO in C.
It also possible and actually quite easy, to write extremely bad code in the true OO languages.
I once had the misfortune to have to try and unpick the dying skeleton of a Smalltalk project in order to reverse-engineer as far as possible the specification of the bits that worked prior to a re-write in another language. The guys that wrote it were, well lets just say they took the notion of re-use to the extreme, inheriting from anywhere that vaguely did something that they needed to do. The result was a tortuously, convoluted mess.
Like most of the other "paradigm shifts" that have gone before it, OO isn't the holy grail, it's just another method of designing software.
Some language support this concept by providing syntax and semantics, along with class libraries, that lend themselves in the implementation of projects designed from the OO perspective.
Some languages--C++ for instance--have tried to force fit these concepts and ideals upon their predecessors, and despite having ridden the tide of OO-isms rising popularity, have never quite succeeded in their goals. The C++ templating mechanism for polymorphism is one very good example. Leaving the ability to cast from object types to primitive types is another. I seen and even written C++ that used casts to bypass certain restrictions imposed by the compiler. I hear the OO purists around world take deep breaths in shock and feel the wind of their wagging fingers, but the piece of code I am thinking of is still in use today some 8 years after it was written, and doing sterling service despite it's 'cheats'.
I have also seen and contributed to code written in a language called BLISS (a C-like system programming language) that could, if you squint your eyes enough, be called OO in its design, despite having predated the OO-phenomena by some years.
In the end, it doesn't really matter how much the language or the tools try to enforce the OO paradigm. If the designers & programmers using it don't really understand, or take the time to do their jobs right, then you can still end up in a mess. Alternatively, if the design is well thought through , and the implementation follows the design, the language used is pretty irrelevant.
Whilst the OO purists will argue against it, there are, and probably always will be times when it makes commercial sense (read: cheaper) to 'drift' from the path of true OO-ness in order to get the job done. Provided this is agreed, fed back into the design specs, and well documented, its ok.
Perl allows this. Smalltalk doesn't. I love Smalltalk at the intellectual level, but sometimes trying to get it to do what you want it to do can be a real pain in the ..er..well, you know. That said, I haven't even begun to explore Perl's OO side. I'm having to much fun exploring it's other possibilities.
Tempting, the dark-side is.
What's this about a "crooked mitre"? I'm good at woodwork!