Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

Object Oriented Orientation

by koolgirl (Hermit)
on Jul 31, 2011 at 21:28 UTC ( #917729=perlmeditation: print w/ replies, xml ) Need Help??

OK, Monks, in fear of being hit with flying keyboards, I must tell you that I am currently in the process of learning Java, as my second language.**ducks** As most of you know, from several posts before on my behalf, Perl was in fact my very first language (well, as far as computers go, of course). However, even though I've come quite far in Perl, I have yet to pursue Object Oriented Perl. Now that I'm embarking on my new Java quest, it's coming to my attention, that Java is, itself, object oriented.

So, my question is this...*finally, you say*...should I stop where I am, and come back to learn object orientation in Perl? Is it more a concept to learn, than something to do with a particular language (other than syntax, of course)? Am I leaving my Perl quest immaturely if I've skipped object oriented Perl?

I suppose I hadn't really seen much point in venturing down that path, as I've never really come to a problem where the answer to said problem had anything to do at all with OO Perl, but if it's a concept I'm going to have to confront in order to move forward in my career, hadn't I better tackle it with good ol' Perl, rather than try and learn an entirely new language at the same time?

Comments, suggestions? Do ya'll use OO Perl a lot? Is the concept of object oriented languages closely related enough for the knowledge of one to help set precedence for the knowledge of another? Am I just grasping at ideas to keep me close with my beautiful Perl?

"The unexamined life is not worth living." -- Socrates

Comment on Object Oriented Orientation
Re: Object Oriented Orientation
by dreadpiratepeter (Priest) on Aug 01, 2011 at 00:37 UTC
    I use OOP in Perl all the time. But these days I use Moose. It is all the joy of OOP without any of the pain. I would highly recommend reading through the Moose manual and cookbooks.


    -pete
    "Worry is like a rocking chair. It gives you something to do, but it doesn't get you anywhere."
Re: Object Oriented Orientation
by Anonymous Monk on Aug 01, 2011 at 01:13 UTC

      I have to second these recommendations.

      Stick with Java. First, look at the job boards these days. Java is huge and marketable. It's a good OO language to learn, and a lot of the best OO training is in Java these days.

      Invest in OOAD. Learn good OO Design. A lot of the best OOAD training is in Java these days... I highly recommend the Responsibility Driven Design approach also. Object Design: Roles, Responsibilities, and Collaborations http://wirfs-brock.com/DesignBooks.html is a good book for that. You can find it on Safari also.

      Take what you learn and apply it to Perl. You'll learn a lot about Perl doing that. There are lots of OO Perl programmers out there, but not a lot of great ones. Good design skill is fundamental for OO quality.

      Finally, Perl is my favorite OO language to work with. It's what-you-write-is-what-you-get approach is simple and powerful. Dynamic compilation, being able to change the nature of your program taking on new responsibilities as your data and input dictate... literally seeking them out and compiling them.. very cool.

      --Dave

Re: Object Oriented Orientation
by chromatic (Archbishop) on Aug 01, 2011 at 01:54 UTC

    I have a theory that if you learn OO with Perl 5 and Moose (and my book teaches that), you'll find Java tedious, limited, and annoying.

    I've split my paid work between OO programming in both languages this year, and Perl 5 and Moose are really that much better. Java's only advantage (to me as a programmer) is IDE support due to partial compilation, but once you bring in things like Spring to deal with Java's inflexibility and lack of abstractions, part of that goes away.

    You can write a lot of great Perl 5 code while only ever using objects (so you ought to know enough to be able to use OO modules), but OO Perl 5 gives you a lot of other options to solve problems—especially in testing and design.

      ++. Thanks, I was excited to hear praise, complete praise, with no apologies or explanations, of OO Perl. I of course appreciate ALL comments here, and the time all monks devoted to answering, because I really needed to see and hear all sides of the coin on this topic, so different perspectives and opinions is a huge advantage given me on this thread, but it is still nice to hear a true professional, give an unabridged, pure appraisal of my long time love, Perl.

      Of course, it seems I've made a big mistake not having learned OO code before now, but, fortunately, my brethren are helping me get back on track, so hopefully, JavaFan, I'll be able to make a left turn soon ;)


      "The unexamined life is not worth living." -- Socrates

      "The idea, is to make a compromise, some where between your ambitions, and your limitations."--The Teahouse of the August Moon

Re: Object Oriented Orientation
by JavaFan (Canon) on Aug 01, 2011 at 08:59 UTC
    However, even though I've come quite far in Perl, I have yet to pursue Object Oriented Perl.
    I find that a strange sentence. I wouldn't claim to be quite far in Perl without having done any OOP. That's like saying "I'm quite far with learning how to drive, I've yet to make a left turn".

    So, my question is this...*finally, you say*...should I stop where I am, and come back to learn object orientation in Perl?
    Well, you could do two things. Either learn OO programming in Perl first, so you'll just accept how things are. Or you first learn OO programming in a language that does OO halfway decent (like Java, even if they don't do MI), then turn back to Perl and think "WTF was Larry thinking" for the rest of your life. I did the latter, and after 15+ years, I still loathe OO programming in Perl.
    Is it more a concept to learn, than something to do with a particular language (other than syntax, of course)?
    For most languages, it's more a concept of learn, with some syntax attached. In Perl, it's like getting a lump of metal, some rubber, and a dozen manuals on how to create your own bike, with hundreds of fanboy cheering that this allows you to create whatever bike you want. (The same fanboys will dislike C for its low-levelness, even if it gives you all the tools to write a much better regular expression engine that Perl has...)
    Am I leaving my Perl quest immaturely if I've skipped object oriented Perl?
    Yes. Regardless of ones opinions of OOP, it's important.
Re: Object Oriented Orientation
by bluescreen (Friar) on Aug 01, 2011 at 18:48 UTC

    IMHO, you can learn objects in any language but don't stop there go and see other languages too. All the implementations differ from each other and each one of them impose different constrains. i.e. Barebones Perl5 ( no Moose ) doesn't have attribute introspection or distinction between class/instance methods. Java on the other side doesn't support Multiple-Inheritance and you can't add attributes on the fly ( you can do that in Perl ).

    Learning objects is something that is not easy at all, it a shift in the way you see things. And usually I see the following pitfalls with people learning objects

    • Gigantic methods
    • Copy & Paste code among different classes
    • Poor cohesion
    • A depth inheritance tree

    The point is that it is common - specially when you start with a new paradigm - to try to do things in the old way ( and maybe not the most efficient way in the new paradigm ) so you might feel frustrated but don't worry it's just a matter of time and learning

Re: Object Oriented Orientation
by dwm042 (Priest) on Aug 01, 2011 at 19:28 UTC
    Comments, suggestions? Do ya'll use OO Perl a lot?

    I probably use OO Perl far less than many of the far better programmers who have replied, and my opinion is that of a sys admin who generally is asked to write fast and dirty scripts to Just Get Things Done.

    For small programs, under 100-200 lines or so, I see no advantage to writing in OO. Using OO? Plenty of advantage, because how else do I get my programs to be under 100 lines? Perl's brevity is in part due to the extensive CPAN library programmers can use.

    The moment you start thinking about code you would like to stick around, code you would like to keep and reuse, code you would like to share, the advantages of OO come to the fore. IMO, it takes more work to write OO, but the final product has a better defined interface, is better isolated (that word encapsulation raises its head), is easier to hand over to a beginner and have it "just work".

    It's better, in the long run, to have a 2,000 line object in a module that gets turned into a 30 line main program than 1,500-1,800 lines of functional chicken scratch. People might "get" the point reading the 30 line main program. People (including you) will forget the details in your 1,000 line+ bit of chicken scratch. You'll also forget that 2,000 line module too, but you have a better chance of going, "Hey, I sort of remember what I did here.."

    When I first started into Perl OO, I wrote an object that encapsulated a closure that gave me a date iterator. It was just practice, until 2 months later it became a crucial part of a production program. So even dabbling in OO will give you a bit of a toolkit you can put to practical use later.

    David.

      ++

      There speakes the voice of Wisdom.

Re: Object Oriented Orientation
by jdrago999 (Pilgrim) on Aug 02, 2011 at 22:14 UTC

    Try Flash ActionScript 3

    Really. It is similar to Java, yet will allow you to really get your OOP gears moving, *plus* because you can easily manipulate visual objects (boxes, bouncing red balls, whatever) you can actually *see* the results of your coding.

    Re-learning how to do the exact same things you already know how to do in Perl, in another language can be boring at best and frustrating at worst. I recommend you learn another language that can help you build on what you already know. Build a Flash front-end to a Perl back-end, connecting the dots between the two via JSON. You'll do some learning and gain some skills in the process.

    ActionScript 3 is quite similar to Java and C#, yet with the scripty feeling of JavaScript. Here is an example:

    package com.vw { import flash.display.* import com.vw.*; import flash.events.*; import flash.utils.*; import flash.geom.Rectangle; public class MainScreen extends MovieClip { public var controls:MovieClip; public var viewPort:MovieClip; public var imageCanvas:MovieClip; public var navigator:MovieClip; public function MainScreen() { // Empty constructor: } public function init() :void { App.Trace(this + "::init()"); controls.init(); stage.align = StageAlign.TOP_LEFT; stage.addEventListener(Event.RESIZE, handle_resize); setTimeout(function():void { handle_resize(new Event("dummy_event")); imageCanvas.init(); navigator.init(); },1); controls.addEventListener("zoomLevel_changed", zoomLevel_changed +); } private function zoomLevel_changed(e:Event) :void { dispatchEvent(e); } private function handle_resize(e:Event) :void { App.Trace("stage.stageWidth: " + stage.stageWidth); viewPort.width = stage.stageWidth; viewPort.height = stage.stageHeight - controls.height; viewPort.y = 60; viewPort.x = (stage.stageWidth / 2) - (viewPort.width / 2); var orig:Object = { width: 900, height: 550 }; if( x > 0 ) x = 0; // Move the controls so that they are centered: controls.x = (stage.stageWidth / 2) - (controls.width / 2); if( controls.x < 0 ) controls.x = 0; // Move the navigator so that it is bottom-right justified: navigator.x = viewPort.width - navigator.width - 20; navigator.y = viewPort.height - navigator.height + controls.heig +ht - 20; // Move the log too: App.log.x = 20; App.log.y = viewPort.height - App.log.height + controls.height - + 20; dispatchEvent( new Event("resized")); } } }
      This might be sound advice ... in a suitable context ... but you are unwittingly taking for granted that the programmer is doing client-side scripting! Sure, one of the first decisions that you must make is "what tool(s) will I write this thing in?" And let the record show that programmers can write really-good or really-awful code in whatever tool they choose to pick up.

        This might be sound advice ... in a suitable context ... but you are unwittingly taking for granted that the programmer is doing client-side scripting!

        You're absolutely right. I am making an assumption as to the environment (server-side, client-side). That assumption may be incorrect.

        I understand that the OP is looking for advice on what language to learn so that they can better understand OOP in general. Classes, interfaces, overridden methods, public/private/static/protected members, inheritance, polymorphism, encapsulation, etc. Yes it's clear that Perl has all of those things (and then some) but what isn't always clear is how Perl's way (if there is such a thing) and the Java/C#/C++ way line up together. The keyword "private" for example is "my" in Perl (sort-of). Those other languages have keywords while Perl has idioms and other tricks to Get The Job Done.

        For someone who already understands OOP quite well, Perl's power can be magnified by a factor of magnitude. You could say the same thing for those who have a firm grasp of functional programming. Having previous experience with Perl may help the OP learn traditional OO practices in a language more closely-aligned to Java (such as ActionScript 3) because similar concepts -- though with different spellings -- can be detected in both.

        And let the record show that programmers can write really-good or really-awful code in whatever tool they choose to pick up.

        Aye. "That...is the sound of inevitability..."

Re: Object Oriented Orientation
by sundialsvc4 (Monsignor) on Aug 03, 2011 at 15:12 UTC

    I find that “objects” have two very useful features, and two three very bad ones.

    Useful:

    1. The code and the associated data that it manipulates are neatly bundled together into one “thing.”   Every bit of code has easy and immediate access to the (whatever you want to call it) $self-variable.
    2. A well-considered object system makes it much easier to write “centralized” code in one-and-only-one place, then to “manage by exception” all the rest.

    Disadvantage:

    1. It can be unexpectedly difficult sometimes to deduce precisely what a piece of code will actually do at runtime.   Static analysis of the software becomes difficult.   Too much “contextual” information is needed to describe and therefore to identify a problem.
    2. Coupling.   Every descendent of a base class is more or less coupled by its ancestry.   Trouble is, sometimes companies buy other companies with altogether different business-models, and you have to find a way to make the disparate software-systems work together.   Base classes incorporate what I’ll call foundational assumptions and then derive much of their practical benefits from the resulting expressive brevity.   “Then, something changes,” and Let The Ripples Begin.   When you start making changes to one of these “elegant” systems, sometimes what you get is hideously rather disturbingly un-stable.   You feel like you’re having to perform surgery on a moving thing that is held together by springs.
    3. Religion.   Where “good software engineering practice,” which is solely concerned with how things actually are, begins to be replaced by “religious philosophy” of how things ought to be, IMHO there’s not one good thing to be had in all of that.   Because, when the dust finally settles, what all of us are doing is:   engineering.   We all must strive to create the most fanciful “castles in the air” that we can possibly devise, while remaining firmly centered upon the reality that they must float in mid-air (while we’re all heading for the pub).   Sometimes that means brilliance.   Sometimes that means “crafting a particularly elegant stone archway over the front door of a supermarket.”   (To more-or-less quote The Soul of a New Machine, “you might be justifiably proud of it, but not particularly want to admit to having been the sorry bloke who did it.”)   We love to think about the brilliant things, but the reality is that we do build a lot of supermarket archways.   (And, ahem... damn good ones, too.)

    I find this to be true whether we’re talking about Perl or not.

Re: Object Oriented Orientation
by GrandFather (Cardinal) on Aug 04, 2011 at 00:05 UTC

    You may be interested in Not quite an OO tutorial. I use OO in a very light weight way a lot in Perl. For small scripts I use it as a convenient way of carrying around context when calling various functions to get work done. It pretty much completely avoids the need for global variables and allows me to control coupling between different parts of the code by choosing between using explicit parameters in calls or by passing information in the object as part of the object's context.

    My entry point for using OO is more like a few tens of lines than a few hundred!

    True laziness is hard work
Re: Object Oriented Orientation
by jdrago999 (Pilgrim) on Aug 05, 2011 at 21:50 UTC

    One thing I'd like to say about using OO in Perl (or anywhere for that matter) is this:

    Just as proper English spelling and grammar should be well-known to a native English speaker, I wouldn't expect an English speaker to apply them to every phrase spoken or typed. Just as one can easily distinguish between the words of someone who understands English grammar and one who does not, the software written by one who understands OO will often stand out from software written by one who has limited understanding of OO.

    Once you know, you can spot the (albeit sometimes subtle) differences.

Re: Object Oriented Orientation
by Anonymous Monk on Aug 06, 2011 at 04:57 UTC

    Sometimes I use OOP in Perl, sometimes I don't. But then, sometimes I use Perl and sometimes I don't. The right tool for the right job and all that.

    One thing to bear in mind is that OOP is a concept and NOT just a language feature. A prime example is GTK+ which is OOP written in C, which has zero support for OOP.

    I dunno, do you feel that you can already use Perl to easily accomplish just about any task you want? If so, you can prolly study OOP in any language you want. If not, I would stick to Perl just so you can really develop an in depth knowledge of your first language. Not to mention that the details of learning the basics of the language will stay out of your way.

    But please, if you're in this for the long haul, at least look at many languages. IMHO, any old programmer worth their salt should know at least half a dozen languages and especially C.

    Oh, and just for the record, Perl is my favorite language because it is so expressive and I can bang things out in Perl way faster than any other language. On the other hand, Perl is useless for writing device drivers.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://917729]
Approved by davies
Front-paged by ww
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (8)
As of 2014-08-23 11:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (173 votes), past polls