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

should I stop where I am, and come back to learn object orientation in Perl?

It really depends on what you're learning from, and your current level of knowledge; too many new ideas introduced too quickly will only leave you confused

Safest course is finish studying your java material, learn what its trying to teach you, then revisit perl, via Beginning Perl Chapter 11: Object-Oriented Perl, followed by the Objects chapter of Modern Perl

Compare similar concepts from one to the other, and revisit any parts that make you pause or raise questions

Is the concept of object oriented languages closely related enough for the knowledge of one to help set precedence for the knowledge of another?

Learning an object-oriented-language usually only teaches you the mechanics (axle, wheels, steering, engine ... how to make object, call methods, how method dispatch works...), it doesn't teach you how to drive (what should be an class/object, what properties/methods it should have ... object oriented design)

Some links about OOD

• Code Complete, Second Edition
• Code Complete, Second Edition
• http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion)
• http://en.wikipedia.org/wiki/GRASP_(object-oriented_design) (General Responsibility Assignment Software Patterns)
• What You Can and Cannot Teach about Encapsulation
• Introduction to Computer Science using Java
• What Is Object-Oriented Design?
• ...

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

Comments, suggestions? Do ya'll use OO Perl a lot?

++

There speakes the voice of Wisdom.

However, even though I've come quite far in Perl, I have yet to pursue Object Oriented Perl.

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?

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!

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

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.

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"));
    }
  }
}
[download]

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

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.

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.