The tech blog of Peter Shangov

Making a clean break from what draws you back is important. Whither can we go if "Perl 5" has lost its coolness factor, and "Perl 6" is already taken? But the path to world domination and greater numbers of "ninja perl programmers" and "perl rockstars" need not not necessarily go through the name of Perl itself. It did not for Ruby - it was Rails that did it. Here is my recipe:

A couple of weeks ago Microsoft launched its WebsiteSpark initiative in an effort to gain some inroads into the market share of the open-source web development stack. The Redmont giant, however, has got it wrong again. The thing is, people choose open source not only because the initial licensing costs are lower, but because it provides certain types of benefits that closed-source simply cannot provide, no matter at what cost.

Within the next week or so I am planning to announce the launch of an open-source perl project I have been working on recently and I want to create some publicity within the community. My blog currently appears only in the Planet Perl Iron Man feed, so I thought I should look into some other aggregators and get my blog included there too. There are two major problems I encountered that I want to share.

A friend of mine, a pretty good java and C# programmer, recently asked me this question while I was advocating the merits of perl and of dynamic languages in general. Why don't universities pay proper attention to dynamic languages? Why do software companies, which are run by smart people and employ smart people, use java and C# rather than dynamic languages for the enterprise systems they develop? Why are dynamic languages used as niche tools only (e.g. perl for system administration, or RoR for quick websites), and usually because an individual pushed for their use rather then because of company policy?

I promptly replied that platforms such as java and .NET are backed by billion-dollar companies that spend enormous amounts of money convincing people that their software is superior. But even as I said it, this explanation felt somewhat insufficient to me. The question has been haunting me ever since, and gradually a somewhat unexpected realization dawned on me.

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.