You are mixing several issues together here.

1. OO versus procedural (not C versus Perl).

   Your title is:

   Help me avoid writing C Programs in Perl

   But then you say:

   What are the arguments in favor of ... versus writing procedural code?

   You can write very effective procedural code in Perl, without resorting to writing C. You can use functional techniques; 1st class functions; closures; et al. None of which are available to the C programmer. Who conversely can write OO code with the use of simple, but very powerful and efficient libraries like the C Object System.

2. dynamic code (e.g. Class::Accessor and Class::DBI), versus writing procedural code?

   This is another conflation of several ideas.

   There is are considerable distinctions between OO code & code generation. And between compile-time code generation & runtime code-generation.

   The modules you list, (and that your point guy seems to prefer not to use), are OO, but the distinctive part is that they are compile-time generators.

   The best argument for compile-time code generation, is that the less code you write, the less bugs you can introduce.

   With the second best argument for being the ease of maintenance over cut&paste or hand-coded, if across-the-board changes or bug-fixes are required.

   But there are also caveats. Here are a few:

   • The first requirement is that the code-generator modules you used need to be not just well-tested, but well exercised. Especially in the area(s) of your application.

     Using a well tried & tested module for a type of application for which it was not specifically designed or exercised can mean you're the path-finder as far as a new class of bugs is concerned.

   • It can increase the maintenance task when changes required are specific to individual subclasses of a generated superclass.

     Where one subclass of a generated superclass needs a particular change, but other subclasses do not, you may need to create a new superclass, or layer of intermediate subclasses to accommodate the disparate requirements.

   • Poor performance can be a penalty of generators.

     Eg. Go overboard with something like Params::Validate, and the costs of all the checking can significantly impact the performance of your code.

     An alternative like Class::Contract that allows you to disable runtime checks for production may be a better choice if performance is any sort of an issue.

   • Mix and match several different generator type modules, may cause you to paint yourself into a corner because they don't play well together when really exercised.

     Something like Moose may be a better choice if you have complex requirements--but be aware of the performance issue.

3. He writes all his accessor/mutators out manually using vim code snippets or an IDE. He claims that is safer and more maintainable that using dynamically generated closures and abstracting things like that into the background.

   Consider briefly that he may have a point.

   Developing a class using a well designed IDE can be just as quick as using a generator. You may end up with more code, but if most of it comes from fill-in-the-blanks templates, it doesn't take long to produce.

   And when bugs arise--and they will--code that seems so convenient because you didn't write yourself, can soon become a burden. And doubly or triply so for generators.

   1. You have to start fixing code you have no familiarity at all.

      Not just code you can't remember, but code that may use techniques and coding standards that are totally alien to you.

   2. Debugging code is hard enough.

      Debugging the code that produced the code that contains the bug can orders of magnitude harder.

   3. Any changes you make have to be done such that they will be accepted back into the module by its authors.

      Otherwise the next refresh and you'll find yourself having to fix them again.

   4. That can be compounded again if the bugs live in a dependency of the module you used.

      Now there are two sets of foreign authors and all of their constraints and goals to take into consideration in addition to your own.

To summarise:

• Clarify what you are arguing for and against.

  Mixed up arguments allow one weak point to be shot down, and the rest of your (even good) arguments to be summarily dismissed.

• Emphasis the difference between compile-time & runtime dynamic code.

  Perl tends to blur the lines between the two, but the former is far less costly in terms of performance, and far easier to debug, than the latter.

• Pick your dependencies carefully. Just like kids, dependencies have their costs as well as benefits.

  Too new born and they'll keep you awake all night--but you'll be the one screaming.

  Too mature, and the experienced helpers will have moved on to pastures new.

• Look for short dependency chains.

  Bug identification, acceptance, and fix times will go up to the power of the depth of the dependency chain.

• Seek out mature and well-tried (in your type of application), modules.

  Real-time modules may be wonderful in their domain, but are naff all good to you if you have long running, indivisible processing to do.

• Not everything lends itself to being OO.