One of the big turning points in the development of my programming and data processing skills was embracing Perl not only as a language for writing scripts but also as a shell tool for basic processing tasks. For a long time I had basic familiarity with common shell tools such as grep, sort, cut, and so on, and had learned to do basic tasks by piping them together. I had also learned the power of writing short bits of Perl code directly on the command line and running it with
perl -e or
perl -ne. But as I’ve gained more experience with shell tools (and hey, even more experience with Perl), my default approach to data processing has changed. For many line-by-line processing tasks, stitching Perl together with other shell tools is often quicker and more concise than firing up a text editor and writing the whole processing procedure in Perl.
I’m a huge proponent of using the right tool for the right job. Some languages are designed and optimized for certain types of tasks, and of course a programmer’s experience and preference influence what “the right tool” for a particular job is. My first programming experience was with PHP, and I occasionally find myself “thinking in PHP” while I’m actually writing code in other languages, or wishing I could leverage one of PHP’s built-in functions without implementing the entire script in PHP.
Well, I came across this underwhelming post the other day. It looks like
php -r is all that has been missing in my life…