This will be a circus of profanity, filled with half truths, baseless rumors and bald face lies, any resemblance to reality is purely coincidental I rated that talk “R” for language because I didn’t want to hold myself back, which was fine for OPW, however at YAPC ...
This will be a circus of (mostly censored) profanity, filled with half truths, baseless rumors and bald face lies, any resemblance to reality is purely coincidental I am going to be a little more family friendly.
perl5-porters I spoke about p5p and how within it there exists a simultaneous fear of change combined with an intense love for bikeshedding. And that the combination of these two can lead to a culture of obstructionism.
perl5-porters I spoke about p5p and how within it there exists a simultaneous fear of change combined with an intense love for bikeshedding. And that the combination of these two can lead to a culture of obstructionism.
PURL, Y U NO HAZ REAL SUBROUTINE SIGNATURES?!WTF I spoke about our inability to move the language forward because our collective obsession with backward compatibility
CPAN I spoke about how CPAN is not the only game in town anymore, other languages like Ruby, Python, Javascript, C#, Java, etc. are quickly catching up both in module counts as well as with sophisticated tooling support. Don’t get me wrong here, CPAN still has the best toolchain, but it is only a matter of time before they copy us, learn from our mistakes and move beyond us.
I Perl but I want to assure you, I said all this because I really love Perl and I want Perl to move forward and prosper like the awesome language I know it is.
My Perl Wishlist • A more consistent syntax and sane grammar • with a real AST • and better tooling support • A less insane runtime • proper MOP (everything is an object) • slimmer core • easy (non-XS) extension mechanism • On a modern VM platform • JVM / CLR / LLVM / V8 • cross language sharing I basically wanted to be able to have all the cool features I had experienced in other languages, but i wanted them with a Perlish twist. NOTE: yes, this is kind of a subset of what Perl 6 is promising, the difference is was that I want to do it with Perl 5.
My reasoning at the time was because I saw Perl 6 as a space age language sent from the future, which meant that it was something that cannot and should not be rushed (if for no other reason then we can continue to mine it for awesome ideas).
My reasoning at the time was because I saw Perl 6 as a space age language sent from the future, which meant that it was something that cannot and should not be rushed (if for no other reason then we can continue to mine it for awesome ideas).
Perl 5?!?! People still use that?!? My reasoning at the time was because I saw Perl 6 as a space age language sent from the future, which meant that it was something that cannot and should not be rushed (if for no other reason then we can continue to mine it for awesome ideas).
Perl sucks So, anyway that was the past, lets get on with *this* talk. So first, why “Detroit”. Well, because Detroit *was* once the center of a lot of crazy productivity (like Perl), but many of Detroit’s biggest companies have since moved away (kinda like Perl), and Detroit has since begun to rot from the inside (a lot like Perl), because it is easy to make Detroit the but of jokes (also a lot like Perl). ... also lastly, because there are actually people out there that are working hard trying to fix up Detroit, but no one knows or cares (a really, really lot like Perl)!
2 So you can think of this as the part 2 to that original talk. I am going to talk about what happened after I gave that talk and some of the insights it brought. I also recently realized that I wrote that last talk from the point of view of a programmer (in that my solution to the problem was basically just “more programming”), but the fact is ...
I don’t do much programming anymore, I have become more of a manager now. This is a picture of me drinking my lunch. So wearing my manager hat, I actually tried to approach my Moe project in that way at the start. I eventually abandoned it, ... because, well, I got nothing done and just talked all the time. But that said, I actually want to talk a bit about what I discovered in that first phase, because I think it uncovered some important problems in our community that we need to discuss.
So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . Get rid of AUTOLOAD So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . Get rid of AUTOLOAD Include a MOP So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls XS must die! So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls XS must die! Add subroutine signatures So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls XS must die! Add subroutine signatures Deprecate formats So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls XS must die! Add subroutine signatures Deprecate formats Remove UNIX functions So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls XS must die! Add subroutine signatures Deprecate formats Remove UNIX functions Real exceptions!!! So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls XS must die! Add subroutine signatures Deprecate formats Remove UNIX functions Real exceptions!!! Remove tie/untie So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls XS must die! Add subroutine signatures Deprecate formats Remove UNIX functions Real exceptions!!! Remove tie/untie Fix smartmatching So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls XS must die! Add subroutine signatures Deprecate formats Remove UNIX functions Real exceptions!!! Remove tie/untie Fix smartmatching Remove contexts & wantarray So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls XS must die! Add subroutine signatures Deprecate formats Remove UNIX functions Real exceptions!!! Remove tie/untie Fix smartmatching Remove contexts & wantarray UTF-8 by default, everywhere!!! So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls XS must die! Add subroutine signatures Deprecate formats Remove UNIX functions Real exceptions!!! Remove tie/untie Fix smartmatching Remove contexts & wantarray UTF-8 by default, everywhere!!! Multiline comments!! So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls XS must die! Add subroutine signatures Deprecate formats Remove UNIX functions Real exceptions!!! Remove tie/untie Fix smartmatching Remove contexts & wantarray UTF-8 by default, everywhere!!! Multiline comments!! Real Threads! So one of the first things that happened after I announced Moe was that the community started to throw in their two cents. appear>. It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.
${some}% but by far the most common request that I got about Moe was that I should support some percentage of CPAN. Perhaps just the Pure Perl parts people speculated, perhaps some arbitrary percentage (80, 90, whatever). So I took this as a challenge and started to look into that what would entail ...
Perl 5 Core turns out that many of the things I noticed about the core and it’s fetish with backwards compatibility at all costs, well they weren’t isolated to just the core of Perl.
CPAN All the same issues (to one degree or another) applied to the CPAN, just multiplied by 27_000 (of whatever the current module count on CPAN is). If you look at that list of features people want to remove from Perl, then pick a module at random, it will most likely use/abuse one of those features, and if by chance it does not, then it will include a module somewhere in it’s dependency chain that uses/abuses one of those features. (and if it doesn’t at all, then it cannot be that useful a module then).
We already know that any backwards incompatible changes in the core of Perl has the potential to break DarkPAN, the great unwashed mass of Perl code in the wild. This being a common reason why to not change things. But it turns out that it would also break a lot of CPAN as well. Basically, you can’t win!
DarkPAN We already know that any backwards incompatible changes in the core of Perl has the potential to break DarkPAN, the great unwashed mass of Perl code in the wild. This being a common reason why to not change things. But it turns out that it would also break a lot of CPAN as well. Basically, you can’t win!
CPAN DarkPAN We already know that any backwards incompatible changes in the core of Perl has the potential to break DarkPAN, the great unwashed mass of Perl code in the wild. This being a common reason why to not change things. But it turns out that it would also break a lot of CPAN as well. Basically, you can’t win!
Test::More Take for instance, Test::More, a module commonly acknowledged as being one of the key breaking points of CPAN. If someone releases a broken Test::More, they pretty much break the whole of the CPAN. According to MetaCPAN it has over 12,000 modules directly depending on it (which can’t possibly be right, but thats what is says). If you do some diving into the code you will find some of those ugly bits in there. And please keep in mind, I actually picked this module not just cause it is almost universally depended on, but because it is still being actively developed, meaning this is not old rotted code, but nice well tended code that just happens to be tied to a rotting language. But “wait” you say, Test::More isn’t that bad with it’s subroutine prototypes, non-strict refs and typeglob tomfoolery, ... “okay” I say ...
12,741 Test::More Take for instance, Test::More, a module commonly acknowledged as being one of the key breaking points of CPAN. If someone releases a broken Test::More, they pretty much break the whole of the CPAN. According to MetaCPAN it has over 12,000 modules directly depending on it (which can’t possibly be right, but thats what is says). If you do some diving into the code you will find some of those ugly bits in there. And please keep in mind, I actually picked this module not just cause it is almost universally depended on, but because it is still being actively developed, meaning this is not old rotted code, but nice well tended code that just happens to be tied to a rotting language. But “wait” you say, Test::More isn’t that bad with it’s subroutine prototypes, non-strict refs and typeglob tomfoolery, ... “okay” I say ...
ExtUtils::MakeMaker Lets talk about something much uglier, ExtUtils::MakeMaker, which again (according to MetaCPAN) 10,000+ modules depend on. I am pretty sure that it horribly off as well, but you get the idea. ExtUtils::MM actually bundles 13 other modules with itself, to avoid dependency loops (a hole in our tooling there). But it is *full* of a whole bunch of ugly, twisty and nasty Perl. And again this module too is maintained, it is not old and rotting.
10,305 ExtUtils::MakeMaker Lets talk about something much uglier, ExtUtils::MakeMaker, which again (according to MetaCPAN) 10,000+ modules depend on. I am pretty sure that it horribly off as well, but you get the idea. ExtUtils::MM actually bundles 13 other modules with itself, to avoid dependency loops (a hole in our tooling there). But it is *full* of a whole bunch of ugly, twisty and nasty Perl. And again this module too is maintained, it is not old and rotting.
Now, I don’t mean to be picking on Schwern, buuuuut since he is not here, I figured, ... why the heck not!! Just kidding, he has dedicated a TON of his time over the years to these two modules and should be praised for that effort alone. And the fact is that the degree of ugliness in these modules is not there because he is a bad programmer, on the contrary, it is there because he has to support weird older versions of Perl, and strange mostly deprecated environments and all sorts of horrors. Again backwards compatibility comes and bites us in the ass!
So, where does this leave us? Stuck between a rock (the Perl 5 core and a 25 year commitment to backwards compatibility) and a hard place (millions of lines of code on CPAN which depend upon that commitment). Both of which drive up the cost of adding new features
CORE So, where does this leave us? Stuck between a rock (the Perl 5 core and a 25 year commitment to backwards compatibility) and a hard place (millions of lines of code on CPAN which depend upon that commitment). Both of which drive up the cost of adding new features
CORE CPAN So, where does this leave us? Stuck between a rock (the Perl 5 core and a 25 year commitment to backwards compatibility) and a hard place (millions of lines of code on CPAN which depend upon that commitment). Both of which drive up the cost of adding new features
So what then is the cost of adding new features? And speaking of getting it wrong, what is the cost of removing our mistakes? So what then is the cost of maintaining 25 years of backwards compatibility? We have lost our credibility as a language because our commitment to backwards compatibility has meant our language is not evolving, at least not in any sizable way.
Cost of adding new features? So what then is the cost of adding new features? And speaking of getting it wrong, what is the cost of removing our mistakes? So what then is the cost of maintaining 25 years of backwards compatibility? We have lost our credibility as a language because our commitment to backwards compatibility has meant our language is not evolving, at least not in any sizable way.
Cost of adding new features? Possibly slowing down startup/execution times ... So what then is the cost of adding new features? And speaking of getting it wrong, what is the cost of removing our mistakes? So what then is the cost of maintaining 25 years of backwards compatibility? We have lost our credibility as a language because our commitment to backwards compatibility has meant our language is not evolving, at least not in any sizable way.
Cost of adding new features? Possibly slowing down startup/execution times ... Risking getting it wrong (again) ... So what then is the cost of adding new features? And speaking of getting it wrong, what is the cost of removing our mistakes? So what then is the cost of maintaining 25 years of backwards compatibility? We have lost our credibility as a language because our commitment to backwards compatibility has meant our language is not evolving, at least not in any sizable way.
Cost of adding new features? Possibly slowing down startup/execution times ... Risking getting it wrong (again) ... Cost of removing crappy old, broken or just poorly designed features? So what then is the cost of adding new features? And speaking of getting it wrong, what is the cost of removing our mistakes? So what then is the cost of maintaining 25 years of backwards compatibility? We have lost our credibility as a language because our commitment to backwards compatibility has meant our language is not evolving, at least not in any sizable way.
Cost of adding new features? Possibly slowing down startup/execution times ... Risking getting it wrong (again) ... Cost of removing crappy old, broken or just poorly designed features? Possibly alienating unrealistic users who probably don’t upgrade anyway ... So what then is the cost of adding new features? And speaking of getting it wrong, what is the cost of removing our mistakes? So what then is the cost of maintaining 25 years of backwards compatibility? We have lost our credibility as a language because our commitment to backwards compatibility has meant our language is not evolving, at least not in any sizable way.
Cost of adding new features? Possibly slowing down startup/execution times ... Risking getting it wrong (again) ... Cost of removing crappy old, broken or just poorly designed features? Possibly alienating unrealistic users who probably don’t upgrade anyway ... Breaking code that should never have used those features in the first place ... So what then is the cost of adding new features? And speaking of getting it wrong, what is the cost of removing our mistakes? So what then is the cost of maintaining 25 years of backwards compatibility? We have lost our credibility as a language because our commitment to backwards compatibility has meant our language is not evolving, at least not in any sizable way.
Cost of adding new features? Possibly slowing down startup/execution times ... Risking getting it wrong (again) ... Cost of removing crappy old, broken or just poorly designed features? Possibly alienating unrealistic users who probably don’t upgrade anyway ... Breaking code that should never have used those features in the first place ... Cost of maintaining backwards compatibility for over 25 years? So what then is the cost of adding new features? And speaking of getting it wrong, what is the cost of removing our mistakes? So what then is the cost of maintaining 25 years of backwards compatibility? We have lost our credibility as a language because our commitment to backwards compatibility has meant our language is not evolving, at least not in any sizable way.
Cost of adding new features? Possibly slowing down startup/execution times ... Risking getting it wrong (again) ... Cost of removing crappy old, broken or just poorly designed features? Possibly alienating unrealistic users who probably don’t upgrade anyway ... Breaking code that should never have used those features in the first place ... Cost of maintaining backwards compatibility for over 25 years? Priceless!!! So what then is the cost of adding new features? And speaking of getting it wrong, what is the cost of removing our mistakes? So what then is the cost of maintaining 25 years of backwards compatibility? We have lost our credibility as a language because our commitment to backwards compatibility has meant our language is not evolving, at least not in any sizable way.
Cost of adding new features? Possibly slowing down startup/execution times ... Risking getting it wrong (again) ... Cost of removing crappy old, broken or just poorly designed features? Possibly alienating unrealistic users who probably don’t upgrade anyway ... Breaking code that should never have used those features in the first place ... Cost of maintaining backwards compatibility for over 25 years? Priceless!!! Sorry, I meant ... complete loss of credibility as a modern language. So what then is the cost of adding new features? And speaking of getting it wrong, what is the cost of removing our mistakes? So what then is the cost of maintaining 25 years of backwards compatibility? We have lost our credibility as a language because our commitment to backwards compatibility has meant our language is not evolving, at least not in any sizable way.
You see, I believe that something happened in 2000, when Jon Orwant threw his cup, and when Chip Salzeberg abandoned Topaz and the development of Perl 6 began. It was at that point that Perl 5 stopped evolving, because we were waiting for Perl 6
But meanwhile Perl 6 has launched into the stars, it *is* a language of the future. Larry is the Dave Bowman of programming language design, he is going beyond the stars. But while he and the other sixers are out exploring time and space ...
... those of us still using Perl 5 have to listen to stupid FUD like “Perl is a write only language” and “Perl is unmaintainable line noise”. But that said, many of the remaining criticisms of Perl are valid, we stopped evolving. Our lack of a proper OO system, no subroutine signatures, lack of mainstream IDE support, confusing sigils and references, and the list could go on. *These* are the reason why Perl is not often taken seriously as an option for building large scale systems any more (by people not inside this room of course). Ultimately, this is, I believe, exactly why people say ...
Mark Keating no amount of Mark Keating is gonna solve ... oops, sorry wrong slide, I mean’t ... (with apologies to Mark, the joke was just too hard to resist)
Marketing ... no amount of “marketing” can fix this. It does not matter how many cool modules we make; our Moose-es, our Dancers, our Mojoliciousessssesss. Deep down, we are still Perl, and you can still use formats, you can still check unix user group membership, you can still run your Perl 1 script. And even CPAN, our most popular goto reasoning for still using Perl, it is suffering the same fate.
“But what’s so wrong with this?” you ask. Perl has always been a language about getting things done, no matter how sloppy or dirty or ugly. What matters is that it works.
Perl is also a glue language, it can be used to bind all sorts of things together, from simple unix commands, to C libraries, to large project builds, to entire systems, to networks of systems, to networks of networks of systems, and on and on and on. When you are just the sticky messy stuff in between, there is no need to be clean and pretty.
And you know what, some of those systems that Perl holds together, they are mission critical financial systems, which, if Perl were to slow down by just a second of execution time, could cost a lot of people a lot of money. And that code, it is not elegant and clean, it is not well-factored,.. it just f-ing works and that is *ALL* that maters!
Spinning earth ... In short, in more ways then most people might think, Perl, in all its ugly glory, helps to keep the world moving along. If for this reason alone we should just keep Perl as it is, right?
“Again, what is wrong with this?” you might ask. Well, nothing, as long as you don’t mind Perl becoming the next COBOL. And you know what, maybe we really don’t mind that either. If that is what *some* of the community wants, that is fine. There is still a lot of money to be made in COBOL these days, so why not let Perl follow in those footsteps?
PERL “Again, what is wrong with this?” you might ask. Well, nothing, as long as you don’t mind Perl becoming the next COBOL. And you know what, maybe we really don’t mind that either. If that is what *some* of the community wants, that is fine. There is still a lot of money to be made in COBOL these days, so why not let Perl follow in those footsteps?
But what about those of us want to see the language move forward? why do we have to be shackled and weighed down by the ball-and-chain of backwards compatibility? Why can’t we have nice things? Those of us who write new code and new systems in Perl, we want to be able to take advantage of some of the modern features we see in other languages but which are not available to us in Perl. That said, we also want to be able to take advantage of some of the excellent flexibility and robustness that Perl offers that other languages do not.
sub sum (@x, $acc = 0) { return $acc if @x.length == 0; return sum( @x.tail, @x.head + $acc ) } Wouldn’t it be awesome if we had subroutine signatures? I mentioned in my Orlando talk, FORTRAN had signatures, as did COBOL, and LISP. Given that those are three of the oldest programming languages out there, it is pretty sad that we are still debating, in 2013, whether we should even add subroutine signatures to Perl. So instead, we have this ...
sub sum { my ($x, $acc) = @_; $acc //= 0; return $acc if @{$x} == 0; return sum( $x, (shift @{$x}) + $acc ) } Note that the // (defined-or) will only work on 5.10 and above. Also bask in the glow of the horrid dereferencing syntax for array references. Sure you could write this differently to avoid those, there are about 50 different ways that you could write this same simple subroutine if you wanted, thats TIMTOWTDI after all (for better or for worse).
class Point { has $!x = 0; has $!y = 0; method x ($x?) { $!x = $x if $x.defined; $!x } method y ($y?) { $!y = $y if $y.defined; $!y } method clear { ($!x, $!y) = (0, 0); } } What about a proper class system? Heck, Larry already designed one for Perl 6, we could just implement that! (perhaps slightly simplified)
package Point; use strict; use warnings; sub new { my ($class, %args) = @_; bless { x => $args{'x'}, y => $args{'y'} } => ref($class) || $class; } sub x { my $self = shift; $self->{'x'} = shift if @_; $self->{'x'}; } sub y { my $self = shift; $self->{'y'} = shift if @_; $self->{'y'}; } sub clear { my $self = shift; $self->{'x'} = 0; $self->{'y'} = 0; } 1; Instead we are stuck with the old system of blessed references, subroutines in packages masquerading as methods, magic @ISA variables filled with strings that should map to other packages to provide inheritance. This system, when it was created in 1995 was elegant in its simplicity and clever in it’s use/abuse of existing features. However, a lot of thinking has gone into OO programming since then, and it is time for us too to move on.
try { ... SomeException.new.throw; } catch { when ($_.isa('SomeException')) { warn "Got SomeException: " ~ $_.message; } default { die $_; } } And what about exception handling? Most languages have some form of structured exceptions, a few outliers still allow strings to be thrown, but mostly they have all moved to some kind of exception object.
my $error = do { local $@; eval { ... die 'Some Exception'; # OR SomeException->new->throw; }; $@; }; if ($@) { if (ref $@) { if ($@->isa('SomeException')) { warn "Got SomeException: " . $_->message; } else { die $_; } } else { if ($@ =~ /^Some Exception/) { warn "Got SomeException: " . $@; } else { die $_; } } } To do this properly and safely we would need to jump through a ton of obscure and nasty hoops. And this doesn’t even handle all the edge cases, such as overloaded objects, the possibility of $@ being a valid false value, etc.
use Try::Tiny; try { ... die 'Some Exception'; # OR SomeException->new->throw; } catch { when (ref $_ && $_->isa('SomeException')) { warn "Got SomeException: " . $_->message; } when (/^Some Exception/) { warn "Got SomeException: " . $_; } default { die $_; } }; Thankfully this is one that is partially fixed by the Try::Tiny. But you still need to check for exceptions that are not string as well as account for the plethora of possible exception module APIs that might be used because Try::Tiny only solves the try/catch block, not the exception side of thing. Which means it only solves one side of the problem, in that it makes no attempt to standardize the exception objects for Perl.
class BlockingQueue { has $!capacity; has @!items = []; method enqueue ($item) is synchronized { while (@!items.length == $!capacity) { $?THREAD.wait; } @!items.push($item) $?THREAD.notify; } method dequeue is synchronized { while (@!items.length == 0) { $?THREAD.wait; } my $item = @!items.shift; $?THREAD.notify; $item; } } And wouldn’t it be nice to have proper threads? Even though thread programming it fraught with issues, and this theoretical version above probably will suffer from race conditions and various other issues, at least it would be real threads!
package BlockingQueue; use strict; use warnings; use threads::shared; sub new { my $class = shift; my @queue : shared = map { shared_clone($_) } @_; my %self : shared = ( 'queue' => \@queue ); bless \%self => $class; } sub enqueue { my $self = shift; lock %{$self}; push(@{$self->{'queue'}} => map { shared_clone($_) } @_) and cond_signal %{$self}; } sub dequeue { my $self = shift; lock %{$self}; my $queue = $self->{'queue'}; cond_wait(%{$self}) while (@{$queue} < 1); cond_signal(%$self) if (@{$queue} > 1); shift @$queue; } 1; But instead we have a really horrid and broken threading system that most people don’t even enable when the build Perl. Some of the really horrid bits are the use of subroutine attributes to mark things as shared and the fact that we have to dereference $self in order to lock it. I will be honest, I am not even sure if this code works, mostly because didn’t really want to spend time building a threaded perl. So instead I just stole most of this code out of the Thread::Queue module and tweaked it to my needs. It most likely segfaults and deletes you entire ~/music directory out of spite.
class Ping extends Actor { has $!count; has $!pong; method act { my $pings_left = $!count - 1; $!pong.send('PING'); self.receive(sub ($sender) { when ('PONG') { if ($pings_left > 0) { say "Ping: pong"; $!pong.send('PING'); $pings_left--; } else { say "Ping: stop"; $!pong.send('STOP'); self.exit; } } }); } } But you know what would be even better then some race-condition prone thread system that was really just a throwback to the late 90s? A proper Actor system! For those who aren’t familiar, the Actor pattern is a concurrency pattern championed by the Erlang language. It is based on the idea that concurrent “processes” would simply send messages back and forth and react to those messages.
class Pong extends Actor { method act { my $pong_count = 0; self.receive(sub ($sender) { when ('PING') { say "Pong: ping " ~ $pong_count; $sender.send('PONG'); $pong_count++; } when ('STOP') { say "Pong: stop"; self.exit; } }); } } And Erlang, despite it’s relatively new status of “cool language”, is actually pretty old, it “escaped the lab” sometime around 1989 and has been in production use ever since in what are called “soft” realtime systems for Ericcson’s phone switches. So this model has ultimately proven to be very robust and resilient. Recently Java, via the Akka framework and the Scala language has adopted the Actor pattern as a way of doing concurrency that does not suffer from some of the issues that raw threads suffer from.
my $pong = Pong.new; my $ping = Ping.new(count => 100_000, pong => $pong); $ping.start; $pong.start; The other nice aspect is that Actors means you never have to care how your concurrency is being implemented. Meaning that it should just be a matter of maybe adding a few constructor parameters ...
my $pong = Pong.new(host => 10.0.1.5); $pong.start; # ... meanwhile on another machine my $ping = Ping.new( host => 10.0.1.2, count => 100_000, pong => “[email protected]” ); $ping.start; ... and suddenly your actors at no longer just threads on the same machine, but distributed nodes in a network.
die 'Actors do not exist in perl’; And unfortunately Perl does not have anything that really comes close to this in terms of simplicity on abstraction. Sure Perl has been doing Event based concurrency for a long time and we have a couple of nice time tested modules for it. One was voted the best module of the year in 1999 (14 years ago), the other recently released a version which purposefully died if a specific module was found inside the %INC. So while we have something that could, in theory, support an actor style implementation, the situation is far from ideal (and at times not even stable).
The whole intent of Perl 5's module system was to encourage the growth of Perl culture rather than the Perl core. – Larry Wall Let me pull out a Larry quote here ... Any of those features I listed would require sizable work and changes to the core, which could in turn endanger CPAN. It has been proposed by some that we just keep adding hooks into the core so that people can build these features as CPAN modules. And I actually used this quote in a talk I gave at YAPC::EU last year to justify this exact approach with the p5-mop project. However, there is a point after which taking this approach to add new features fails and people begin to need to make ugly compromises in order to accomplish the seamlessness needed to make a feature feel native.
Perl was always designed to be an evolving language. – Larry Wall Which brings me to this Larry quote. I believe right now, we are at an evolutionary crossroads with Perl.
to start with, everything I said in Orlando still holds true. I believe this now more then ever having spent a significant amount of time over the last 6 months looking at both the Perl 5 core, CPAN and Perl 6.
Perl 5 Core Learning Curve At this point the learning curve (or perhaps more appropriately, the learning right angle) of the core codebase is simply too large for anyone one person to learn it without it being their full time job and a serious passion. Of all the current maintainers only two (Nick Clark and Dave Mitchell) have any hope of understanding the whole thing, everyone else is just a specialist in his/her pet peeve.
Perl 5 Core Learning Curve At this point the learning curve (or perhaps more appropriately, the learning right angle) of the core codebase is simply too large for anyone one person to learn it without it being their full time job and a serious passion. Of all the current maintainers only two (Nick Clark and Dave Mitchell) have any hope of understanding the whole thing, everyone else is just a specialist in his/her pet peeve.
This is a real problem because this means that anything but small changes are likely to break things (unless the change in question only affects a single isolated subsystem, and I suspect on the regexp engine falls into that criteria).
And to make matters worse, the test suite, oh the horrors of the test suite. I recently spent some time at the NY.pm hackathon trying to revive strict-perl, which was an experiment started by chromatic to have a perl in which “strict” was always on. It was fine until I hit the core test suite and oh what a mess it was.
So then, how can you make significant improvements to a codebase in which no one person understands the entire thing and whose test suite is a giant sloppy mess? Sure we have a mess of smoke servers and we have CPANTesters and all that. This stuff works great for bug fixes and easily fixed issues such as the Perl 5.18 hash randomization change. But how well would it work in the face of larger sweeping changes? How many iterations of smoke testing and such would it take? How many bugs and language abuses would it perhaps uncover? How long would people be willing to be deal with this?
But this is not just about the core anymore, it is also about CPAN too. Because many of those features I listed will require changes to some core CPAN modules.
A few years ago, Perl 6 was declared not to be the successor to Perl 5, but that they were sister languages. This means then that Perl 5 can start moving forward too, we are no longer waiting.
So then, is Moe the answer you may be asking? No, it is not the answer. Moe has always been meant to be a fun project, a thought experiment. As I said originally, I am modeling it after the Pugs project, and specifically the idea that there needed to be a way to test out new language features for Perl. While re-writing the runtime might seem an extreme solution it was actually simpler (and a hell of a lot more fun) then trying to hack it atop the Perl 5 core.
-Ofun So then, is Moe the answer you may be asking? No, it is not the answer. Moe has always been meant to be a fun project, a thought experiment. As I said originally, I am modeling it after the Pugs project, and specifically the idea that there needed to be a way to test out new language features for Perl. While re-writing the runtime might seem an extreme solution it was actually simpler (and a hell of a lot more fun) then trying to hack it atop the Perl 5 core.
Moe is an attempt to show a way forward, not be a way forward. Moe is my attempt at taking some of the aspects I love about Perl 5, and replacing all the bits I don’t like with a trimmed down version of what Perl 6 does. I wanted to see if I could piece together a language that had some of the Perl 6 shiny, but was still comfortable in the hands of a Perl 5 programmer. But you know what, Moe is not the only Perl 5 re-write project out there, ...
.ooo 'OOOo ~ p ooOOOo 2 ~ .OOO oO %% a fast perl5 Oo 'O ` (o) ___/ / /` \ /v^ ` , (...v/v^/ \../::/ \/::/ There is also p2, which is a project started by Reini Urban using the “potion” VM (originally written by _why the lucky stiff). Reini’s goals are to make a new runtime for Perl 5 that can parse almost all of perl 5 and support some subset of XS, meaning his goal is for partial backwards compatibility with as much CPAN as he can manage. Reini also plans to add some extensions to the language as well, ...
my int $i = 1; my const str $x = 'hello world'; my const @a = (0,1); my const %h = ('ok' => 1, 'nok' => 0); ... such as compile time checking of the perl type annotations and compile time enforced constant declarations
my $a[10]; my int $a[10]; ... p2 will also include sized arrays (which can also be optionally typed). These will not auto-vivify, meaning they cannot be extended, and will be compile time initialized to ‘undef’.
{ no magic; use Config; print $Config{ccflags}; } # error: Invalid use of # tie with no magic ... p2 will also include a pragma that will lexically turn off magic allowing the compiler to make more optimizations under the hood. Reini also plans other features such as a new match/case operator, a more extensible and flexible parser, and macros on the level of LISP.
Perlito There is also Perlito, which the author Flavio Glock calls “a compiler collection that implements a subset of Perl 5 and Perl 6”. Keep in mind these are subsets of Perl 5/6 and I think Flavio would characterize Perlito much like Moe in that it is his own personal playground for experimenting with compiling of Perl like languages.
Perlito • Perl 5 㱺 Perl 5 There is also Perlito, which the author Flavio Glock calls “a compiler collection that implements a subset of Perl 5 and Perl 6”. Keep in mind these are subsets of Perl 5/6 and I think Flavio would characterize Perlito much like Moe in that it is his own personal playground for experimenting with compiling of Perl like languages.
Perlito • Perl 5 㱺 Perl 5 • Perl 5 㱺 Javascript There is also Perlito, which the author Flavio Glock calls “a compiler collection that implements a subset of Perl 5 and Perl 6”. Keep in mind these are subsets of Perl 5/6 and I think Flavio would characterize Perlito much like Moe in that it is his own personal playground for experimenting with compiling of Perl like languages.
Perlito • Perl 5 㱺 Perl 5 • Perl 5 㱺 Javascript • Perl 6 㱺 Perl 5 There is also Perlito, which the author Flavio Glock calls “a compiler collection that implements a subset of Perl 5 and Perl 6”. Keep in mind these are subsets of Perl 5/6 and I think Flavio would characterize Perlito much like Moe in that it is his own personal playground for experimenting with compiling of Perl like languages.
Perlito • Perl 5 㱺 Perl 5 • Perl 5 㱺 Javascript • Perl 6 㱺 Perl 5 • Perl 6 㱺 Javascript There is also Perlito, which the author Flavio Glock calls “a compiler collection that implements a subset of Perl 5 and Perl 6”. Keep in mind these are subsets of Perl 5/6 and I think Flavio would characterize Perlito much like Moe in that it is his own personal playground for experimenting with compiling of Perl like languages.
Perlito • Perl 5 㱺 Perl 5 • Perl 5 㱺 Javascript • Perl 6 㱺 Perl 5 • Perl 6 㱺 Javascript • Perl 6 㱺 Python 2.6 There is also Perlito, which the author Flavio Glock calls “a compiler collection that implements a subset of Perl 5 and Perl 6”. Keep in mind these are subsets of Perl 5/6 and I think Flavio would characterize Perlito much like Moe in that it is his own personal playground for experimenting with compiling of Perl like languages.
Perlito • Perl 5 㱺 Perl 5 • Perl 5 㱺 Javascript • Perl 6 㱺 Perl 5 • Perl 6 㱺 Javascript • Perl 6 㱺 Python 2.6 • Perl 5 㱺 Perl 6 There is also Perlito, which the author Flavio Glock calls “a compiler collection that implements a subset of Perl 5 and Perl 6”. Keep in mind these are subsets of Perl 5/6 and I think Flavio would characterize Perlito much like Moe in that it is his own personal playground for experimenting with compiling of Perl like languages.
Perlito • Perl 5 㱺 Perl 5 • Perl 5 㱺 Javascript • Perl 6 㱺 Perl 5 • Perl 6 㱺 Javascript • Perl 6 㱺 Python 2.6 • Perl 5 㱺 Perl 6 • Perl 6 㱺 Ruby 1.9 There is also Perlito, which the author Flavio Glock calls “a compiler collection that implements a subset of Perl 5 and Perl 6”. Keep in mind these are subsets of Perl 5/6 and I think Flavio would characterize Perlito much like Moe in that it is his own personal playground for experimenting with compiling of Perl like languages.
Perlito • Perl 5 㱺 Perl 5 • Perl 5 㱺 Javascript • Perl 6 㱺 Perl 5 • Perl 6 㱺 Javascript • Perl 6 㱺 Python 2.6 • Perl 5 㱺 Perl 6 • Perl 6 㱺 Ruby 1.9 • Perl 6 㱺 Go There is also Perlito, which the author Flavio Glock calls “a compiler collection that implements a subset of Perl 5 and Perl 6”. Keep in mind these are subsets of Perl 5/6 and I think Flavio would characterize Perlito much like Moe in that it is his own personal playground for experimenting with compiling of Perl like languages.
Perlito • Perl 5 㱺 Perl 5 • Perl 5 㱺 Javascript • Perl 6 㱺 Perl 5 • Perl 6 㱺 Javascript • Perl 6 㱺 Python 2.6 • Perl 5 㱺 Perl 6 • Perl 6 㱺 Ruby 1.9 • Perl 6 㱺 Go • Perl 6 㱺 Common Lisp (SBCL) There is also Perlito, which the author Flavio Glock calls “a compiler collection that implements a subset of Perl 5 and Perl 6”. Keep in mind these are subsets of Perl 5/6 and I think Flavio would characterize Perlito much like Moe in that it is his own personal playground for experimenting with compiling of Perl like languages.
gperl there is also gperl which I don’t know a huge amount about, the author is japanese. His github description of the project indicates that he clearly is aiming for speed it seems to be primarily written in C++ and perhaps most interestingly, he has been releasing modules to CPAN which appear to contain elements of the overall gperl in it. Specifically he released Compiler::Lexer which is a lexical analyzer for Perl code. He also has a Compiler::Parser which is still on github but which appears to be an AST (abstract syntax tree) for Perl 5 all of which is accessible to Perl 5 code.
gperl • goccy (Masaaki Goshima) there is also gperl which I don’t know a huge amount about, the author is japanese. His github description of the project indicates that he clearly is aiming for speed it seems to be primarily written in C++ and perhaps most interestingly, he has been releasing modules to CPAN which appear to contain elements of the overall gperl in it. Specifically he released Compiler::Lexer which is a lexical analyzer for Perl code. He also has a Compiler::Parser which is still on github but which appears to be an AST (abstract syntax tree) for Perl 5 all of which is accessible to Perl 5 code.
gperl • goccy (Masaaki Goshima) • “fastest perl like language” there is also gperl which I don’t know a huge amount about, the author is japanese. His github description of the project indicates that he clearly is aiming for speed it seems to be primarily written in C++ and perhaps most interestingly, he has been releasing modules to CPAN which appear to contain elements of the overall gperl in it. Specifically he released Compiler::Lexer which is a lexical analyzer for Perl code. He also has a Compiler::Parser which is still on github but which appears to be an AST (abstract syntax tree) for Perl 5 all of which is accessible to Perl 5 code.
gperl • goccy (Masaaki Goshima) • “fastest perl like language” • C++ there is also gperl which I don’t know a huge amount about, the author is japanese. His github description of the project indicates that he clearly is aiming for speed it seems to be primarily written in C++ and perhaps most interestingly, he has been releasing modules to CPAN which appear to contain elements of the overall gperl in it. Specifically he released Compiler::Lexer which is a lexical analyzer for Perl code. He also has a Compiler::Parser which is still on github but which appears to be an AST (abstract syntax tree) for Perl 5 all of which is accessible to Perl 5 code.
gperl • goccy (Masaaki Goshima) • “fastest perl like language” • C++ • Compiler::Lexer / Compiler::Parser there is also gperl which I don’t know a huge amount about, the author is japanese. His github description of the project indicates that he clearly is aiming for speed it seems to be primarily written in C++ and perhaps most interestingly, he has been releasing modules to CPAN which appear to contain elements of the overall gperl in it. Specifically he released Compiler::Lexer which is a lexical analyzer for Perl code. He also has a Compiler::Parser which is still on github but which appears to be an AST (abstract syntax tree) for Perl 5 all of which is accessible to Perl 5 code.
perl5i And actually, I think too that Michael Schwern’s perl5i falls into this same category. He is kind of taking a Kitchen Sink approach to language design in that he has heaped together a whole bunch of very interesting CPAN modules, all which in some way affect the syntax and semantics of Perl. He calls this an “imaginary world” and he invites the Perl community to throw in their two cents. He also declares pretty loudly in the documentation that he does not intend to be backwards compatible with Perl 5 itself, but he also declares that he won’t promise being compatible with perl5i either. Basically he is declaring his right to experiment.
perl5i • Michael Schwern And actually, I think too that Michael Schwern’s perl5i falls into this same category. He is kind of taking a Kitchen Sink approach to language design in that he has heaped together a whole bunch of very interesting CPAN modules, all which in some way affect the syntax and semantics of Perl. He calls this an “imaginary world” and he invites the Perl community to throw in their two cents. He also declares pretty loudly in the documentation that he does not intend to be backwards compatible with Perl 5 itself, but he also declares that he won’t promise being compatible with perl5i either. Basically he is declaring his right to experiment.
perl5i • Michael Schwern • Kitchen Sink And actually, I think too that Michael Schwern’s perl5i falls into this same category. He is kind of taking a Kitchen Sink approach to language design in that he has heaped together a whole bunch of very interesting CPAN modules, all which in some way affect the syntax and semantics of Perl. He calls this an “imaginary world” and he invites the Perl community to throw in their two cents. He also declares pretty loudly in the documentation that he does not intend to be backwards compatible with Perl 5 itself, but he also declares that he won’t promise being compatible with perl5i either. Basically he is declaring his right to experiment.
perl5i • Michael Schwern • Kitchen Sink • Autobox, MOP, subroutine signatures, utf8::all, Time::y2038, autodie and more And actually, I think too that Michael Schwern’s perl5i falls into this same category. He is kind of taking a Kitchen Sink approach to language design in that he has heaped together a whole bunch of very interesting CPAN modules, all which in some way affect the syntax and semantics of Perl. He calls this an “imaginary world” and he invites the Perl community to throw in their two cents. He also declares pretty loudly in the documentation that he does not intend to be backwards compatible with Perl 5 itself, but he also declares that he won’t promise being compatible with perl5i either. Basically he is declaring his right to experiment.
perl5i • Michael Schwern • Kitchen Sink • Autobox, MOP, subroutine signatures, utf8::all, Time::y2038, autodie and more • Backwards Incompatible with Perl 5 and itself And actually, I think too that Michael Schwern’s perl5i falls into this same category. He is kind of taking a Kitchen Sink approach to language design in that he has heaped together a whole bunch of very interesting CPAN modules, all which in some way affect the syntax and semantics of Perl. He calls this an “imaginary world” and he invites the Perl community to throw in their two cents. He also declares pretty loudly in the documentation that he does not intend to be backwards compatible with Perl 5 itself, but he also declares that he won’t promise being compatible with perl5i either. Basically he is declaring his right to experiment.
NQP And there is also NQP, which most people associate with Perl 6. However one of the more interesting developments to come out of the Perl Reunification Summit that was recently held in Perl Germany, was the idea of using it to also run Perl 5. It was during this summit when Larry revived a project called STD5 which is a standard grammar for Perl 5 using the same grammar engine that they are using for Perl 6. This means it may eventually be possible to run Perl 5 on top of the Rakudo infrastructure, which would be a giant boon for 5<->6 interoperability.
STD5 And there is also NQP, which most people associate with Perl 6. However one of the more interesting developments to come out of the Perl Reunification Summit that was recently held in Perl Germany, was the idea of using it to also run Perl 5. It was during this summit when Larry revived a project called STD5 which is a standard grammar for Perl 5 using the same grammar engine that they are using for Perl 6. This means it may eventually be possible to run Perl 5 on top of the Rakudo infrastructure, which would be a giant boon for 5<->6 interoperability.
[ ] Perl 6 [ ] Moe [ ] p2/potion [ ] Perlito [ ] gperl [ ] perl5i [ ] p5 on Rakudo [ ] All of the above So what is the answer? x 6 ... The answer is “All of the above” a number of other languages out there are doing just fine with multiple implementations which are not 100% compatible with one another (Python, Ruby, Javascript, etc). In fact, those languages are thriving as the projects borrow from one another to improve the languages as a whole. So why then does Perl have to stick with the idea of the one-true-perl?
[ ] Perl 6 [ ] Moe [ ] p2/potion [ ] Perlito [ ] gperl [ ] perl5i [ ] p5 on Rakudo [ ] All of the above MoarVM So what is the answer? x 6 ... The answer is “All of the above” a number of other languages out there are doing just fine with multiple implementations which are not 100% compatible with one another (Python, Ruby, Javascript, etc). In fact, those languages are thriving as the projects borrow from one another to improve the languages as a whole. So why then does Perl have to stick with the idea of the one-true-perl?
[ ] Perl 6 [ ] Moe [ ] p2/potion [ ] Perlito [ ] gperl [ ] perl5i [ ] p5 on Rakudo [ ] All of the above MoarVM So what is the answer? x 6 ... The answer is “All of the above” a number of other languages out there are doing just fine with multiple implementations which are not 100% compatible with one another (Python, Ruby, Javascript, etc). In fact, those languages are thriving as the projects borrow from one another to improve the languages as a whole. So why then does Perl have to stick with the idea of the one-true-perl?
After all, isn’t this the whole idea behind “Pumpkin Perl”? To assign a name to the old Perl and therefore allow new Perl’s to be made? To make the number less important then the name? To allow a way forward that still allows us to keep the promises of the past. After all, Perl is a multi-paradigm language, which means you can program it in different styles; procedural, object-oriented, functional. Perl is also a multi-purpose programming language, which means you can use it in a number of different environments; shell-scripting, GUI applications, web applications, data crunching, etc. Why can’t we have different Perl’s optimized for different environments? As a shell scripter I care about startup time, as a web-application programming, I could give a shit less about startup.
Moving forward requires change and change is never easy And I never said this was going to be easy. But it is our collective responsibility to decide what we are going to do about this. And not just in the core ...
CPAN is my language, Perl is just the syntax. We must both reinvigorate Perl the language (meaning CPAN) as well as Perl the syntax. If we can do that, we will show the world how awesome Perl the Community really is.
Because the reality is that Perl is not just a syntax, but also Perl is a community, a community of very awesome like-minded folk who all happen to love Perl. As long as the Perl community is still around, Perl will never be dead. But its up to each and every one of us to do our part to help keep it alive and to keep it exciting and keep it moving. This is our language, this is our community, and we need to make it great!
while (@community) { $Perl = !$DEAD } Because the reality is that Perl is not just a syntax, but also Perl is a community, a community of very awesome like-minded folk who all happen to love Perl. As long as the Perl community is still around, Perl will never be dead. But its up to each and every one of us to do our part to help keep it alive and to keep it exciting and keep it moving. This is our language, this is our community, and we need to make it great!
stevan_little
shumpei0111
akarin
hschwentner
joker1007
workspace93
tmikov2023
daisukeshinoku
gmvalentino8
uhooi
poteboy
chobishiba
%20-%20%E3%82%B3%E3%83%94%E3%83%BC.png){kind=avatar}
picopico
ammeep
geoffreycrofte
kastner
tammielis
danielanewman
keavy
keithpitt
deanohume
jennybc
eileencodes
brianwarren
robhawkes