Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Object Orientation is:

by Petruchio (Vicar)
on Sep 03, 2002 at 09:15 UTC ( [id://194707]=poll: print w/replies, xml ) Need Help??

Vote on this poll

The bomb. The bee's knees. Uncut cool. The True Way.
[bar] 27/8%
A good approach to many problems, though not the only one.
[bar] 199/57%
Useful for really big projects, perhaps, but mostly overrated.
[bar] 59/17%
Slow, bloated, and boring. I'm a coder, not a theorist.
[bar] 15/4%
For the weak. As are scoped variables and control structures. Goto++
[bar] 7/2%
Something I've been meaning to figure out.
[bar] 24/7%
So poorly defined, it's hard to venture an opinion.
[bar] 13/4%
None of the above.
[bar] 8/2%
352 total votes
Replies are listed 'Best First'.
Re: Object Orientation is:
by frankus (Priest) on Sep 03, 2002 at 10:48 UTC
    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.


      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.

Re: Object Orientation is:
by Courage (Parson) on Sep 03, 2002 at 11:23 UTC
    Steve Fink once sayd on p5p really wise and funny things:
    ... Ok, so I didn't really mean that about information hiding. Dramatic license. But it is one of the things that bothers me the most about OO code. A "real OO programmer", when given the task of implementing a heart, would take a real heart and coat a meter thick layer of plaster around it, then drill holes down to the aorta and stick tubes in them. He would tell you how great it is that you can replace the buried hear +t with a vacuum cleaner or a rooster without changing anything else. Whe +n you complain about the tubes sticking out of your chest and the wheelbarrow you need to push your new heart around in, he'd quickly point out that the wheelbarrow is really an advantage because you can haul around all kinds of other great things at almost no added burden. ...

    Courage, the Cowardly Dog

      Cool. That's the first time I've ever run across someone quoting me on the web (properly attributed, even!). A slightly updated version is at, but the passage quoted above is unchanged (and probably the only part worth reading.) But as I say in the pointer to it from my home page:
      If you disagree with it, then it's probably more right than wrong for you. If you agree with it (like I do!), then it's most likely more wrong than right. We humans are funny that way.
      ...this is very funny, but the analogy breaks down immediately when we realize that the heart is a component of a system that is not subject to extension, redesign, or feature creep. (So far at least, who knows what will happen in the age of nanotechnology?)

      It's easy to laugh at the idea that encapsulation leads to the possibility that we could replace the heart with a vacuum cleaner or a rooster. But imagine a real-world situation that concerns something almost as dear to many of us, the filesystem.

      Most Unix filesystem afficionados are aware that files are based upon a construct known as the inode. (An inode contains all of the relevant information that defines a file with the exception of the file's name.) In order to support the notion of remotely available files through the NFS filesystem, designers had to choose between either modifying the core code in the kernel to make special exceptions for files that are seen in a mounted NFS filesystem, or finding an abstract layer that encompassed all of the things that are common to both types of files.

      It would not have been difficult to account for both types of files in the kernel, but then there was this other form of networking that was common in the early days of NFS. A lot of people called this the "sneaker net." People wanted to put floppy disks with PC filesystems into their systems and be able to read them.

      So without an abstract representation of the inode concept, there would have had to be changes in the kernel to account for every new filesystem that came along. (So the S5 filesystem, the UFS filesystem, the PCFS filesystem and NFS filesystems were just the beginning of the problem.)

      By throwing some plaster around the problem (not a meter thick perhaps, but maybe only a few centimeters), it became possible to support a virtually unlimited number of new filesystem types without much change to the kernel core.

      In the end, OO programming is over-hyped, but then so are Tiger Woods, Michael Jordan, and Barry Bonds. This does not detract from their greatness. On the other hand, you probably wouldn't hire Tiger Woods to clean your carpets. A simple Perl one-liner would be a better choice.

      ...All the world looks like -well- all the world, when your hammer is Perl.

        ...I fully expected someone to challenge me to demonstrate the Perl one-liner that will clean your carpets.

        ...All the world looks like -well- all the world, when your hammer is Perl.

(jeffa) Re: Object Orientation is:
by jeffa (Bishop) on Sep 03, 2002 at 13:44 UTC
    OOP is dandy ... but Perl OOP is fun!
    raise Zombie; package Zombie; sub raise { print "BRAINSSSS!\n" }


    (the triplet paradiddle with high-hat)
      LOL! ++

      Makeshifts last the longest.

Re: Object Orientation is:
by tbone1 (Monsignor) on Sep 03, 2002 at 12:35 UTC
    I use OO when the situation merits, just as I will occaisionally use sed when the occaision merits. I do think that OO has some dashed nice things in it, if it's done right. If it's not, it becomes such a headache. This is why I vastly prefer Objective C to any other OO language, at least as an OO language. The whole package (IDE, language, etc) is splendid.

    If I may go into "grumpy old pfhardt" mode, I have worked with some fresh-from-college whippersnappers who can evangelize about OO and all that rot, but when you ask them something about real-world programming (like, say, dealing with user input errors), their jaws drop, the saliva begins to drip, and in my mind I hear "Duh, gee, Tennesse, let's ask Mr. Whooppee." Well, that or "Gosh, Mr. Obvious; I never made the connection." I think that, because the OO paradigm hides many things, they sometimes have trouble dealing with things that shouldn't be hidden to the programmer.

    As God is my witness, I thought turkeys could fly.

Re: Object Orientation is:
by talexb (Chancellor) on Sep 03, 2002 at 17:42 UTC
    Object Orientation is a golden dream, a lovely ideal, but we program for the real world. OO isn't always the best solution -- some managers seem to insist on doing a project 'OO' so they can put another line on their resume. Not because it makes sense technically.

    For example .. I'm writing a quick script to mirror a web site. Am I using OO? No, not really. I'm just getting the job done.

    Another project I'm working on is quite large. Will I be using OO? Perhaps it's not pure OO, but I will certainly write modules to handle the two (so far) classes I have. And, yes, one class inherits the other. But I'm doing it that way because it's the right tool for the job. Not because everything looks like a nail.

    It seems that if you mention a project you worked on was 'OO' you suddenly appear much more intelligent, technically competent and attractive to the other sex. Bollocks.

    'OO' is one way to do the job. Period.

    --t. alex
    but my friends call me T.

Re: Object Orientation is:
by krisahoch (Deacon) on Sep 03, 2002 at 11:18 UTC

    When the only tool you have is a hammer, then every problem looks like a nail

    -Abraham Maslow

    Kristofer A. Hoch

Re: Object Orientation is:
by chip (Curate) on Sep 03, 2002 at 14:56 UTC
    This is Perlmonks. Perl's religion is TMTOWTDI. Of course the most popular poll answer will feature TMTOWDI.

        -- Chip Salzenberg, Free-Floating Agent of Chaos

Re: Object Orientation is:
by NAstyed (Chaplain) on Sep 03, 2002 at 14:22 UTC
    "A good approach to many problems, though not the only one."

    That's true, but this days there are people that hate the words OO, and others that just love them, i think the diference is inside us.
    I would suggest another poll "Are you a OO lover?"
Re: Object Orientation is:
by beamsack (Scribe) on Sep 03, 2002 at 19:23 UTC
    OO works great for large projects.
    I have converted small elegant programs from functional to OO with dismal results.
    As a OO programmer, I have found that the most important design and code techniques come from Structural programming. Most of the powerful design patterns can be related to things done Functionally, but by using OO techniques. Heck I think the Observer pattern is nothing more than a smart GOTO.
    I have seen some OO designs with classes containing nothing but attributes (Data Objects) and classes containing nothing but methods (Editor Objects).
    Why not. The problem with OO projects is that designs get rejected for not being OO enough.
    In summary - good OO does not reject or ignore structural programming - it attempts to stand on the shoulders of structural programming to achieve maintainable industrial strength programs.
Re: Object Orientation is:
by digiryde (Pilgrim) on Sep 04, 2002 at 10:53 UTC
    OO in the real world....
    • Wrench set
    • Socket Set
    • Screwdriver set
    • Pots and pans
    • Vehicles
    • Genetics...

    My point:
    OO exists in many place in many ways. It is great in situations where there are large unknowns in the future. You build code, test it and maintain it seperately. You assign rules (parameters) to its input and output. Others that use it follow these rules do not worry as much about the code in the object.

    I have written programs that OO saved 100s to 1000s of man hours programming. I have seen programs written that added 100s of man hours by going OO. Like all great projects, map it out from a thousand feet, but land and see the ground around you before you decide on a coding method.

    Nothing clever here, move along.
Re: Object Orientation is:
by zakzebrowski (Curate) on Sep 03, 2002 at 15:08 UTC
    10 print "Hello World" 20 print "Keep it BASIC, baby yeah!"

    "There is no room in this country for hyphenated Americanism" ~ Theodore Roosevelt (1915)
Re: Object Orientation is:
by elusion (Curate) on Sep 03, 2002 at 21:12 UTC
    OO's great -- in the right situation. That's why I love perl: when OO's best, you use OO; when it doesn't work, you don't. In fact, most of the time, I use OO inside my other code. I don't know that I've ever done anything that's completely OO.

    Then again, when I write OO, I write the the methods with a functional paradigm.

    Some OO languages (ruby, maybe even python) are great, but being limited to one paradigm really stinks.

    elusion :

Re: Object Orientation is:
by blaze (Friar) on Sep 03, 2002 at 20:50 UTC
    I had to go with "Something I've been meaning to figure out" since i have yet to tame that beast, though with TheDamians book, i hope to overcome that soon...
Re: Object Orientation is:
by feloniousMonk (Pilgrim) on Sep 04, 2002 at 14:45 UTC
    my 2 cents -
    I can't say I've ever written any OO Perl. Never, and I've done quite a bit of Perl programming.

    Using an OO interface to a module, yes I've dont that. But for my style of programming and problems I
    tackle with Perl, OO doesn't seem to fit well.

    But I've written my share of OO code in C++ and Java - which when the problem fit an OO solution well then team
    programming sent very smoothly. Lots of design work and typical design tweakage along the way :-) but overall, depending on the problem,
    my experience with OO based projects is very positive.

Re: Object Orientation is:
by cybear (Monk) on Sep 05, 2002 at 13:40 UTC
    Good thread. This type of poll, while being less entertaining,
    is really useful to us "new kids". Reading the comments herein (that's lawyer talk)
    is helping me to decide whether to learn OOOr not. :-)

    - cybear

      Hopefully the answer is/was "Yes"?

      No matter what you see in the comments, either it's pro-OOP or anit-OOP, you should learn about OOP.
      First its not that hard to learn (it's not nuclear science, it's not even math, relational database used to be math whatever that means!).

      If there is one thing I learned about programming from PerlMonks website; it's there is several pardigms for programming(I dont remember the node name or author, sorry, but there is a specific node that I mean): functional, procedural, OOP, and ... well and more to come I hope! OOP will not corrupt your mind if you learn it.
      Mostly people who attack it, are just turned off by other people who are so very ooh-no ooh-my pro-OOP. But OOP is really interesting, as many ppl say, and will continue to say.

      OOP can be thought of in many ways, you can think of it as an upgrade to procedural programming, or the next logical step in the comp.lang evolution. In a procedural lang you manipulates data.

      Just data you cannot manipulate anything that can not be seen as data!

      Data are of course: Numbers(int, floats) and characters (strings!),data here is basically what ever you can insert from your keys in your keyboard...did i miss anything thing.

      And functions are functions, anything you cannot describe as data, you had to code a functions to represent it, and still those function can only manipulates data!

      OOP offers you a real way (by real I mean OOP is not just a theory, you have real implementation of its concepts) to manipulate more then just data, you can manipulate objects (and that is part why I think OOP implementations that don't support operator overload are missing a great deal!). Of course data can be objects, and objects can be anything. The gotcha here is, objects can only be anything that can be described in functions/methods and data; but hey, look around (at the different programs that exist today), that really almost anything!

      So why not think of a button as a function that draw a button!
      Don't you think it's better (a better and easier way to think when designing a program) to put a button object, on your window object (function..eek!), and add textArea objects and label objects to make a form!
      Yes GUI programming is one area of design that benefits a lot from OOP.

      So the bottom line is OOP is way of thinking when designing a program that is actually supported by langs that implement the concept and allow you to code what think the way you think it.

      And yes if all you wanted to manipulate is just numbers and characters, OOP would not give you much of and edge.
      But still its great to be here when you need it!

      And believe it or not OOP offer you a lot more then what I said, take Inheritence, this feature proved to be a great way to organize and upgrade object. And offered a great maner of code reuse. Abstract object at the top more detailled ones as subs, and subs for subs...

      A change in the the father Object with affect all its sons! WOW..thats impressive, not impressive to do, but to think about this way, and you know what you really code it that way, you can probably still do the same with regular modules. But isn't a lot more logical and fun to think about it in term of objects!

      It really reduce the gap between modelling a program/system and the actual code.

      I guess this is all.
        Thanks for the input. I'll keep your comments in mind.

        Got a good book to recommend?

        - cybear

Re: Object Orientation is:
by nacka (Friar) on Sep 04, 2002 at 20:02 UTC
    Object orientation is a very nice tool when doing system analysis and design. It's nifty to have small thingies (objects) that you can shuffle around on table, give attributes and behaviour.

    But when I sit down to actually write the code? No thanks! Object orientation gives you bloated syntax, tries to force you to behave with regards to coding standards etc without giving something in return.

    What's needed is discipline and standards. Don't expose every sub, var etc to the world, don't change interface every release cycle, etc etc etc. Have a consistent naming scheme for subs and vars. Think before you type, don't reinvent the wheel and Keep It Simple, Stupid.

    None of these things is automagically taken care of by a OO-language. So I really don't see the point in using one.

    If OO was the answer, shouldn't apps written in a OO-languages have fewer bugs, less maintainence headache, quicker adoption of coolest-feature-of-the-day?
Re: Object Orientation is:
by rir (Vicar) on Sep 03, 2002 at 23:32 UTC
    Inheritance is the heart of OO. Inheritance is another dimension in which you may stretch your code. You can obfuscate or clarify your code with it.
Re: Object Orientation is:
by NaSe77 (Monk) on Sep 03, 2002 at 11:06 UTC
    I think it is good for people that sit down when they pee - true men stand up for it and use structured programming ;)


      ...some days you wish that you could -- more than once.

      I know several "true men" at Sun who work on the kernel internal design, many of them pee sitting down (and bunked in the womens' dorm at school), and they have developed several object-oriented artifacts that make the system what it is.

      Thanks to the magic of encapsulation (forget about code reuse and modularity, that junk is for the trade shows) we have the virtual filesystem (thanks guys (and gals) for the swapfs, the specfs, the tmpfs, and the procfs), the virtual memory system (the vnode layer made the virtual filesystem possible), and the creation of scheduling classes (now we have timeshare, realtime, system, fairshare, and fixed priority scheduling classes).

      All this is done without a line of Java, C++, Ruby, Python or Smalltalk. Using only C and assembler, the designers of the OS kernel have given us the best of OO design without too much in the way of overhead. And it makes possible the solutions to problems that would never have been solved without a tremendous amount of overhead in the kernel code itself.

      No, OO programming is not for every problem, but it should be mastered by every serious programmer at this point. There's not much to it actually, and it doesn't actually demand a heroic ability for abstract thought. I actually cover most of the core principles in my Advanced Perl class in about an hour.

      On the other hand, I don't think that Perl is the ideal language to use for initially exploring OO concepts. But if you start out that way, you'll be able to do anything in other OO languages as soon as you become accustomed to how they work.

      I would guess that programmers who learn OO with Smalltalk or Java will only struggle a bit with Perl for OO, but those who learn first in Perl may chafe at the strictures imposed by more typesafe languages like Java. (I also found high levels of resistance in C++ programmers trying to move to Java.)

      Bottom line for me is this: If you think loops, switch constructs and the conditional operator are really slick, then don't worry about OO. You'll find plenty to amuse you in procedural programming. If you had enough of writing simple logic structures in school, then maybe you want to move up to the world in which you program the behavior of such program constructs that are already encapsulated in an object that regulates behavior so that it remains rational most of the time.

      That's an important part of what we talk about when we teach new Java programmers. Trying to ensure rational access to things so that bank accounts don't magically have their balances set to $-1,000,000 or that life support systems don't magically shut down due to a minor error condition. Encapsulation is a big win, and it helps us to build more robust structures in our programs.

      But there are many ways to tackle any problem and all of them are good as long as they succeed. Once more with feeling folks:
      Vincent's Law of Elegant Programming: The most elegant programming solution is the one that is finished.

      ...All the world looks like -well- all the world, when your hammer is Perl.

      Um, some of us here actually like women and want to encourage them to program in Perl, including OO. Your comment is bizarre, and not very friendly to them.
        i myself like women alot (and pee sitting) and it was just a joke in fact

        in german there is a joke like this ("das ist was für sitzpinkler") and i tried to translate it into english but obviously it didnt work out. sorry.


Re: Object Orientation is:
by malaga (Pilgrim) on Sep 05, 2002 at 08:15 UTC
    How do people get to have the first comment in a poll? Do they watch for the poll to change so they can vote first, or is it just by chance?
      I understand OOP just about as well as I understand sandscrit. Oh well, soon enough I will get around to it... one of these days; maybe... probably not... oh well.

      work it harder make it better do it faster makes us stronger more than ever hour after our work is never over.
        so, brother frankus, how do you do it? do you wait for the poll to change?

View List Of Past Polls

Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (2)
As of 2024-06-21 18:03 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.