I can only speculate that if this 'OO toolset' is coded in some hairy, obtuse, and highly non-sensical manner, then the equivalent 'procedurally-based script' would be as awkward and as twisted as the OO version. The only thing missing would be the convenient excuse that it can't be understood because it's 'OO'.

What I mean, more diplomatically, is that while OO programming is intended to help the programmer to program better, but like discovering a new drawer full of knives and power tools, it increases your ability to hurt yourself if you're not careful.

Recently, I was working on a library that compacted and uncompacted IP packets, something like NetPacket but for a different application. The original 'procedurally-based' program ran over 1100 lines with all the various routines required to handle ICMP, UDP, and the like. It was one of those things that just kept growing and growing. At this point, while I was pretty sure where I was going at any given time, nobody else could make heads or tails of it. 1100 lines of code was just too much for someone else to soak up at once, especially when the program was doing some things that made no sense unless you had read the requisite RFCs and understood what they meant.

So, I pulled out some relatively static code that was functionally similar and made it into a module. Did that help? Not really. It just meant a lot less scrolling to find what you were working on, but things weren't any clearer. Now you had to cross reference two files to figure out what the program did.

So, I whacked away at it again, this time taking an OO approach, and knowing the scope of the program in advance having already programmed it once. I made a few objects that inherited nicely from each-other, and packed this all up into a convenient object that did all the work for you. The end result is a 'main' program that is 51 lines ling, including comments, parameters, and generous white space. The actual 'program' is extremely brief:

    report "Creating engine....";
    my ($engine) = new Framisdat::Engine();

    report "...stoking.";

    $engine->Stoke($engine_stoke_limit);

    report "...running.";

    while ($engine->Running())
    {
    }
[download]

If you don't know what the heck a Framisdat::Engine is, just perldoc Framisdat::Engine, and read the POD descriptions of the object, and its methods. If when examining the code, you discover something curious, such as a Framisdat::WonderPacket, the same procedure applies.

The real benefit of OO is that when examining the code, you only have to dig as deep as you need. Everything else is some sort of little 'black box' which you know how to operate (because of the docs) but don't care about the details.

Compare using the 'old' way of using UNIX networking with the new 'OO' way using IO::Socket. Before you had to jump through a whole pile of hoops to do something as simple as create a network socket and connect it to something. Now you can do this in one line and it has better error checking to boot.

I'm sure most people are completely stunned after reading something like perltoot. I was. It didn't make any sense at all for the longest time. While authoring objects is perhaps a little bit harder than writing regular code, as you have to think a little harder, using well written objects can be so much easier.