it may be the case, that a perl monk is not pushed to a OO perinciples while programming in Perl and that a humble monk may spend all his life coding (un)structured script ...

False dilemma—there are plenty of ways to write well-structured code without writing object-oriented code. Learning new techniques is good, but using the techniques you already know appropriately is better.

Until you get to about 1000 lines of code (either that you wrote, or including a library), objects are actually more harmful than helpful. That's because it'll take about 1000 lines of code before you need inheritance. And if you're not using inheritance, you really don't need objects. Data hiding is cool, but with a rich set of data structures as primitives, Perl doesn't have that "urge" to "go objects" as early.

Since 80% of the Perl applications in the world are under 100 lines (maybe even under 20 lines), it's no wonder that most Perl applications don't use objects.

Sure, learn objects for large apps. But don't make the "java" mistake, where you must learn them for every app (even though Java is a partial non-OO language as well: it's the worst of both worlds!).

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

I wouldn't say inheritance is the end-all criterion to decide whether to use OO, nor even is data hiding. I relatively often find myself using OO even when I need neither.

I often have a bunch of functions that all deal with a specific, non-trivial data structure and only make sense in the context of this data structure. In this case I usually bundle them into a class and then use the OO syntax on the resulting objects so as to have that data structure implicitly passed around. I am not doing real OO there of course, but the syntactic sugar makes the code easier to read - sometimes dramatically so.

See rules 2, 6, and 10 of Damian Conway's ten rules for when to use OO.

Makeshifts last the longest.

i don't write much java these days but i've reviewed a fair amount of other folks' java code and i can confidently say that java does not force developers to learn OO principles. i still see entire applications that are just one class with a hundred methods, passing all the data as arguments. some people write C in every language.

i don't think that's necessarily a problem with java. the fact that you can escape the OO paradigm even just a little is probably a pro for java. just that if one is thinking of using java solely because they think it "forces developers to learn OO principles", they may want to re-consider.

anders pearson

Agreed. and some write Basic in every language. I once saw a Turbo Pascal program that started with half a page of labels, one page of variables and the rest was just

begin
 ...
 ...
end.
[download]

and the whole program was about 15 pages.

I still don't know how could that person make that mess work.

Jenda

I don't like perlboot, since it makes the all-too-common mistake for OO introductions of stressing inheritance to the point of making it seem like the whole point of OO is inheritance.

I do lots of OO programming and I don't use much inheritance. And when I do use inheritance, it is almost always interface inheritance using a purely virtual class that simply defines an interface and includes no implementation.

Unfortunately, Perl OO doesn't really support interfaces (unless you consider a simple list of method names to be an interface) so this type of inheritance is pretty pointless in Perl.

So I find inheritance to usually be the wrong answer in Perl. And yet I find lots of people who decide to "go the OO route" in Perl and immediately start thinking "what should inherit from what here?"

The point of OO, especially in Perl, is to nicely wrap all of your related data up into a convenient package that also knows the things that you can do with that data.

I find that if I'm writing a module, then it is best to just write it using OO, no matter how small it starts out to be. Without even thinking about it, you'll likely end up with a module that is much more robust in the face of being used from multiple parts of the same program and yet has a much lower risk of namespace collisions.

        - tye

I don't like perlboot, since it makes the all-too-common mistake for OO introductions of stressing inheritance to the point of making it seem like the whole point of OO is inheritance.

Inheritance is only one of many topics. There's also "the magic first parameter" and "instance data" and "blessing" and "class methods versus instance methods". I wouldn't say inheritance is "stressed": they all get equal time in the examples. If there was anything less about inheritance, it wouldn't be in there at all. Would you prefer that? {sigh}

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

I guess there are several ways to look at this...

Perl programmers take the lazy way of not learning or implementing OO since they are not being forced to, and so they are not "OO programmers". Or Perl programmers do understand OO, but choose not to use it as often and so there appears to be less "OO programmers" around.

Any programmer worth their salt will investigate different tools, like OO, and use them as appropriate (as apposed to being forced ala Java). For all others, it is not worth the effort to push/pull them -- OOP is not a magic bullet and will add nothing to them.

bluto

A major advantage of an clean OO approach is that it forcese one to analyse a problem clearly and impose appropriate structure on the solution.

While working on a problem it happens very often that the OO approach "suggests" itself. Code tends to get messy if it's more than a page or two, and while restructuring it to bring some order, usually one notices ways to bring it to a higher level of abstraction, often in terms of classes and objects.

After all, for most real world problems we are actually dealing with objects that have properties, that we can do things to or that can do stuff themselves. In a sense it is only natural to model that real world in terms of the objects it consists of.

Of course, as has been mentioned, OO is not the answer to every problem, but very often it offers a clean, nice and abstract formulation of a solution, intellectually and estetically satisfying.

Just my 2 cents, -gjb-

OOP is not the only way to get a clean design.

I have seen the argument alot, and always attempt to pipe up with "It can be done cleanly in structured coding as well". Granted I do not have "formal" edjucation in programming, having taught myself C and Perl over the last few years, both OTJ and during my spare time, and my largest projects have only been a few thousand lines of code.

The main advantage I see to OOP is the namespace segregation , but that does not automagically imply a clean design or interface. Whats the difference between

for ($some_obj->get_line()) {
   ...
}

for (&Get_Line()) {
   ...
}
[download]

One is cleaner?
One shows a better grasp of the data?
One is faster?

In this instance, those questions can't be answered due to lack of further data. It's a pet peev that OOP designs are always touted as being superior/cleaner.
As someone pointed out earlier, the OOP approach can be a hinderance until the code base is at a certain length/complexity, and forcing your code to be OOPish can extend your devel cycle unneccessarily.

I am not con-OOP, and I am not attempting to bash the post this is in reply to. It simply amazes me that people need a 'method' of doing something in order to cleanly define an applications functionality and flow. I mean, it requires the same amount of work to write a clean top down app, as the amount taken to write it in an OOP fashion.

People talk about well this way we can change what the function is doing without modifying the interface to it. You can do the same in a structured program. You can use the same levels of abstraction. The only difference I can see to the 2 approaches in Perl is

Top down, you are dealing strictly in main's name space a derivitives thereof (read sub functions name space).
You need to keep track of which piece of data you are dealing with right now.

OOP you have a seperate namespace for you data "over there", which in my viewings isn't below main's namespace but beside main's space.
When you create your object, it keeps track of which data you are referencing at a given point in time (no pun intended), hence freeing you from keeping track of one more piece of data while developing or using a piece of software.

It feels like OOP to structured programming is kinda like C to perl (bear with the analogy for a sec). It feels like people say "Oh, it's to easy to muck with (namespace|pointers) that way, so I'll just write it in (OOP|perl). That way it will be nice and clean".

This statement isn't necessarily true, but it's a trend I see, and wonder about.

Sorry, about the rant, and feel free to mod down. I don't know if my lack of formal training has excluded anything that is glaringly obvious for others.

I guess my point is. I like top down, structured Perl. It works for me. I define clean interfaces to my data. The functions that are usefull go into my personal lib that I port around with me. If others like OOP that's fine too. I use the modules from cpan, which are all OOP. I use them to maintain consistancy and portability, as well as avoiding reinventing the wheel, not because I think that it is necessarily the best way to do it. Sometimes I'm rather shocked at the results of attempting to use a module, both in terms of memory utilization as well as speed, which if I remember correctly are drawbacks of the OOP methodology, and something to be corrected down the road by individuals far smarter than me.

/* And the Creator, against his better judgement, wrote man.c */

Programming is all about modeling, one tries to choose the model that's most appropriate. Personally, I like to think in terms of objects, classes and the relations between them.

Using OO will not guarantee that one ends up with clean and nice code, on the contrary, I've seen awful things done with OO. Using a structured non-OO approach can result in nice and clean code, but both are beside the point I wanted to make. I guess I haven't expressed myself clearly, I should have said that I tend to end up with a clean and elegant model using OO techniques since it reflects the way I look at the world (and hence the problems I'm trying to solve). Of course, it all depends on one's personal mode of thinking.

And incidently, I've no degree in computer science, I'm just a humble physicist. -gjb-

And no monk will be pushed to the Java world just to learn OO .....

That's why there's Python!

Not a troll, just saying variety's good, at least until Perl 6 comes along :-).

I work as a programmer and have used many, many languages in my various jobs: C/C++, ksh, perl, Objective C, awk, Java, PL/SQL, and on and on and on. And on.

Perl is one of the tools in my toolbox. Granted, it's my favorite tool, and often the best tool. However, it is not the best tool in every case. I like Java because it lets me write code in OS X that can be used anywhere. I like Objective C because it is what C++ should be. C and C++ are great because the compiled code will run so quickly without the source code being as grungy as assembler. Yesterday, in a shell script that I inherited, I used sed for a 's///g' in a long string of pipes.

Now, having said that, I have to emphasize that my instinct is to reach for Perl. A lot of what I do is parsing text; enough said. Oneof the nice things about Perl is that it is object oriented, but it doesn't have to be. I write a lot of quickie scripts that just need to work, so forcing OO would be like tying a school bus to the back of a horsecart.

A Perl geek may not be pushed to OO. This is not necessarily a bad thing, as a lot of us would consider it a dashed liberty if we were. However, it is there if we need it, and it can provide a good introduction to OO. To me, that is one of the beautiful things about Perl. The decision is left to the programmer, so we can adapt to the situation.

(Puts soapbox away, crawls back into hole.)

--
tbone1
Ain't enough 'O's in 'stoopid' to describe that guy.
- Dave "the King" Wilson

I'd say the reason that a lot of people can use Perl without learning OO is a good thing. It means they can get things done without having to bother learning too much, a few basic commands and you have a useful program which you can understand.

Ever seen how much hand-waving most Java books end up doing when trying to explain what the 'public static void main' bit means in their Hello World programs? When people want to get things done (Which is the real purpose of a language) Perl doesn't stand in their way unless asked to.

Perl is a nice 'compromise' language which shapes itself around you rather than the other way around.

If people begin to want to write large programs they will (hopefully) read up in a few of the right places and realise the proper way to do this. Now is when they'll learn OO, and in my mind now is when they need to learn OO. Personally I don't consider Perl to be the ideal language to learn classical OO from, it uses too many of it's own mannerisms and when looking at OO Perl it's difficult to tell the wood from the trees.

All things considered though I don't think Java or C++ s the ideal language to learn OO either. Both are good languages which I do use (I was hired as a C++ coder here, and am sometimes called upon to give my own odd perspectives helping the main team which are Java people), but Java lacks too many things which I think OO programmers should know (Multiple inheritance, Operator Overloading, Pre and Post conditions.. etc.), and C++ both lacks them and adds in some tricksie memory handling. If learning OO is the goal I'd point people towards Eiffel. I'd never really suggest using it in production, though.