Dual-license your content for inclusion in The Perl 5 Wiki using this HOWTO, or join us for a chat on irc.freenode.net#PerlNet.

Perl Myths

From PerlNet

Jump to: navigation, search

Contents

Introduction

There are a number of myths about Perl, usually used as reasons not to use or learn the language. Simon Cozens debunks some of these in his 10 Perl Myths and some others have been added below.

The Myths' List

Perl is Dead/Dying

With the surge of popularity for PHP, Python and Ruby as language competitors for Perl, some people are suggesting that use of Perl is dying off. Fortunately this doesn't seem to be the case. Instead, the differences in languages are allowing programmers who'd never have been comfortable with Perl find languages that suit them better.

Part of the reason for this myth is advertising. Perl does not have a single company behind it advertising its uses. Instead, people learn Perl because it is recommended by their peers, or they need to use it for existing applications. Many system administrators still find Perl an essential tool in their day-to-day jobs, and many programmers use Perl to write web, desktop and server applications as necessary.

Perl 5 has a very large code-base throughout businesses internationally. As such these businesses require Perl programmers to maintain and improve their programs. At least since 2005, demand for Perl programmers has outstripped supply. This is causing some businesses to look at moving away from Perl, while other businesses are focussing on re-training non-Perl programmers.

Perl's famous library repository, the Comprehensive Perl Archive Network has grown from approximately 5,000 modules in 2000 to 11,000 in 2007. Perl has a very strong community interacting through online forums such as Perlmonks, holding regular user group meetings throughout the world and hosting high quality conferences in many countries. Perl is not dying and is far from being dead.

Perl is not Object Oriented

Quoting from Damian Conway's book "Object Oriented Perl": "Perl was not originally designed - or implemented - as an object-oriented language. Its version of object orientation is simple and well integrated, but not fundamental to the language (as it is in Java or Eiffel or Python, for example).".

Perl's OO is very flexible. While you often need to be explicit about many things, it is generally possible to do what you want to do with it. In particular multiple (and diamond) inheritance, polymorphism, and re-dispatching all have superb solutions in Perl.

Unfortunately it's hard to address this myth adequately as a common definition of what exactly is, or is not, an object oriented (OO) language tends to be lacking. Each OO language differs from the others in so many different ways, just like there are many imperative, functional and declarative languages. Perl's OO implementation reflects those features of the OO paradigm that the implementers thought most appropriate.

The perl5 Code base is a Huge, Unmaintainable Mess

The code base of many large projects is huge and apparently unmaintainable to the outside observer. The Perl 5 code base is no exception with over 500,000 lines of code in bleadperl (according to SLOCCount by David A. Wheeler). Fortunately the code is fairly modular and reasonably amenable to changes once you do understand its design. The latest development release (which will be available as 5.10) introduces many new features from the Perl 6 language design without compromising backwards compatibility or requiring a full rewrite.

Also note that most of the perl 5 code is not directly the core perl 5 code: the code of the automated tests (over 100,000 assertions and growing), some user-land, high-level, modules written in Perl or C/XS, support code for the build-system (needed for portability), etc. The core perl 5 code which results in a 1,427,604 bytes-long libperl.so on an Linux machine running on a Pentium is much smaller.

Perl 5 just works for most purposes. Granted, no project this large will be bug-free, however Perl has a comprehensive test suite, extensive documentation, and works across more than 30 different operating systems. In addition, Perl is released under the Artistic (open source) license.

Perl is only Suitable for Small Programs - It does not Scale Well for Large Projects

There is nothing in Perl 5 that prevents it from being used for large projects -- just like there is nothing in C, or Java or most other languages which prevent them from being used for large projects. However as Perl has all of the usual tools used to compartmentalise projects, such as object oriented features, libraries, name spaces, testing suites and distribution tools; writing large projects in Perl is very easy. Any restrictions that exist are usually based on the experience and competence of the programmers involved.

Creating a medium project which can scale to a large project requires a deliberate effort with careful design and a decent test suite. On the other hand, many projects (in most languages) start off by being small and have features stuck on incrementally. This development model is typically called "the big ball of mud", and it is these projects which cannot scale well to large projects; regardless of the programming language.

Perl continues to be used to develop many significant applications and web sites. The extensive (and growing) contributions on CPAN are representive of the pervasiveness of Perl, with a strong infusion of modules that have their origins in commercial projects. For example, Amazon.com has a rapidly changing code base of 100 million lines of code, a large part of which is written in Perl and using the HTML::Mason web site authoring system. The CPAN includes contributions used to power popular sites/products such as The BBC, LiveJournal, SqueezeBox, and many others.

Perl may not be the most suitable tool for every task, but no language is. According to the Pragmatic Programmer you should learn as many languages as possible - at least one language per year - and not have prejudice against any language. Increasing your understanding of multiple languages will increase your ability to program effectively for big and small projects.

Perl Code is Ugly/Messy/Unreadable

It is very easy to write ugly and unreadable code in Perl. However, it is rarely much more difficult to write elegant and readable code instead. Unlike Python which has strong whitespace rules, Perl is very happy to completely ignore whitespace in most circumstances. Programmers who choose to abuse this to write messy code, tend to make the same mistake in other languages as well.

Damian Conway's book Perl Best Practices provides strong recommendations on code layout and presentation. Additionally, the Perl::Critic module can be used to give feedback on one's programming styles, while Perltidy can rewrite most Perl programs in a tidy fashion.

XML has Eliminated the Need for Perl's Text Processing Capabilities

As nice as XML is, there are plenty of non-XML-based formats out there and more are constantly created. So chances are you'll need to process non-XML text or non-XML binary formats, using a programming language that has good support for them. That's because XML is not always the most suitable meta-format for every task.

Furthermore, Perl has very good support for XML-mangling, and you can use its power to handle XML with ease, with a small codebase and with very few frustrations. And using CPAN you can have your XML management code interact with the rest of the world.

So Why is Perl Attacked So Much?

Well, Bjarne Stroustrup (who is best known as the creator of the [[C++]] programming language) has two relevant quotes about it:

  • "There are more useful systems developed in languages deemed awful than in languages praised for being beautiful--many more".
  • "There are only two kinds of languages: the ones people complain about and the ones nobody uses". (Attributed)

So all the criticism against Perl is proof that people have been using it, forced to use it, wanted to learn it, or were burned by it.

Of course there are other factors:

  1. Perl was not meant to be likable by anyone. Some elements of it may be very controversial.
  2. Perl does not go to great lengths to discourage bad practices. It does not prevent you from doing dumb things because that would prevent you from doing smart things. (By analogy to what was said about Unix).
  3. Perl is particularly optimised for writing small programs, as this is most of the work for which its programmers are using it.
  4. Perl has a syntax full of special characters. This was a design decision, which yields several important benefits, but many people naturally dislike it.
  5. Perl has too many "default" behaviours - unless you are an expert in the complete syntax, it is difficult to read code which has implicit values/actions but are not shown on paper. The designers have gone overboard with adding defaults, presumably to save typing time but at the abovementioned expense.