This was a keynote given at the first DC-Baltimore Perl workshop. The topic was "Future Perl" and it laid out a number of features I would like to see come about in Perl (some of which actually have).
encourage the growth of Perl culture rather than the Perl core. – Larry Wall Larry said this about Perl 5, sometimes around when he originally released it. The CPAN, and the community that created, is the embodiment of that idea. Recently (the former) Pumpking, Jesse Vincent, proposed that we actually take this idea one step further. He proposed that we actually start removing things from the Perl core and putting them into modules. While this might seem insane at first, there are a number of changes which have happened in the Perl core that actually make this idea quite sane.
6 to be the community's rewrite of Perl and of the community. – Larry Wall But Pugs did more then contribute code, here is a quote from larry when the Perl 6 project really got started. Pugs really got more people involved, it was a good thing.
captures state variables say() mro pragma UNIVERSAL::DOES given/when smartmatch But also some which were not so successful. Taken from Perl 6 the given/when construct and smart matching was implemented, but the results were problematic. But then in 2009 ...
be Pumpking. Traditionally pumpkings were the developer/ releasemanager/etc/etc/etc, Jesse tried a different approach, being basically the project manager.
ARRAYs Y2038 compliance delete local $hash{$entry} package NAME VERSION; overloading qr// Pluggable keywords when as statement modifier Perl 5.12 is released But it wasnt just about features, Jesse also instituted a regular release schedule so that ...
ARRAYs Y2038 compliance delete local $hash{$entry} package NAME VERSION; overloading qr// Pluggable keywords when as statement modifier Perl 5.14 is released ARRAY and HASH built-ins on refs ${^GLOBAL_PHASE} package NAME VERSION {} Lots of internals work! Perl 5.12 is released in 2011 Perl 5.14 was released,
Perl was actually a talk he gave last summer in which he laid out the future direction. See, ever since 2000 no one had really done this, Perl 5 was old, Perl 6 was new, that was the direction. But 11 years later, no Perl 6, so Perl 5 needed to be resuccitated.
CORE::* references new OOP docs Devel::CallParser smartmatch.pm p5-MOP List::Gather ... Additionally in the last few years some work outside the core has been going on. This is in keeping with Jesse’s idea that the core should be slimmer and we should put stuff into modules.
Future Perl, so lets take a trip. Disclaimer: nothing from here on out is sanctioned. When I floated some of this to RJBS, he said “sounds good, just get someone to implement them” :)
SomeException->throw; } catch { when ( $_->isa(‘SomeException’) ) { warn “Got Some Exception: “ . $_->message; } default { die $_; } } Okay, so just a year ahead. Wouldn’t it be nice to have proper exceptions? This code is actually already possible using Try::Tiny and one of the many exception modules, but wouldn’t it be nice to have some level of standardization. Now I know this is Perl, so TIMTOWTDI, but that has a bad side too. Error handling is a mess in Perl, lets fix it.
$num ) { return 0 if $num == 1; return 1 if $num == 2; return fib( $num - 1 ) + fib( $num - 2 ); } fun ok ( $test, $message=’...’ ) { $test ? “ok $message” : “not ok $message” } fun log ( $level, ?$message ) { $message ? print( “[$level] : $message” ) : print( “[$level]” ); } What about function parameters? They don’t have to be fancy, they shouldn’t introduce types, there is (for now) no need for them to be introspectable either. Just simple parameters, that can be required, have a default, and be optional. I ran this by Jesse Luehrs and he said that doing this with Devel::CallParser “might actually just work”
sub bar { baz() } my sub baz { ... } } Foo::baz() # BOOM! And what about privacy. I know, again, this is perl, stay out cause I asked you, not cause I have a shotgun. But have you meet some of the people in the perl community (present company included).
has $x = 0; has $y = 0; method clear { ($x, $y) = (0, 0) } } class Point3D (extends => Point) { has $z = 0; method clear { super(); $z = 0; } } So, just 2 years ahead now. This is actually my proposal, to add a new MOP based object system to perl. If you want to know more about this, come see me after the talk. And if you want to contribute, definitely come see me.
($foo{bar}{baz}[2]->@) { ... } while ( my ($k, $v) = each $foo{bar}{baz}->% ) { .... } Now, this is something RJBS talked to me about and at first I was like WTF. Then I really gave it some thought and I was like “Hmmm”. This is the idea of a post-fix dereference operator, pretty fancy actually!
== any( 1, 2, 3 ) ) { ... } if ( $value eq none( ‘y’, ‘n’ ) ) { ... } if ( all( $foo, $bar ) >= 10 ) { ... } if ( one( 0 .. 10 ) == $baz ) { ... } So one of the features in Perl 6 that I really feel in love with was junctions. There are a couple of good CPAN modules out there, but really this should be something simpler, just a plain pragma. Also, it really should be in C so that it can be fast.
$acc, @list ) { match ( @list ) { case ($head, @tail) { reduce( $head + $acc, @tail ) } case ($head, ()) { $head + $acc } } } How many of you have written OCaml? Haskell? Pattern matching is great, and with destructuring bind, it is even more awesome.
$acc, $head ) { $head + $acc } fun reduce ( $acc, $head, @tail ) { reduce( $head + $acc, @tail ) } It also can be desugared into a style of multi-methods (see also Standard ML)
$connection, $message ) { match ( @$message ) { case ( 'start', $name, @args ) { $connection->get($name)->start( @args ); } case ( 'stop', $name ) { $connection->get($name)->stop; } case ( 'error', $message ) { $connection->all->stop; warn $message; exit; } } } and it is not just for recursive esoteria, it can be very useful, think of it as a more awesome- er switch.
my_app.pl % perl -MO=JVM foo.pl % gcc -Wall bar.pl -o bar Part of what drives trendiness in programming languages is actually the level of CS sexy, and the idea that they can be pushed forward in new and exicting ways. Of course, this leads to disasters too, but until now (the future) it hasn't even really been possible, but thanks now to the reduced core, .... I have faith that Perl as a language can survive 13 years, it is flexible and has proven to be useful in many contexts. But where it needs to innovate is the compiler infrastructure. IronPython and JRuby are out there, they might not be the best or fastest, but they are platforms for innovation. Languages are consolidating around central VMs and cross language integration and Perl is behind on this.