Why I Stick with Perl
This is the obligatory general-purpose evangelism piece that every perl hacker ends up writing sooner or later in his or her journalling career. Mine comes as only the second article in this blog, and is dedicated to what has recently become an increasingly controversial aspect of the perl culture - the dreaded There Is More Than One Way To Do It design philosophy. This article suffers from an abundance of generalizations, but too many details would have made it unbearably long to read. A more useful discussion may ensue in the comments.
Many argue that TIMTOWTDI is the curse of perl. It confuses beginners, increases the learning curve, makes it difficult for companies to enforce programming standards, makes it difficult to establish criteria for evaluating job candidates, etc. These arguments are by all means true. But for me, having programmed in a number of languages, TIMTOWTDI has emerged as probably the number one reason why I persist in preferring perl to anything else on the market.
A great example of TIMTOWTDI in action is Catalyst. I recently spent several months learning it and developing a relatively complex application. It was indeed very frustrating at the beginning. Catalyst supports a bazillion configuration formats and different parts of the documentation provide examples with different formats, and it is not always straightforward to translate from one format to the other. I had a tough time figuring out which form generation and validation library to start learning, since I had never used one before (Which one has the functions I need? Which one is best integrated with Catalyst? Which one has the best documentation?). Trying to understand the multiple ways in which access control can be implemented made my had spin. And so on, you get the idea.
But at the end of my learning experience I was happy. Having grasped the fundamentals of Catalyst I knew I could use any templating system I needed, plug in any storage model I needed, and generally deal with any circumstances whether planned by the Catalyst authors or not. I felt exhilarated and brimming with power. I felt like Popeye the sailor after eating his spinach. I felt I could rule the world.
I have done serious web programming in two other languages besides perl - C# and PHP. Late last year I joined a team working on a large web portal written in C# and .NET, and I had the chance to learn learn the .NET web programming patterns. In .NET there is generally one way and one way only to do things - which is sometimes good, and sometimes it sucks big time. I won't go into detail, but you don't feel powerful doing web applications in C#. You feel trapped.
With PHP, on the other hand, you have a proliferation of frameworks and tools, but the overwhelming majority of them have their own view of the universe and usually come with their own stack of tools developed by the framework creators and designed to be used with this particular framework exclusively. Diversity seems to come at the price of constant reinvention of the wheel. You end up feeling you could rule the world, but you'll have to use a different type of army for each individual country, and some countries will probably not surrender at all, and also things tend to get pretty messy with the larger countries, and in the end it is just too much work to bother so why don't you just give up your global domination plans altogether.
The bottom line is, perl powerful because it tends to provide a level of abstraction that you just do not get in other languages. Perl itself, as well as perl's frameworks and tools, have been designed from the very start to accommodate diversity and deal with the unexpected. The perl module author is trained to make very few assumptions about how you are going to use her code and leaves a lot of room for choices. And the knowledge that I can make choices gives me a warm fuzzy feeling and lets me sleep well at night. Choice creates competition and competition creates evolution. I may be a strange bird, but I love the fact that I can choose what object-oriented programming framework to use. I find it comforting to know that I can choose what regular expression engine I want to use - even though I would probably never do that. I am grateful to be able to work in an environment that inherently acknowledges that each solution is imperfect and the least imperfect solution tends to be different for each individual problem.