That said, we also like to improve existing modules and release those improvements. Why? Because we can save other people time by telling them how we fixed a problem we ran into.

This isn't to say that learning how something is done is a bad thing. In fact, it's a good thing. But, telling someone to roll their own when all they need is to have this thing work in three hours ... that's not very wise, nor is it Lazy.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

dragonchild: "Seekers of Perl Wisdon. The idea is to find out how to do something in Perl. The way most professionals use to interact with DBMs and RDBMs in Perl is to use modules like DB_File and DBI. We tend to not roll our own when a perfectly good solution exists."

Actually i was presenting another option with "rolling your own stuff", not implying to use it but to consider it, nor did i say use it to interact with a DBM or RDBM, i meant more directly.

The way you represent yourself as professional, to draw a difference between you and me, is just childish.

Since we don't know the performance criteria the seeker has, we can do nothing but provide options, and leaving out one is not professional in my view.

professional n: One who earns a living in a given or implied occupation

For instance a professional Perl programmer would be someone who makes a living by programming in Perl.

For example I am a professional Perl programmer. So is dragonchild. I do not see dragonchild's comments about his being a professional or the behaviour of professionals to be in any way childish. Rather they are precise and accurate.

As he said, decent professional Perl programmers do not as a rule waste their time and their employer's money by rewriting dbms or DBI without a very good reason. Generally no such reason exists. Certainly performance does not qualify. If Perl with those tools available to it does not perform adequately to the job, then the odds are excellent that the bottleneck is not in those tools. Look to your algorithm, data structures, and failing all else your language. (Good professional Perl programmers will tell their employers to use something else when ploughing ahead with Perl would be unwise.)

Professional Perl programmers who waste resources in reinventing good available wheels are generally liabilities for their employers. Competently run companies seek to eliminate such liabilities. Usual techniques include training, moving them into different roles, and firing.

Awareness of this fact is one of the reasons that decent professional Perl programmers who wish to remain so (which is most of them) behave as dragonchild describes.