Relax man, don't take this all so personally, we are just talking 'bout Perl here.

The point of all this waste of time is to say that I don't like the particular mechanism of modular decomposition offered by (pure) object-oriented programming, regardless of how the particular implementation of object-oriented programming works

My point is that many different languages provide different approaches to OO, and therefore provide a different form of "OO-style modular decomposition". I find it hard to believe that you have programmed enough (non-trivial) applications in all these different languages to really make such a sweaping statement about OO programming in general. I know that I have not done so, but I am willing to leave open the possibility that what I don't like about $language{X} might be "fixed" by some feature of $language{Y}. Or that through some creative technique I might be able to implement said feature in $language{X} often times by (ab)using the language in ways it was never intended to be (ab)used.

For instance, when I have programmed in Java, I have really really missed closures, which I use heavily in my Perl OO programming. In the end I just created an interface and wrote small inline classes to mimic them. It was clunky, but worked.

When I programmed in Javascript, I really missed some kind of namespacing mechanism, thankfully someone came up with a cool namespace hack using functions and exploiting the prototype based OO system.

I learned to hate Perl's clunky OO system over the years, but I loved where Perl 6 was going. So I wrote Moose, which bootstraps an entire new OO system into Perl's existing one.

In all these three examples, $language{X} was missing a particular "gob", but with a little creative hacking that "gob" (or something fairly close to it) was added to $language{X}.

Right, I suppose I should have written four or five of these meditations to enforce equality between paradigms.

Hopefully you don't hate all programming paradigms, cause if so, I think you picked the wrong career/major.

But since you asked nicely, I recommend pure functional programming with monads to encapsulate the particular cases where you need explicit state and sequential execution. Haskell is one where this happens. You can read more propaganda from their wiki.

Yeah, Haskell is nice, but IMO monads tend to be an overly complex abstraction of what are usually very simple tasks/requirements. The exception being the Maybe monad, which I always thought made Haskell code more readable.

It is interesting that you say monads, because while there are many "Monads in $my_favorite_language" blog posts out there, there are few practical uses of the technique outside of Haskell. Part of this is due (IMO of course) to the fact that really effective use of monads relys not only on a strong type system, but also on polymorphism (i.e. overloading of >>= operator) such as is provided by Haskell's type classes. Simply taking a look at any monad implementation in OCaml will illustrate this, since OCaml does not have this level of polymophism (you can hack around it somewhat using Functors, but it gets really ugly). So really your solution to OO is heavily tied to a particular programming language and other features in that language that truely make it a useful technique. Just as writing small inline classes to mimic closures in Java sucked, I would not want to have to use some other ackward technique in $language{X} to have monads.

My whole point is that you can't be implementation agnostic when discussing the merits of a particular paradigm, especially in a multi-paradigm language like Perl. As many people around here are fond of saying ...

TIMTOWTDI