Yikes. Perhaps the best thing to do is not to "slurp" a file. It's a "quick and dirty" method, which certainly has its place, but perhaps not in critical produc

Yikes. Perhaps the best thing to do is not to "slurp" a file. It's a "quick and dirty" method, which certainly has its place, but perhaps not in critical production code (slurping a file of unknown size is a Bad Idea). It's too bad the File::Slurp module has bugs, and the author seems unresponsive about them, but it's not a core module, and other authors are free to produce alternatives, which is exactly what happened. Looks like the change in the fine author's code would have amounted to a two line difference. In my opinion, it would still make sense to use a CPAN module - I'm glad their orginal code is faster, and if it works with that specific use case - fine with me. The problem, obviously, is if the fine author of the home-grown code needs similar functionality somewhere else. Do they make their home-grown code into a module for reuse, or just copy/paste? Say they copy/paste and then they find a bug in their implementation years down the line (or worst, someone else does, as this author has moved on to greener pastures). Uh-oh - same problem as relying on a module, but now it's more work to fix (the code is everywhere and perhaps has evolved now independently), and there wasn't the framework of module authors, testing infrastructure, bug tracking system, peer review, etc, etc, etc there to have a drop in replacement for ya. The line to draw for reusable code is certainly yours to make. My line not to cross is when I'm practicing, "Copy and Paste Programming" - easy enough to take the extra 5 minutes and package the code up for reuse. Makes it easier to make my unit tests up and all the rest of the good practices of a Perl programmer.