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.

.