Jesse Vincent is taking a hard look at where Perl 5 is headed. Vincent, who’s at the forefront of maintaining Perl 5 these days, says that the Perl Porters are doing “a stellar job” of getting Perl 5 “back into a reasonable groove.” But Vincent says there’s more to do and that Perl 5 will continue to evolve.
Vincent’s thoughts are put forward in a mail to the Perl5 Porters list, based on a presentation given at OSCON and other conferences this year.
Despite many assertions that “Perl is dead,” it’s very much alive – particularly Perl 5, which is and will be in widespread use for quite some time. It may not be getting as much attention as JavaScript, PHP, Ruby, Python, and whatever the language du jour is that Google wants to put out – but it’s not going anywhere.
Which means it needs to continue evolving. Vincent notes that Perl 5 was in a rut for quite some time, but in the past year things have changed. Perl has had five stable releases and a dozen development releases. Now Vincent says it’s time to think about evolving. “Perl’s internals, syntax and semantics have seen some much-needed improvements in the past few years. There are many additional changes we can’t make because they may damage too much legacy code.”
View more
from
Vincent’s principles for new versions of Perl are:
- New versions of Perl 5 should not break your existing software.
- Backward compatibility must not stop Perl from evolving.
Note the “should” and “must,” there. Vincent says that some Perl 5 features should be removed from Perl, including core features. The idea in some cases is to remove unwanted features from the Perl core and implement them as modules for Perl. That way if code has a “use v5.12” declaration, it might tell Perl to enable a module that has the same functionality as something in Perl 5.12 but removed from 5.16.
More Modules, Please
Vincent wants to see more done in modules, period. He says there are a number of language features that might make sense as modules, including functions for UNIX System V interprocess-communication (IPC), socket I/O functions, and a number of other *nix functions. This makes sense, given that not all Perl programs will be running on *nix type systems.
Ultimately, Vincent says that there should be two distributions of Perl provided by the Perl Porters – one that contains “roughly what we’ve always shipped,” and a “Perl the language” distribution that stops with the Perl language features and enough to bootstrap the installation of new modules from CPAN.
Vincent’s vision seems to be getting a good reception from the Perl5 Porters list. Perl has largely been on the back burner in many people’s minds for some time. I wonder if a new approach is enough to put it back in the spotlight?
