FWIW when I saw the original article I had a similar reaction to chromatic. The quality of the code was such that I would object to code like that at work, and I simply do not think it appropriate that a site like http//www.perl.com should be posting articles that show as examples of how to use something code which I wouldn't like to see in production.

And yes, I identified many of the same items that chromatic did. If you are lining up long chains of variable names and hoping that you have the same number, in the same order, then you are going about things in the wrong way. I am quite sure that there is plenty of code in the world that does that. But they should not be appearing in prominent Perl sites as examples of how to code.

In fact most of your complaints about things that involve "manual coding" are things that I look at and would never code that way. If you are writing large amounts of code that looks like repetitive cut and paste, there are usually better ways to do it (quite easily) in Perl. I would expect a good programmer to find those ways. And conversely a programmer who does not find those ways will usually benefit from a discussion about how to do it better, and why it is important to do so.

Other complaints I simply disagreed with. More on that later.

This is not even getting into nitpicks. For instance a good editor should have caught your using Angryman as a data structure, and asked you to use a less provocative name for that.

Until those issues are addressed, it will be hard for me to read that article and get a sense of how those modules would compare in the hands of a competent programmer. It is not hard for me to look at the list of things that you are saying are improved in DBIx::Recordset and tell that the abstraction, at least as you are describing it, would not be appropriate for the actual situations that I am coding against at work. Likewise your list of things that you are complaining about having to do repetitively with DBI are things that I don't have to do repetitively in the situation I am working with.

And now I just went to look at what chromatic was talking about about placeholders. What I saw simply convinced me that there is a lot about programming well that you either have not bothered to learn, or you saw it and thought was bunk.

Here is some commentary of one repeated obvious mistake in your code example at the end. Those who want to see the code that I am about to criticize can go here. Those who want to keep any illusions of me being a generally polite nice guy should skip this. Those who read on should note that this is far from a comprehensive criticism of everything that I saw which needs improvement. And princepawn, I sincerely hope that you read this, get off your high horse, and learn something useful.

You use gratuitous globals everywhere. Not only do you use globals with very generic names, you are forcing them into package main where they can conveniently collide with any other gratuitous globals you write. In mod_perl you would have just gone out of your way to create a perfect setup to have stale data from one request pollute the next. Congratulations.

Some of the globals are conceivably reasonable globals. They are registration data that you might have a reason to use elsewhere in the program. But some of the globals are just stupid. For instance you have an insanely_long_function_name which has no purpose other than to set up $::INSERT_TERM so that you can do an insert in the next function.

Does this variable really need to be global? How about global and in package main? Is creating conflicts so important to you that you need to work so hard to defeat the hapless maintainer that tries to introduce a little sanity with package? Have you heard of this little innovation called returning a value or another silly idea that a few clearly out of touch programmers use called passing a parameter?

One almost can imagine that in the distant past some hapless programmer faced with your code tried to introduce some sanity with a package command. After that broke everything, you decided to defend yourself by always using package main rather than learning how to program better.

An alternate theory is that you heard somewhere that strict was a good idea, but never saw the point of using vars rather than fully qualifying your variable names. So you fully qualified everything into main (less typing, and makes it easy to violate every rule you are ignoring about encapsulation etc) and promptly lost most of the practical benefits of strict. But you didn't actually understand why strict is beneficial, so you never realized that.

You know, if you really need to share variables between packages, that might be what this handy module known as Exporter is for? I know you have heard about it, because I mentioned it to you before.

Now that mention is interesting. Your entire idea of selecting * from a table and having your code figure out how to handle that is a stupid idea. I spent a good deal of energy in that post trying to explain to you why that was bad and what a saner approach is.

Apparently you didn't listen. Somehow I am not surprised. You don't appear to spend much time listening. You think that the rest of the world should listen to you though.

Now if you want an answer to the question I ask there, along with a few other comments that would be good for you to take to heart, I would recommend reading the end of About white shoes. My comments there would probably have been even harsher if I knew exactly how little you appreciate about basic things like why you should avoid globals everywhere.

The fact is that right now you clearly have so little appreciation of basic principles of how to program that I don't care about your opinion on what modules you like. You simply lack the skill level necessary to make judgements on that that I would find even remotely useful.