Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re^5: I dislike object-oriented programming in general

by stvn (Monsignor)
on Oct 23, 2007 at 22:11 UTC ( [id://646776]=note: print w/replies, xml ) Need Help??


in reply to Re^4: I dislike object-oriented programming in general
in thread I dislike object-oriented programming in general

Yes, all this theory is very nice, clean and organized, but it doesn't help me at all when I need to get a job done.

This is one part where I think it is essential to take a step back and forget everything you know about any programming languages you have learned.

Again, I disagree. First of all, you are talking about concepts very heavily tied to programming languages (in fact, all your expansions on the "gob" definition come back to programming languages). But really what you call a "gob" is nothing new or fantastical, but simply the product of "moduler decomposition". Modular decomposition is not specific to computer science of course, or even engineering. Many artistic disciplines use the technique, like music and painting.

And lastly, you have not really given a useful alternative to OO. You say you don't like it, but you have not shown a superior tool. Sure, we all hate zealots, but that is no reason to abandon OO and the 30+ years of research and usage in which it has grown and developed as a paradigm. But hey, if you want to go back to the 70s/early 80s and program in CLU or Pascal, be my guest.

-stvn

Replies are listed 'Best First'.
Re^6: I dislike object-oriented programming in general
by vrk (Chaplain) on Oct 24, 2007 at 15:13 UTC

    it doesn't help me at all when I need to get a job done.

    It helps me think. The root node title says I dislike, and the author was vrk, 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 gobs modules parts, which particular mechanism to use based on the structure of the problem.

    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).

    And lastly, you have not really given a useful alternative to OO.

    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.

    --
    print "Just Another Perl Adept\n";

      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

      -stvn
        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.

        No, I hate them all, even those that have not been invented yet. And they all hate me! :)

      I like oops !

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://646776]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (6)
As of 2024-03-28 11:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found