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.
C was based on B, which was designed almost entirely by a single person. K&R literally wrote the book on the pre-ANSI C language. C89 codified most of original C. C99 represents only minor changes to the specification of the language (restrict, long longs, and implicit casts to UDTs in actual parameters being the more important changes). C++ was designed by Stroustroup, but unfortunately the committee made some elephantine changes to the language. STL and namespaces is about the only good things, IMHO, that came out of standardization. The latest ISO C++ standard has certain flaws (limits on access of friends, among other things) that I think severely degrade the usefulness of the language.
You don't actually need an explicit return:
:)
sub foo { "bar" }
This is actually how "use constant" works internally: it fakes up a subroutine that (implicitly) returns the requested value.
Since the subroutine is defined at compile time, and the compiler sees that it returns a constant value, the constant value is inlined in place of the subroutine call.
So, constants work and are exactly as fast as you'd expect, even though it may seem odd to people without backgrounds in functional languages that a constant is really a special case of a function, but with a built-in performance hack.
PHP isn't really a competitor to Perl in the CGI space. PHP is embeded in an HTML page, whereas a Perl CGI is more likely to be in the backend, or at most generating HTML. There are HTML::Embperl, ePerl, and maybe other embeded perl options, but probably the way most people use Perl is not comparable to PHP.
The " Doneness" listing indicates that virtually all of the commands are done, and the last date that something was updated was in June 1999.
It may well be effectively complete. I don't think PPT has taken the world by storm, though...
If you're not part of the solution, you're part of the precipitate.
Hey, I like my C++ short and terse too, but I don't care for entire subroutines mostly written in punctuation.
This is a myth. You can right perfectly readable and maintainable perl. I currently prototype web pages in perl using cgi.pm and hand it off to an asp developer who translates it into VBscript asp's and cleans up the user interface. The guy had close to zero perl experience when he started, but was able to read an understand my perl almost immediately.
You can write unreadable perl, and that's a godsend for 1 shot scripts, but you can also write very readable perl. It's a language of acceptable subsets.
--Shoeboy
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.
Also, strong typing can be more efficient. When you say getInteger(), the compiler doesn't have to waste cycles trying to figure out if it's an integer, string, float, etc.
BTW, C++ allows you to emulate weak typing where it's appropriate, using operator overloading. Say I've created a SpecialInt class that contains an int, plus does some other special stuff I need for some reason, I can make it interchangeable with an int, like this:
Change is scary. But it sounds like this change will be pretty transparent to programmers; perl will continue to get faster and better, still stay easy to use, and Larry Wall is still a little crazy. Well, it sounds like everything is right in the world.
The above is also found in it's original form at use.perl.org. use.perl.org is a great site, and also based on Slash (the slashdot.org engine).
First of all, here's a list of things i don't like (just so you know i'm being fair):
1) The lack of constants: The only way to do constants is to create a subroutine that returns whatever value you want to be constant, ie: sub foo{ return "bar";}
--BlueLines "The cost of living hasn't affected it's popularity." -anonymous
Here's a regexp I saw in some perl yesterday:
:)
s#<(?!$okay_tags)([^>]*>)##gi;
Think it's unreadable? What about this sentence:
"Cette phrase en francais est difficile a traduire en anglais." (From Douglas Hofstader's "Metamagical Themas")
The point is, it's impossible to read anything until you know the language. I know that the above perl reads "zap all html tags not in the list of ok tags. " (Of course, I have the benefit of knowing what the context for the line was).
So, yeah - perl is ugly unless you know it.... just like any other language. Also, I think C++ uses all the punctiation that perl does, just not as often
-Dave Turner.
Become a FSF associate member before the low #s are used
If you put export PERL5OPT='-Mstrict' in your profile, then it will already happen.
-- Abigail
-- Abigail
I'm at the perl conference right now (using their wireless connectivity which is pretty cool), and I saw Larry Wall's keynote speech. He said "I hope we have 100% compatability with all Perl 5 scripts, but I don't think that will happen [with Perl 6]. If we have 100% compatability with 80% of the scripts out there, that's good in my opinion. If we have 95% compatability with 100% of the scripts, that's good. As long as we're in the ballpark, it's ok. You have to break a few...umm..somethings to make an omlette."
.anonymous coward.
Enjoy!
Yes, there is. Most of the core Perl developers call "5.005" "5.5".
As another aside, I'd say this is a Good Thing (tm) for those of us that have to admin PC's running Linux, Solaris, Win2K, WinNT, and Win98, Sun boxen, and Mac's all in the same campus. That's the advantage of Perl. And thanks to M$ for finally supporting something that someone else wrote without trying to take it over. They should get credit where credit is due.
Depends on what you mean here. I use PHP scripts to present information drawn from my mysql database as webpages definitely. But I also use it to publish static html pages, create text files, ftp files from one server to another, verify data values in my database etc - all tasks that could have been done in Perl (and perhaps more effectively) but which I have done using PHP simply because I am more familiar with it than I am with Perl. In this sense, it is a competitor with Perl, in the sense that most sysadmins will not be writing their maintenance scripts in PHP, no it is probably not in competition with Perl.
Overall I find PHP scripts are easier to decipher when you return to them 6 months later to make a change, I think it has a simpler syntax and some very logical improvements over some aspects of Perl, and for these reasons I prefer it. Mind you there are some older scripts written in Perl that I still occasionally have to tweak, but most of these have been replaced by PHP scripts whenever the need arose.
"The first time I got drunk, I got married. The second time I bought a chimpanzee, after that I stayed sober" Arian Seid
Will perl 5 source be 100% ok with perl6 or will i have to rewrite code?
The impression I get from the article is "mostly compatible":
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.
You'll probably be ok, but no promises, assuming they don't change their minds during the next year or so (remember, they're just _entering_ the planning stage now).
He announced his vision for Perl 6. Please try to keep the headlines from being completely misleading....
Another reason Perl holds the web together is that even though its benchmarks suck for number-crunching, it out-performs both Java and C (Yes, C, and I found that unusual) when it comes to parsing text. In fact, if I remember the "Benchmark" story on Slashdot from a couple months ago, Perl was six times faster than Java for text-based stuff.
And since the web's content is so heavily text-based (because plain text is a universal standard, HTML is text-based, and because most pages' content is text), it's easy to see why PERL dominates.
Different tools for different jobs. If you want to write a first-person shooter or operating system, use C. If you want to write a script that converts newlines in text files between \r\n and \n, PERL would probably be the best choice. If you want to write an ASCII game, I'd go with QuickBasic 5.
In conclusion, PERL rules, and if this upgrade is good, that's cool, and if it isn't, no one is going to force us to upgrade our interpreters.
"Beware he who would deny you access to information, for in his heart he deems himself your master."
This should be interesting to watch develop. Since this one is going to be design by open source, I wonder if they'll ever be able to release an upgrade.
It seems that the past has shown that language by committee ends up over-burdoning the language. Are they're any previous examples of language design by committee that worked? It seems that all of the successes programming languages have made have been because of one or two evil geniuses who were able to see a project to completion, design to code.
I wonder if it's just revisionist history, but weren't c, c++, python, perl, and tcl all works of very small teams (excluding the standardization committees).
This should prove to be a great example for university programming language courses.
-js
I believe your example could be written much more clearly. This:
s|<(?!$okay_tags).*?>||gi;
should do the same thing, and is more readable. You can make any language obfuscated, especially when the language is flexible.
I mean, honestly, can you think of a faster way to "zap all html tags not in the list of ok tags"? It may be a little hard to read when you are done, but if you put a comment next to it saying what it does, it's not hard to understand.
Got HTML? Want LaTeX? Try html2latex
O'Reilly is funneling massive kick backs to Larry Wall in exchange for making millions of O'Reilly Perl books obsolete. This way they get to "totaly rewrite" the books and sell them to you again all over again. Think of the children!! ;) Or something.
This sig is false.
I have avoided learning Perl for a couple of reasons. One of them (not the most important reason, obviously) is that the syntax looks vaguely like a memory dump. You know that Dilbert joke where Dilbert instructs Ratbert to dance on the keyboard so that Dilbert will have more bugs to fix, but in doing so Ratbert creates a web browser instead? I think it was written in Perl.
I'm really hoping Perl 6 will give us some more readable syntax. Hey, I like my C++ short and terse too, but I don't care for entire subroutines mostly written in punctuation.
Yeah, I know that syntax is a lame reason to like or not like a language, but I'm the one who has to stare at it. It's the little things that make the difference.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)