morungos

I'm thinking about Perl, and how people can possibly believe the community is anything less than vibrant. As some may know, I used to be a Common Lisp developer, and Common Lisp has a lot in common with Perl. I haven't done too much with Lisp for the past ten years, but when I did work in it (between 1985 and 2000, more or less) all the time there were questions over its survival. Sorry, everyone, Common Lisp is still here.

There is a reason why Perl has survived so well, and why it will continue to do so. The reason is subtle, and one of the less apparent aspects of Perl, and one that is sometimes criticized, its very malleable syntax.

Common Lisp has macros, and a relatively small core of 'special forms' which were all the compiler needed to know about. Virtually all the visible syntax of Lisp was macros, written to expand into these special forms. For this reason, very significant aspects of the language could be added without changing the core compiler in any way.

Initial versions of the Common Lisp Object System, or CLOS, were written in exactly this way. In the early days, objects were represented as fancy closures - not great performance, but a very good way of encouraging community participation with CLOS, and also of smoothing off any rough edges. Over time, this became more integrated. The Common Lisp exception system also went through a similar transition.

Now consider Perl. Perl has accommodated similar inclusions, and subtle changes in the parsing since Perl 5.8 have made this easier.

Let's face it, Perl's exception handling is on the clumsy side - but the CPAN module Try::Tiny managed to turn it into a much clearer code form, without requiring the core language system to be changed. In a language with a more conventional syntax system, control structures cannot generally be added without core system support. Try::Tiny looks like a control structure, but it's actually a function that does some sleight of hand with closures and functions - exactly how the prototypes of Common Lisp exception system retrofitted similar structures.

Object systems are similar. Perl's initially simple object system has blossomed into one of the smoothest and most flexible object systems (Moose) in any language in mainstream use. Moose also supports the "syntactic sugar" which makes it seem like these features were there from the beginning.

This characteristic means Perl can evolve in ways that are hard to predict. Like Lisp, Perl is a survivor, able to accommodate almost any idea adopted by other languages - and like Lisp, when Perl accommodates a new feature, it is very likely to improve on the original source. CLOS is almost unrecognizable as a descendant of Smalltalk, yet that was the source for many of its concepts. Perl's strategy of "there's more than one way to do it" demanded this syntactic flexibility, yet its by-product is language extensibility.

By contrast, most languages have very strict grammars. Java's grammar is especially well-defined, and in addition, by eliminating any form of preprocessing, it puts the entire burden of language change onto the compiler. PHP, Ruby, and Python all share this syntactic inflexibility, although to a lesser extent than Java. The problem is: this places the burden of language extension on core developers rather than module developers - and not just the burden, the control too. In effect, the direction the language takes will have to be driven by core developers rather than a wider community. Paradoxically, the language may be more likely to fork with a strict grammar, rather than less.

Perl didn't go as far as Lisp with its macro system (well, actually it did, with filters, but these are a very powerful tool, and best used very cautiously). But the principle of a malleable and accommodating syntax means Perl will continue to evolve, and to surprise as it does evolve. Perl is not only here, but it has a surprisingly bright future.