Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Perl - The Detroit of Scripting Languages

Perl - The Detroit of Scripting Languages

This is the Tuesday night Keynote I gave at YAPC::NA 2013 in Austin TX.

Stevan Little

June 04, 2013
Tweet

More Decks by Stevan Little

Other Decks in Programming

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  8. The Community
    In that talk I spoke about the perl community

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  47. (this slide speaks for itself)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  142. [ ] 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?

    View Slide

  143. [ ] 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?

    View Slide

  144. [ ] 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?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide