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 */