|Just another Perl shrine|
It helps me think. The root node title says I dislike, and the author was w-ber, not stvn (you can compare that with your favourite programming language, if you like). I only argued why object-oriented programming fails to warm my heart, and to my knowledge there was no direct promise of enlightenment after reading my ramblings.
I don't claim to have discovered anything new here. I used the word gob since you were confused with my use of module; but apparently modular decomposition is okay, so I'll use that.
I find it very helpful to keep in mind that despite the programming language, you are always dealing with the same basic things, which boil down to separation of concerns and modular decomposition. If I were stuck with only one or two particular techniques in modular decomposition, and the programming language I used lacked those, I would be stuck. Clearly you are more clever than I am and this doesn't concern you, but for us less advanced in the audience, I'll explain.
For example, recently I've had to program in PHP. PHP 4 and 5 have classes and objects (less refined in the former than in the latter), and they support a rudimentary callback mechanism by giving function names as parameters (through "variable variables"; in Perl: reference to a scalar). They also have eval, but I try to keep away from that beast. So, my options in modular decomposition are limited: I can make some procedures or I can make some objects, and that's about it.
If I only knew, say, (pure) functional programming through Scheme, I would be in trouble: no support for the particular mechanisms of modular decomposition that I know. Oh! But what I do when I pass closures around is roughly the same as passing objects! Problem solved: I'll explicitly define classes and then instantiate objects.
Programming in Scheme would be equally confusing if you only knew object-oriented programming. Oh, what am I saying, of course not: it's the same modular decomposition process again, only with different concepts. In multiparadigmatic languages I even have a choice, when decomposing the problem into
I'm not saying that by knowing what modular decomposition is you would miraculously know any programming paradigm there is. (You'll no doubt read it that way.) 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 (and by implementation, I don't mean how the programming language is implemented, but it seems to be useless to make distinctions).
Right, I suppose I should have written four or five of these meditations to enforce equality between paradigms.
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.
In reply to Re^6: I dislike object-oriented programming in general