http://www.perlmonks.org?node_id=194722


in reply to Object Orientation is:

I hate OO as a topic of discussion. As soon as you sound sceptical, people who really like OO think you don't know what it is.
I dislike the importance attached to it, I mean I never heard people enthusing about Relational Databases in the same way.

It seems, these days, that knowledge of OO counts as much as knowledge of protocols, systems and computer science.
Which is mildly galling. The plain fact is, we'd all like to write cool code that everyone used, abstracted to the nth degree,
which is as generic as a politician's answer but infinitely more applicable.
The art of the matter is recognising when that is productive to do. Mostly I like instantaneous results, which OO never is, either in creating or in running.
Occasionally it's useful for code reuse, but rarely in a quantifiable amount compared to function reuse

OO is a way of saving time and making robust systems, it's a methodology, take it off the pedestal, learn it, move on.
On to abstract oriented development, perhaps...

Err, good poll, sorry about the rant.

† Really like in the "evangelising" sense

--

Brother Frankus.

¤

Replies are listed 'Best First'.
Re: Re: Object Orientation is:
by ichimunki (Priest) on Sep 03, 2002 at 18:13 UTC
    I don't want to "evangelize" anything, but I'm not sure why you think OO programming isn't instantaneous. I think how instantaneous it is depends heavily on the language.

    C++ looks laborious to me. I haven't learned to code to OO in C++ because I've never had time/need (to even learn C++). Ditto Java. Ditto Python.

    Perl OO -- while not instantaneous-- is a great way to learn how OO actually works because all of the internals are exposed. It's almost annoying the way you have to shift $self off the argument list for $self to recognize it-$self, but you really do learn to see an object for just a (blessed) reference to a data structure. I mean, you're there building that structure and manually blessing it. You really get to learn the difference between the namespaces, and how to share data (exporter, etc), and how instance/local variables interact.

    Then what about a language like Ruby. How much more instantaneous could a langugage get? It has a interactive mode (irb) where your program runs as you type it. You can define a class in very few keystrokes, redefine classes and methods after you've already started using them (existing objects can learn new behavior), pick up the objects, classes, and shake them and see what falls out. It couldn't get more interactive or instantaneous.

    But is OO enough all by itself? Of course not. A good language will have a simple way to write a straight-forward imperative program. It will also have things from functional programming, like the ability to pass a block as an argument or creating closures.

    And no, I haven't heard anyone going on about relational databases lately... but I have heard a lot of really enthusiastic discussion of star schema methodology for them. <grin />

      Perl OO -- while not instantaneous-- is a great way to learn how OO actually works because all of the internals are exposed.

      I couldn't agree more. I learned OO with Perl, and I find that it gave me a unique perspective on the meaning and purpose of inheritance, polymorphism, and encapsulation. Because it's so out in the open, it's less magical and more understandable.

      I like Ruby and Perl too, both are cool languages, I run both on my iPAQ; I've also used C++, Java and Python in commercial environments, and I would not grumble if I had to use them again.I didn't feel the need to mention that in the previous post.

      In effect, you've proved my point. In defending OO, you've missed the salient points and started with the premise that I'm a novice.

      OO Development isn't instantaneous, invariably you'll need to "reign in" the analyst who's so busy producing a design that match the "problem set" rather than observing what goes into the system and what comes out. When running OO code, in Perl at least using OO has an overhead. I think you know these things already.

      Perl OO isn't a good way to learn how OO works as it doesn't protect you from bad things, it'll take you longer as you stumble across means of implementing singletons and avoiding diamond inheritance structures. Of course when you do, you'll be a hardened veteran, whereas other langauages will not tell you of these horrors, simply avoid them silently, by means of the language design (mostly). This is where Damian Conway's book is indispensable. OO is fun in Perl, but Perl isn't meant to teach you OO.

      If you're using Perl and nothing else, of course you'll learn OO using Perl makes sense, but it's only maginally less stressful than learning a new language and OO at the same time. Of course I'm speaking as one who learnt C++, Perl then Java then OO Perl.

      --

      Brother Frankus.

        I don't know what I wrote that makes you think I started with the premise that you're a novice, I had no intention of sounding that way. Comparatively, I'm the novice.

        With any advanced functionality the trade-off is either programmer time or CPU time. If you don't need OO (or it isn't a standard bit of the language), I certainly wouldn't warp my problem domain to fit into OO. But the amount of overhead depends on the language. In some it's going to add a lot of overhead, in some not much. But if its not going to save the programmer time, why use it?

        You're right that Perl isn't designed to teach OO, it's barely designed to do OO. But I like it because everything is so exposed and a little bit hard-- that way, instead of relying on the magic of the programming language, I have to understand what I'm doing. Maybe that's not the best way to learn it. But I don't know that there's any right way to learn anything. Most things just take time and practice. I don't think if I were serious about using OO for a project that Perl would be the language I'd choose.