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.
Like most other programming languages worth their weight in salt, Perl has a relatively steep learning curve. In order to become talented one must learn the tools of the trade.
There's always more than one way to do it, even in the most structured programming languages. No excuse really. Indeed, Perl is more flexible in this regard, but not exceedingly so.
Such flexibility fosters creativity and challenges smart people to become even smarter. We're not helping newcomers enough?! Not many programming languages out there have such a plethora of documentation, wiki sites, articles, tutorials, chat rooms, ad infinitum.
Kiffin, You are definitely right, there are a ton of resources out there... The problems I see are three-fold.
First, if you are not in the Perl community already, it's hard to know where to look for good information.
Second, there is precious little available to help the newbie navigate the huge amount of information out there.
Third, it is near impossible to figure out what the good modules are for any given task.
We seem to have a lot of 'How' information but very little 'Why' information. To those who live in the Perl community, it's not a big deal. For a newcomer, it can make all the difference in the world.
We need to work on that, I think.
I definitely agree with you that we need more "why" information. I think it could also be beneficial to have a link to "alternatives" on search.cpan.org. I don't know how many times I've rummaged around CPAN trying to find a module for a particular problem, and in the end I've had to go to IRC to get a good answer to the question.
This kind of information really should be indexable and searchable, to quote mst's ironman talk.
Just to give you an example: I was looking for a module to work with XML, and there is a ton of them on CPAN. Because I needed something that was quick I actually went through the work of benchmarking them all, and in the end I was left with XML::LibXML (based on gnome's libxml2).
If there was a "why" website somewhere I might aswell have put that information out there so that the next time someone was looking for a fast XML library they would know that XML::LibXML was a good module to look at.
One of the things that the EPO is doing (besides the Iron Man competition) is creating a Enlightened Perl distribution. One of the things this distribution is supposed to do is recommend the best of breed module across a specific set of categories. However the place we need help is generating the list of categories that need definition. The partial list is on the epo wiki, and includes XML. This project is based loosely on Task::Kensho on the CPAN.
We're always interested in more people helping out with the discussion.
JFDI FTW!
Also, TLA oversaturation in this reply!
I try (but sometimes fail) to write code that can be maintained by entry level Perl programmers. Often it means using very nice modules from CPAN that the maintainers will never need to look at, but using non-OOP code for the body (which is mercifully short). Even regular expressions are kept to a minimum and as simple as possible, and thoroughly documented. But every now and then something slips out. It's an 800 line script that's hellishly efficient, and without a single function defined. A few calls to get data from the database (but all dynamic queries - even the table names are from the database) then a 9 way nested loop with a corresponding 9 dimensional hash. It's squeaky clean - meaning if even a single character is changed anywhere that isn't a comment, it will break. And explaining it takes a couple hours, and even then, it's pretty clear that no one gets it. And the maintainers think they need to rewrite it in Java. Well, good luck on that one.
Do beginners start with the new stuff? Or should i continue writing in what probably works as is in Perl 4?
Stephen:
a few of us who have worked together here at catalyzed.org believe that you should get *something* working, review, and refactor. Sure, your initial code may come out relatively shitty, but as long as it does the function it's intended to perform, and isn't engaging in bad practice, one can refactor it into perfection (or near perfection). That way, things are learned, code reviews are to be had, and money is to be made with speedy development. Clients always like to hear you're improving things!