eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Formerly the priestly language of Webmasters incantations, Perl is being adopted across a broadening spectrum of tasks. Perl 6, a major re-engineering of the Perl technology, promises to preserve Perls legendary productivity in simple tasks while being built on a formal specification.
The result, its hoped, will prove more suitable for construction of complex and even mission-critical systems, while also appealing to a new generation of developers who have been raised on a diet of object-based languages running in multithreaded environments.
The Perl 6 Web site at dev. perl.org/perl6 is forthright about the need for possibly disruptive change. “The internals of the version 5 interpreter are so tangled that they hinder maintenance, thwart some new feature efforts, and scare off potential internals hackers,” that sites lead statement concedes.
Perl 6 will recognize and execute Perl 5 code, but it will also open new doors to developers with features including strong typing of data, provisions for metadata and a substantial cleanup of the languages distinctive pattern-matching capabilities.
Without changing the basic nature and mission of the language, Perl development leader Larry Wall nonetheless warned the Perl community at the end of 2004 in a communiqué on the topic of patterns that “the Perl 6 approach is to break everything that needs breaking all at once.”
With development releases of Perl 6 expected to emerge this year, and perhaps a production release by around this time next year, its appropriate for developers to start familiarizing themselves with the benefits and the costs of Perl 6 adoption.
There wont be a cold cutover to the new ways: Perl 5 wont be going away any time soon. Perl 5.8 continues to be the main branch in active use, supported by a still-flowing stream of resources such as the mid-2005 fourth edition of OReilly Medias “Learning Perl” from authors Randal Schwartz, Tom Phoenix and Brian Foy.
Summarizing Perls strengths, those authors assert that the language is “easy, nearly unlimited, mostly fast, and kind of ugly.” All those attributes, they emphasize, come with qualifications. Ease of use, they particularly warn, has gotten far more weight in Perls design than ease of learning—in the same way that colloquial English, with its idioms and contractions, is far more concise but takes much more time to learn than the formal language taught to nonnative speakers.
Damian Conway, principal of the Australia-based training consultancy Thoughtstream and an associate professor at Monash University in Melbourne, is an active member of the Perl 6 effort. The changing user base of Perl, he told eWEEK Labs in an e-mail exchange late last month, is an important driver in its development.
“Perl seems to have originally been aimed at sysadmins, toolsmiths, system programmers, and DBAs,” he said. “That heritage is still evident in its large variety of built-in commands: Not many other languages have primitives for controlling sockets, database access, signals or networking.”
User communities, Conway continued, are found in such diverse disciplines as document management, chip design, bioinformatics, finance, genealogy and application prototyping. “Weve had to adjust our ideas,” he said, about the appropriate demarcation between core features and other capabilities.
In addition to its reliance on idioms and implicit default behaviors, Perl can be intimidating to developers used to other languages that dont have as many different ways of doing any given task.
“Perls overriding viewpoint is that a language should be flexible enough to allow you to write code the way you [or your team] prefer,” said Conway, with forms that range from readily understandable to densely concise.
That flexibility is all to the good when Perl is used for ephemeral utility tasks, but it requires team discipline on larger and longer-lived efforts. “There are at least two dozen ways to write a case statement in Perl,” said Conway, “but it would be confusing and unmaintainable to use more than one of them in a given piece of code.”
Making Perl more useful in the future without making it any less useful to those who have made it popular today is a community process thats hard to summarize—but that promises to soon bring forth usable new options for developers.