One of my first CPAN modules was Business::ISBN, a module I made to solve a dirty data problem a publishing customer handed me. In their large Excel file representing their catalog of books, they knew they had a lot of bad data. It hadn't really mattered too much before they had a website because the editors and sales people knew what the data should be; the web not so much. Could I fix it?
Although it might not seem like it now, reading data from Excel from any programming language outside Windows was a pretty big deal. It was practically science fiction. "Any sufficiently advanced technology is indistinguishable from magic." Back in the day, a facility with Perl was magic. It accomplished things we take for granted today, especially with so many ways to do it.
The ISBN, the unique number that forms an identifier for the particular form of a book, is a packed string that tells you the country code (now called the "group code"), publisher code, book identifier, and a one-character checksum. Unpacking all the fields isn't so simple. The first three things are variable length and a restricted set of valid values assigned by the international agency that assigns them. To check my customer's data I'd need to check each part.
As I solved this problem, it seemed that Perl was pulling me along rather than me forcing a solution on it. My experience had been in mainly C and FORTRAN at that point, so any non-trivial task took a lot of work. FORTRAN actively tried to subvert any attempt to get useful things done, I thougt. Many languages commit themselves to purity of thought. Perl commits itself to expressiveness. See, for instance, Larry Wall's Second State of the Onion.
Each time I needed something to manipulate a string, and that was most of the tasks, Perl was waiting for me to catch up. It already had something waiting for me to discover in perlfunc.
Even in my Learning Perl classes today I suggest people read through perlfunc to see what's possible so they can recognize that path that Perl lays out for them.
The outcome of that project almost seems prosaic now. Within half a day I identified a tenth of the data as dirty and could mostly guess where the error was since I knew their publisher codes. Even better, I could easily report it in any way that the customer found most convenient with the quickest turnaround. A few back-and-forths and we had it figured out. It truly was magic.
Although I'm known mostly for being an advocate of Perl, I've tempered my assigned fanaticism by saying that I'd eagerly switch to something more useful. I just haven't found that yet. And, I've tried lots of things since then, finding many good ideas each time I learned a different language.
Over twenty years later, I still find that Perl leads me more than I have to invent what I need. Perl's initial popularity in its ease of text processing now manifests itself as CPAN, the vast repository of ready-to-use solutions to most problems I'm likely to run into. If I have something I need, I've learned to check CPAN before I start coding. CPAN pulls me along, now.
Take none of this to mean that Perl will give you the same experience. As a language it's completely capable in almost all regards, but your connection to it may not be the same. You might find the same thing in some other language. We have so many because we have so many ways of thinking. If you haven't found that language that pulls you along, keep looking. Know there's one out there, and maybe it's Perl.Tweet