nysus wrote:

Is the fact that many modules are written with OO code good enough reason to learn Perl OO programming?

No. Many CGI programs are written using cgi-lib.pl. That's not really a good reason for learning that module (this is along the lines of "if all your friends jumped off a cliff..."). Instead, if you want to learn how to maintain OO code, that should be a good reason.

Of course you can get by without it. I can get by without ever buying new clothes or trying new food, but why would I want to?

Learning new ways of programming opens up ways of looking at things that you probably haven't previously considered. A great demonstration of this is reading tilly's post Why I like functional programming.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Also just as learning a new language (natural or programming) will get you a better insight into your 'own' language. Learing a new methodology will give you better insight in your old one. Same goes for learning functional or logical programming (ie. Prolog).

The bottom line is that if you only know one thing it is difficult to compare it with something else.

Have Fun

But I wouldn't go full out to understand all the various OO idioms that you can use or inheritence or other details that can become important in OO. If you do end up doing OO, they might be useful, but for straightforward perl programming, they won't help.

My basic philosophy of programming is that if I have to do something more than once I'm going to put it in a module or a library or a library of modules and never write it again. This in essence is where OO programming enters the picture.

If you can create a base of good objects that you can re-use and keep stable you save yourself a lot of work later on. Not only that if you have written your modules correctly and in a concise fashion anybody else that has to maintain your code will be able to understand what you did in the first place.

At my current consulting assignment there are two basic classes of code that I have had to deal with here. There is the stuff that was written in an OO style and the legacy stuff.

When a defect is reported in the OO stuff I can usually track the problem down in a manner of minutes. If the legacy stuff breaks, and it does often, I can be chasing my way around the code for days trying to find a problem.

Get by? I'm not sure what that means to you but I'm not sure that getting by is acceptable...

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Peter L. Berghold --- Peter@Berghold.Net
"Those who fail to learn from history are condemned to repeat it."

a lot of people seem to have the idea that you can't have modular, reusable code without object orientation, and vice versa.

yes, it's true that properly written object-oriented code is very modular and reusable; it is even true that object-oriented techniques make it easier. but they are separate concepts. OO is a way of looking at the relationships between data and functions. modularity is about getting to reuse code easily and cleanly, without having to rewrite all the places you use it.

remember that perl modules existed before perl OO; in fact, a perl class is a special case of a perl package. using Exporter, or any of a number of other techniques, you can write a module that is useful and, well, modular, without being object-oriented.

should you learn modularity, reusability, genericity? yes, yes, yes. that's what programming is about, isn't it? making instructions that will be reused on many sets of data, so that you don't have to do the same things over and over yourself. writing code clips to be used in multiple programs is just taking that a step further (and i think we will never finish taking those steps). but that isn't what you asked.

should you learn object-oriented programming? i think so. i find it a great way to solve most of the large programming projects i face. i find it refreshing and invigorating. and perhaps most to the point, i think more and more programming will be object-oriented, so if you still want to be writing code in 19 years, i recommned learning object-oriented.

should you write your OO code to be modular, reusable, and as generic as it makes sense to do so? yes. is it possible to write OO code that is mangled, tangled, unmaintainable spagetti you'd be ashamed to show your hair stylist? yes, actually. it's easy. but you shouldn't.

.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar";
$nysus = $PM . $MCF;

"Master" is a very strong word.

Why "Master" something that you are not using?

My experience has always shown that there is an ongoing process of learning in anything. Requirements will guide you to greater "mastery" of something you have already been exposed to; But if you limit what you are exposed too, then you might miss out on a better tool for a particular problem.

IMHO Keep exposing yourself, "Mastery" will rarely come but greater learning will come naturally as neccessary.
Specialization is for insects.

learning OO will give you another tool ( or toolset, as the case may be ) in your toolbox. that's always a good thing.

the new perspective OO can give also helps.