Free Newsletter GlossaryContact UsAbout Us
Coding & ScriptingDesign & ProcessToolsBusiness & Careers

Perl Makeover

Perl Gets An Extreme Makeover

After 17 years, Larry Wall's creation is about to get a major facelift. The verdict: Perl 6 isn't perfect, but it's clearly a big step forward for one of the world's most popular and important programming languages


Perl has long excelled as a productivity tool for text processing and, with the advent of object support in Perl 5, as an application development tool. However, for just as long developers have derided Perl for its syntactical rules; it has been a source of wonder and consternation among programmers.

In any case, the fact is that Perl is getting rather long in the tooth. In the summer of 2000, when the Perl community decided to go back to the drawing board, as opposed to merely pursuing incremental improvements to Perl's "State of the Onion," they embarked on an ambitious journey. Although that journey isn't over yet by any means (it's still unclear exactly when Perl 6 will be ready for prime time), it's obvious that some big changes are in store.

Perl Gets A Parrot

The biggest change ahead is the separation of the syntax that gets parsed and compiled ("Perl 6") from the virtual machine that runs it ("Parrot"). Let's start with Parrot. What began as an April Fools joke a few years ago is now the name for the underlying virtual machine (VM). In this model, Perl is parsed down to an abstract syntax tree and compiled into the Parrot assembly language bytecode. Parrot then interprets the bytecode, optimizes the code and executes the program.

While all of this infrastructure is intended to support Perl 6, the intent behind Parrot is to keep it agnostic about a high-level language's constructs. As a result, plans are in the works for Parrot to interpret and transform other bytecode formats, such as the .NET Common Language Runtime (CLR) and the Java virtual machines (JVMs). The big win with Parrot is that it was designed to support unicode and threading from its inception--not just as an awkward afterthought. Eventually, Perl, Python and other languages may all share the Parrot VM as a common runtime engine.

Better, Faster, Stronger

Another one of the major goals of the Perl 6 project is to enhance rapid development support. Towards that end, Perl 6 promises a number of improvements:

  • Improved object support

  • A switch statement (no more cascading elsif's)

  • Conjunction/disjunction expressions (think School House Rock)

  • Method and subroutine signatures (no more rummaging around @_ for parameters)

  • Genuine exception handling (no more goofing around with the evils of eval)

  • Aspect oriented programming support (with currying)

  • Attribute Oriented Programming ("the other AOP")

    All of these sound like very useful features, and some of the grammar changes are downright neat. For instance, declaring type constraints is cool, but declaring composite data structures in Perl 6 almost reads like a Celtic poem:

    my %hash is Hash of Array of Hash of Array of Int;

    OK, maybe I'm out on a limb there. Anyway, the variable type declaration features of Perl 6 should assist program debugging. By imposing data type constraints, programmers can (hopefully) identify errors at compile time that might have otherwise turned into runtime mystery bugs.

    Working With Weirdness

    That's enough of the good news. On the other hand, some of the changes to the Perl language lead to one conculsion: No matter how much Perl changes, the sum total of the language's complexity, nuance and weirdness stays constant. For instance, I was pleased to hear that Perl 6 will remove the built-in function format.. But when I read of a new built-in function (zip) for interleaving two arrays, my Bad Idea Alarm went off. In addition, silly things like negative condition operators will also continue to clutter the language unnecessarily.

    Other changes in the Perl 6 spec, with its descriptions of "slurpy arrays" and "splatty parameters," might make you wonder sometimes whether the folks steering the Perl ship are more mad scientists than language designers. Perl 6's string concatenation syntax uses tildes (instead of Perl 5's dots) --is that an improvement? The ternary operator in Perl 6 has doubled up on the question marks and colons, and the language introduces some funny new operators for smart matches and pipelines. Reading the specs, you may find yourself nodding "good move" in one instant but wincing a moment later and wondering, "what kind of syntax is that?" Nonetheless, despite its peculiarities, Perl 6 clearly delivers more than it takes away.

    On Mondays, Wednesdays and Fridays I love Perl 5. The sheer simplicity with which it expresses complexity is truly sublime. On Tuesdays and Thursdays, however, I hate Perl. The function bloat is silly and not only is there more than one way to do it, there might be more than a dozen syntax variations for each way. I suspect with Perl 6, I'll only hate it on Tuesdays; Thursdays will succumb to the love.

    Ian Kallen is an application and software systems architect, consultant, and author. He lives in the San Francisco Bay Area.


    TERMINOLOGY EXPLAINED

    Virtual Machine (VM ):
    A VM is an interpreter: software that converts intermediate language (bytecode) into machine language and then executes it. The best known example is the Java Virtual Machine (JVM): A Java developer takes plain-text code, runs it through a compiler, and the JVM then executes the code. This is the basis for Java's "write once, run anywhere" foundation: JVMs created for a wide range of operating systems can all execute the same compiled Java code.

    As the JVM has matured over the years, developers have also implemented compliers that compile Lisp, BASIC, Smalltalk, and other non-Java code to JVM bytecode. Perhaps the most widely used of these non-Java JVM languages is "Jython": a variant of the Python scripting language that runs on a JVM.

    Similarly, as we note above, the Parrot VM will work with both Perl 6 and Perl 5, and it will probably also work with other dynamic bytecode compiled languages such as Python, Ruby and Tcl. (As an interesting aside, the Perl 6 compiler may eventually be able to product bytecode suitable for the JVM and for the .NET Common Language Runtime, although they will not work as efficiently with Perl 6 bytecode as they will with Parrot.)

    Common Language Runtime (CLR):
    The CLR is Microsoft's runtime environment that compiles and executes Microsoft Intermediate Language (MSIL) bytecode. It is a major component of Microsoft's .NET Framework for developing Web services and component software.

    The CLR is similar in function to the JVM: Both are runtime environments that provide a fundamental set of services that all programs use. And just as compilers exist that can now produce Java bytecode from a number of programming languages, MSIL bytecode can be created from any .NET programming language, such as VB.NET and C#.

    Aspect Oriented Programming (AOP):
    Aspect Oriented Programming enables objects to acquire new capabilities as aspects. Triggering different kinds of events (e.g. logging, sending signals) or handling different parts of the data handling life-cycle (e.g. marshalling, persistence) have all been cited as potential capabilities that might be inserted at a pointcut. Most AOP implementations are in Java (including Aspect-J, JBoss AOP, Nanning and Aspectwerkz) but the currying and method wrapping facilities included in Perl 6's should allow it to implement AOP as well.

    Attribute Oriented Programming (the other AOP):
    Attribute Oriented Programming is characteristic of Java tools such as xdoclet that allow the programmer to tag methods for compile time processing (e.g. generate deployment descriptors, derived classes). This is currently capability of .NET attributes (e.g. a method can be tagged as a "web service" and the framework handles the mechanics of the details) and is in the J2SE 1.5 beta's metadata (JSR 175) support.

  • PERL RELATED RESOURCES

    Over the past three years, Larry Wall's Apocalypses have defined the technical foundations of Perl 6.

    At the same time, Damian Conway's Exegeses provide practical interpretations and explanations of Wall's "Apocalyptic" writings. Together, the two collections are essential reading for developers interested in a detailed look at how—and why—Perl 6 is evolving.

    The Perl 6 RFC is the Perl community's "wish list" upon which Larry Wall based many of the new features in Perl 6.


    More Perl related links appear below the ad.



    OTHER PERL RESOURCES

    Perl 6 Modules --Comprehensive Perl Archive Network (CPAN)

    Editorial and vendor perspectives








    DEVELOPER PIPELINE MARKETPLACE (sponsored links)