Slashdot Mirror
Larry Wall Announces Perl 6
The following was written by Chris "Pudge" Nandor... Perl Guru, Slashcode Guru, and all around swell guy.
Perl 6 To Be Complete Rewrite (But Not What You Think)Larry Wall and other active Perl porters and Perl helpers met on Tuesday afternoon at Perl Conference 4.0 and mapped out a what is planned to become a complete rewrite of Perl that will become Perl 6 in 18 to 24 months, with a prerelease targeted for next year's conference.
Perl 5 will not be abandoned, but will primarily be concerned with bugfixes both major and minor.
The meeting for members of the perl5-porters mailing list was the result of an earlier, smaller meeting of Wall, Nathan Torkington, Chip Salzenberg, and others who basically decided that Perl needed to be fixed in certain ways, and that a rewrite was the best way to do it. Salzenberg started the Topaz project two years ago, to reimplement Perl in C++. Though Topaz itself will not be the basis for Perl 6, Salzenberg noted that the lessons learned in the experience will be very helpful to the new effort.
Torkington led the three-hour meeting, starting off by saying what was wrong with Perl. Much of the focus on the problems with Perl centered around how increasingly difficult it was to improve, extend, and embed Perl. A rewrite and redesign are needed, he said, and maybe it is time for a hard change. So while the focus of the effort seems to be on improving the Perl guts and API, the project will also be used as an opportunity to clean out some of the cruft, including bad and seldom-used features.
Some of the primary (and still vague) goals of the effort will be to reimplement the core so it is better, stronger, and faster; improve syntax; add new features where appropriate; have better version and installation management for perl and its modules; and have a clear and automated migration path, which may include a backward compatibility mode. Some old features may be removed, like typeglobs. Others will be improved.
The group hopes to re-shape Perl community, too. Instead of one all-encompassing perl5-porters list, tightly focused mailing lists with a terminal lifespan will be formed. To start off, the mailing list bootstrap at perl.org will be for discussion of the beginnings of the project. Like most, if not all, other new lists, when it has fulfilled its purpose, it will be closed.
Wall said, "Perl 5 was my rewrite of perl ... I think this should be the community's rewrite of perl, and the community's rewrite of the community."
Specifics have not yet been ironed out. A group has been formed to begin the work, which will primarily consist of planning the work to be done. No coding is to be done at this stage, only planning and support. Roles were determined for the group, and then they were filled. They now include the perl 5 maintainer (Jarkko Hietaniemi and Nick Ing-Simmons), the language design pumpking (Larry Wall), the internals design pumpking (Dan Sugalski), the documentation manager (Adam Turoff), the system administrator (Ask Bjoern Hansen), the quality assurance bloke (Michael Schwern), the spokesdroid (brian d foy), the customer relations person (Dick Hardt), and the project manager himself, Nathan Torkington. Other porters, such as Chip Salzenberg, volunteered to consult when needed.
Some of the short term goals of this group are to draft a language specification, start an RFC channel, get feedback, and set up mailing lists, a documentation repository, and a web site. Hansen will be setting up the mailing lists. The bootstrap list will be open to the public, while the list for the intial small group of people will be closed for posting by anyone not on the list. All lists will be readable by the public, through the web, and perhaps through email. Turoff is going to be preparing the notes for the morning meeting, and foy will be posting the notes and the mailing list links on the www.perl.org web site.
In keeping with the spirit of Perl, heavy use will be made of default variables in this new system. So for example, the commonly used "print" command will be replaced by:
And the almost-as-common "if" will become:
Instead of "foreach" it will be possible to use:
And lastly, any reference to "$_" or "($_)" can be replaced by:
So a typical Perl 6 program segment might look like this.
#!/usr/bin/perl
;
(@_){
{
}
}
Larry has expressed his gratitude to the Python developers for their initial work in this area.
I really think that one of the reasons that the Perl modules are SO useful is due to the lack of strong typing ala Java.
A PERFECT example of this is the DBI library. In Perl, it's simple. You can even do
($id, $firstname, $lastname) = $sth->fetch_row();
In Java, with the JDBC, you have to do this:
(assuming rs is a ResultSet object)
int id = rs.getInteger(1);
String firstname = rs.getString(2);
String lastname = rs.getString(3);
(forgive the syntax if it isn't 100% correct; you should be able to understand the point though.)
The point? Because of Perl's lack of strong typing, it's a hell of a lot simpler to get what I need done: extract a userid, first and last name from a database.
Lots of other modules are like this as well. The result? A looseky bound language that makes it really simple to put different modules together to get something done. In my years of experience in using C++, this is pretty difficult to do: everyone does the data storage differently, leading to a variety of problems. This is still true in Java, but to a much lesser degree.
This is why Perl will never be burdened with strong typing.
Enjoy!