Perl is quite different to languages such as Java and Python. It is an open language with relatively few pre-defined ways to do things. This is one of the greatest strengths of the Perl language. It allows the language to evolve over time. It allows the language to change and to adjust to new methodologies and concepts without a gutting of the core language.
One of the core values of Perl is TIMTOWTDI, or "There Is More Than One Way To Do It." This too is different from other languages whose 'how to do it' is often defined by large commercial organizations or 'language elites' who decide the course of the language. Today we will look into TIMTOWTDI and explore some of it's effects, both good and bad.
TIMTOWTDI is often hailed as both Perl's highest virtue and one of its biggest failings. It is called a virtue because you are not locked into anyone's pre-conceived notion of things. It is called a failing because often There Are Far Too Many Ways To Do It. As is usually the case, the truth lies somewhere in the middle.
I believe that TIMTOWTDI is a high virtue of Perl. Among other things, it indicates a level of permission to do things that would be verboten in other languages. Changing the language's core concept of Object Oriented Programming would be unheard of in Java or Python. Yet here in the Perl world, Moose is doing exactly that.
TIMTOWTDI leads to an organic growth of the language and the methodologies that are used within the language. This can lead to the problem of competing methodologies, as evidenced by the many different templating systems and database access methods that are available on CPAN. Fortunately, as is often the case in open source software, over time the competition is whittled down to a small group of actively maintained options. People join and leave projects and not-so-good projects are abandoned in favor of better ones.
On the whole, the process works. Unfortunately the process is not light-switch fast and doesn't always result in a single remaining option. The competing systems often run side-by-side and it takes a long time for any of them to emerge as a winner, if any of them do at all. This leads to what some have called the 'Paradox Of Choice.' The argument goes, roughly, that because there is no 'right way' declared from on high, the Perl community and indeed the individual developer suffers a sort of paralysis when choosing from the many options available for any given thing.
This is to a degree true, but it is only a problem if you look at your choice as a permanent one. If you allow yourself the freedom to pick one, with the knowledge that if you find it to be unsatisfactory later you can change your mind, the paralysis evaporates and you can get on with things.
That said, what I have described so far is the best interpretation of TIMTOWTDI. There is, unfortunately, another interpretation. Many Perl developers learn of TIMTOWTDI and think that it means anarchy. They think that it means that they can do whatever they like. They arrive at a mindset that the permission granted by TIMTOWTDI means they can ignore best practices, or worse, that there is no such thing as Perl best practices.
Let me be clear: Perl has best practices. They are the methods that have been subject to the Perl community's organic, evolutionary process. They are the methods that are the fittest and that have survived.
This, however, is the curse of TIMTOWTDI. People who do not fully grasp the concept take it to mean they can do whatever they want. It is used as a excuse for why they ignore an established method:
"Hey, I know there's another system that already does this, but I'll do it my way. TIMTOWTDI."
It is used as an excuse not to change when they are gently rebuffed for doing something the wrong way:
"Hey, I don't have to do it your way, TIMTOWTDI."
And much much worse, it is used as a reason not to gently push folks in the right direction:
"Hey, they can do it however they want, TIMTOWTDI."
This is a sad state of affairs indeed.
What everyone approaching Perl needs to realize is that Perl is not a language you can read a book about and be done. Real Perl programming is about 40% the Perl language, and about 60% the tools, methods and modules you use. You can learn some of these methods from books: Effective Perl Programming is a favorite, as is Perl Best Practices. Unfortunately, because of the highly dynamic nature of the Perl language and Perl community, many new options are already available by the time a new book is in print.
The truth is that this is one of the reasons Perl is such a fun language to work with. If you pay attention, you will never lack new things to study, learn and use. It does mean, however, that new Perl developers have a very daunting task ahead of them indeed.
There is no narrow concrete path to get you from point A to point B as you might have in a language such as Java. Perl instead lets you have a nice open field with a pond and some trees but expects you to be disciplined enough not to run headlong into a tree or walk into the pond and not climb out.
And this is where us old-timers of the Perl community come in. We have been so wrapped up in what we have been working on, so wrapped up in the joy of exploring new fields and ponds and trees... that we have sorely neglected those coming to the language fresh. We have done a piss-poor job of helping our newcomers navigate the many options available to them and it has hurt our community in general.
If we want to see this change, it's up to us to do it. We need to step out of our grumpy and too-busy areas of comfort. We need to give up the excuse of TIMTOWTDI and start posting what we have found to be the best ways to do things. We need to stop being concerned with the opinions of other CPAN authors and help our newbies decide what to pick by telling them what tools and modules we love. It's time for us to embrace the other motto of the Perl community: JFDI - Just F*cking Do It.
What we all need to realize, especially us old-timers of the Perl community, is that we need to steward our newbies. We need to take them under our wing and teach them that there is more to Perl Programming than the camel book will show them. We need to gently teach them the discipline required to do things well.
If we can not accomplish this, if we cannot take on apprentices, if we cannot effectively spread the knowledge of our language of choice, ours will be the last generation of Perl developers.
This would be a sad thing indeed.