My first exposure to Perl was near the end of high school when I was working as a computer assistant at the USDA Forest Service. I really can't recall the exact gut feeling Perl gave me at the time, but I imagine it was a mixture of disgust and delight. A few years later, near the end of my undergrad career, Perl came back into my life. Only instead of a few simplistic scripts, Perl was now the core language for my job.
At the USDA, my main duty was to troubleshoot and help out with small computer problems. This included plenty of mundane tasks like cataloging and auditing old unused hardware, reimaging peoples' laptops and helping people with network issues. Fortunately, my super-nice boss Keiko let me have fun tasks like tweak and mess around with the web templates (my first exposure to CSS), and write and maintain little scripts. Mike the IT guy also loaned me his llama and camel books. Both of these were written in a very light-hearted and cheerful tone. That bit really stuck with me.
Perl came in the form of a single large file that had the responsibility of summarizing and publishing journal articles to the web directories. I tweaked this file several times, and each time involved multiple searches to find where I was supposed to make changes. The script was laid out like a well organized essay. It started with an introduction of all the global variables and configurations the rest of the script used. Then it did a lot of preparation work to do checks and to satisfy assumptions. This was followed by paragraph after paragraph of all the tasks that the script was able to handle. Finally we concluded with the CGI parameters parsing and a giant block of conditional logic to dispatch what needed to be done. There was comic relief throughout the script in the form of comments the writer wrote to himself. I hated reading through it, but at the same time, I loved the amount of time and effort it saved everybody. Instead of a program, I thought of it more as a batch script of commands with just a sprinkle of glue logic to make it all come together. It could've been done cleaner, but there's are appropriate times for quick and dirty as well.
That script taught me a width breadth of new and fun things. My first encounter with regexps was in Perl, an indispensible tool. I also saw closures and used them before I even knew what a closure was. There were all these mystical constructs obfuscated by the gross overuse of implicit hidden variables and inconsistent syntax. It was like a riddle that you solved backwards by spying on it's behavior.
Fast forward 4 years to the end of my Berkeley education. I work at RSSP-IT (previously Rescomp). What's different about this new situation? Well, I know more theoretical computer science, and I also know more software engineering. I'd also like to think that I've come a long ways in recognizing good design, and hope that I can mimic and even come up with good designs on my own. Perl hasn't changed since the last time I saw it. However, instead of a few simple scripts run start to finish by a cron job, this incarnation of Perl was a decade of codebase that powered live critical systems. Here and there I still see a few scripts that run from start to finish. But for the most part, I see large systems with beefy data backends, reusable modules of logic, and complex dependencies and hierarchies. Generations of programmers sweat and sticky keyboards have gone into the code. The code could probably be plotted on a timeline to chart our follies and achievements. DBIx::Class? Great idea. Inline html for cgi scripts? That was a hiccup and a bad choice.
All in all though, I continue to feel the same love hate relationship with Perl. The funny part is that I love it for it's flexibilty in usage, but I also hate it for the exact same reason. I don't think Perl is my favorite language, but Perl will always have a special place. I love the one-liners you can do with Perl. I love the time I've spent with the Perl Monks. I love thinking about automating small tasks and finding cute solutions with Perl. This doesn't include writing a large maintainable application in Perl. That much discipline and structure just doesn't go well with this language. Sometimes you see a problem, and you can just immediately visualize the stream of gibberish syntax to solve it. You know it won't be understood by other people. You know it won't be maintainable, and someone will hate you in the future for it. You know it's a hack. But you also can't stop smiling, because you know you're having a good time with Perl.
Switch control statement in Perl 5.1.10
given ($^O) {
when (/linux/) { $file_path = '/mnt/foo' }
when (/mswin32|nt/) { $file_path = '\\C:\foo.exe' }
default { die "FOO was not intended..." }
}