Perl - The Detroit of Scripting Languages

Slide 1

Slide 1 text

Stevan Little – YAPC::NA 2013, Austin,TX – [email protected] Perl The Detroit of Scripting Languages

Slide 2

Slide 2 text

well actually, it was only about 6 months ago, ...

Slide 3

Slide 3 text

and it wasn’t really that far away, it was only in Orlando, which is about 16 hrs by car, or 369 hours on foot, but that is not the point ...

Slide 4

Slide 4 text

Stevan Little Orlando Perl Workshop 2013 [email protected] Perl is not dead, it is a So I gave a talk at the always awesome Orlando Perl Workshop.

Slide 5

Slide 5 text

21000+ ... it kind of “ignited” a lot of discussions and gotten over 21000 views on speakerdeck

Slide 6

Slide 6 text

This will be a circus of profanity, ﬁlled 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 ﬁne for OPW, however at YAPC ...

Slide 7

Slide 7 text

This will be a circus of (mostly censored) profanity, ﬁlled 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.

Slide 8

Slide 8 text

The Community In that talk I spoke about the perl community

Slide 9

Slide 9 text

Echo Echo Echo Echo Echo and how much of an echo chamber we live in

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

Slide 12

Slide 12 text

CGI Flipping ^ I spoke about our community obsession with hanging onto the old ways of doing things and not being willing to let them go.

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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.

Slide 15

Slide 15 text

I spoke about Perl 6 and unfortunate hole that it must climb out of

Slide 16

Slide 16 text

I spoke about Perl 6 and unfortunate hole that it must climb out of

Slide 17

Slide 17 text

WHO IN THEIR RIGHT FUDGING MIND WOULD WANT TO MAINTAIN THE PERL 5 CORE ?!!? and I spoke about the horrid state of the Perl 5 core

Slide 18

Slide 18 text

... and I am sure by now you are asking yourself why I am being so negative

Slide 19

Slide 19 text

NOT SURE IF TROLLING ... and I am sure by now you are asking yourself why I am being so negative

Slide 20

Slide 20 text

NOT SURE IF TROLLING OR JUST AN ASSHOLE ... and I am sure by now you are asking yourself why I am being so negative

Slide 21

Slide 21 text

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.

Slide 22

Slide 22 text

WTMOE!?!?! And in the end of this talk, I announced a project called Moe, which I called an -OFun prototype of an Ultra Modern Perl.

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

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).

Slide 25

Slide 25 text

Slide 26

Slide 26 text

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).

Slide 27

Slide 27 text

Perl sucks So, anyway that was the past, lets get on with *this* talk. So ﬁrst, 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 ﬁx up Detroit, but no one knows or cares (a really, really lot like Perl)!

Slide 28

Slide 28 text

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 ...

Slide 29

Slide 29 text

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 ﬁrst phase, because I think it uncovered some important problems in our community that we need to discuss.

Slide 30

Slide 30 text

So one of the ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 31

Slide 31 text

Replace -> with . So one of the ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 32

Slide 32 text

Replace -> with . Get rid of AUTOLOAD So one of the ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 33

Slide 33 text

Replace -> with . Get rid of AUTOLOAD Include a MOP So one of the ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 34

Slide 34 text

Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls So one of the ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 35

Slide 35 text

Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls XS must die! So one of the ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 36

Slide 36 text

Replace -> with . Get rid of AUTOLOAD Include a MOP Remove indirect method calls XS must die! Add subroutine signatures So one of the ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 37

Slide 37 text

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 ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 38

Slide 38 text

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 ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 39

Slide 39 text

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 ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 40

Slide 40 text

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 ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 41

Slide 41 text

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 ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 42

Slide 42 text

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 ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 43

Slide 43 text

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 ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 44

Slide 44 text

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 ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 45

Slide 45 text

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 ﬁrst things that happened after I announced Moe was that the community started to throw in their two cents. . It seems that there a lot of features in Perl that many people really dislike or that people would like to see overhauled.

Slide 46

Slide 46 text

${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 ...

Slide 47

Slide 47 text

(this slide speaks for itself)

Slide 48

Slide 48 text

FUUUU UUUUU UUUUU UUUUU UUUUU UUUUU (this slide speaks for itself)

Slide 49

Slide 49 text

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.

Slide 50

Slide 50 text

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).

Slide 51

Slide 51 text

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!

Slide 52

Slide 52 text

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!

Slide 53

Slide 53 text

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!

Slide 54

Slide 54 text

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 ...

Slide 55

Slide 55 text

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 ...

Slide 56

Slide 56 text

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.

Slide 57

Slide 57 text

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.

Slide 58

Slide 58 text

Now, I don’t mean to be picking on Schwern, buuuuut since he is not here, I ﬁgured, ... 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!

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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.

Slide 63

Slide 63 text

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.

Slide 64

Slide 64 text

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.

Slide 65

Slide 65 text

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.

Slide 66

Slide 66 text

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.

Slide 67

Slide 67 text

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.

Slide 68

Slide 68 text

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 ﬁrst 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.

Slide 69

Slide 69 text

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 ﬁrst 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.

Slide 70

Slide 70 text

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 ﬁrst 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.

Slide 71

Slide 71 text

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 ﬁrst 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.

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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 ...

Slide 74

Slide 74 text

... 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 ...

Slide 75

Slide 75 text

PERL do people really still use that?! “PERL, do people really still use that??” And you know what ...

Slide 76

Slide 76 text

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)

Slide 77

Slide 77 text

Marketing ... no amount of “marketing” can ﬁx 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.

Slide 78

Slide 78 text

“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.

Slide 79

Slide 79 text

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.

Slide 80

Slide 80 text

And you know what, some of those systems that Perl holds together, they are mission critical ﬁnancial 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!

Slide 81

Slide 81 text

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?

Slide 82

Slide 82 text

“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 ﬁne. There is still a lot of money to be made in COBOL these days, so why not let Perl follow in those footsteps?

Slide 83

Slide 83 text

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 ﬁne. There is still a lot of money to be made in COBOL these days, so why not let Perl follow in those footsteps?

Slide 84

Slide 84 text

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 ﬂexibility and robustness that Perl offers that other languages do not.

Slide 85

Slide 85 text

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 ...

Slide 86

Slide 86 text

sub sum { my ($x, $acc) = @_; $acc //= 0; return $acc if @{$x} == 0; return sum( $x, (shift @{$x}) + $acc ) } Note that the // (deﬁned-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).

Slide 87

Slide 87 text

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 simpliﬁed)

Slide 88

Slide 88 text

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 ﬁlled 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.

Slide 89

Slide 89 text

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.

Slide 90

Slide 90 text

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.

Slide 91

Slide 91 text

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 ﬁxed 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.

Slide 92

Slide 92 text

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!

Slide 93

Slide 93 text

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.

Slide 94

Slide 94 text

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.

Slide 95

Slide 95 text

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.

Slide 96

Slide 96 text

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 ...

Slide 97

Slide 97 text

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.

Slide 98

Slide 98 text

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 speciﬁc 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).

Slide 99

Slide 99 text

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.

Slide 100

Slide 100 text

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.

Slide 101

Slide 101 text

? So then, assuming you agree with me that we have a problem, how do we ﬁx this? How do we make Perl move Perl forward into the future?

Slide 102

Slide 102 text

to start with, everything I said in Orlando still holds true. I believe this now more then ever having spent a signiﬁcant amount of time over the last 6 months looking at both the Perl 5 core, CPAN and Perl 6.

Slide 103

Slide 103 text

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.

Slide 104

Slide 104 text

Slide 105

Slide 105 text

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).

Slide 106

Slide 106 text

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 ﬁne until I hit the core test suite and oh what a mess it was.

Slide 107

Slide 107 text

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?

Slide 108

Slide 108 text

Once again, we are at a dead end. We cannot break our 25 year commitment to backwards compatibility even if we wanted too.

Slide 109

Slide 109 text

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.

Slide 110

Slide 110 text

6 So is Perl 6 our only hope? I believe the answer to that is no, but if not, then what?

Slide 111

Slide 111 text

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.

Slide 112

Slide 112 text

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 speciﬁcally 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.

Slide 113

Slide 113 text

-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 speciﬁcally 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.

Slide 114

Slide 114 text

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, ...

Slide 115

Slide 115 text

.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, ...

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

int method adder (int \$self, int -$a=1) { $self += $a; } Reini also plans to have ‘class’ and ‘method’ keywords as well as subroutine signatures

Slide 118

Slide 118 text

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’.

Slide 119

Slide 119 text

{ 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 ﬂexible parser, and macros on the level of LISP.

Slide 120

Slide 120 text

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.

Slide 121

Slide 121 text

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.

Slide 122

Slide 122 text

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.

Slide 123

Slide 123 text

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.

Slide 124

Slide 124 text

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.

Slide 125

Slide 125 text

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.

Slide 126

Slide 126 text

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.

Slide 127

Slide 127 text

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.

Slide 128

Slide 128 text

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.

Slide 129

Slide 129 text

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.

Slide 130

Slide 130 text

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. Speciﬁcally 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.

Slide 131

Slide 131 text

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. Speciﬁcally 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.

Slide 132

Slide 132 text

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. Speciﬁcally 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.

Slide 133

Slide 133 text

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. Speciﬁcally 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.

Slide 134

Slide 134 text

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. Speciﬁcally 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.

Slide 135

Slide 135 text

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.

Slide 136

Slide 136 text

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.

Slide 137

Slide 137 text

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.

Slide 138

Slide 138 text

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.

Slide 139

Slide 139 text

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.

Slide 140

Slide 140 text

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 Reuniﬁcation 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.

Slide 141

Slide 141 text

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 Reuniﬁcation 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.

Slide 142

Slide 142 text

[ ] 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 ﬁne 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?

Slide 143

Slide 143 text

[ ] 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 ﬁne 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?

Slide 144

Slide 144 text

Slide 145

Slide 145 text

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.

Slide 146

Slide 146 text

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 ...

Slide 147

Slide 147 text

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.

Slide 148

Slide 148 text

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!

Slide 149

Slide 149 text

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!