What do you want Perl 5 to be?

I've noticed that many recent discussions about changes to Perl 5 core development spiral off into circular discussions about deprecation cycles, definitions of compatibility, source code branch strategies, timeboxing, volunteer motivation, and so on.  Consensus has been slow to converge and conflict is in the air.

I think the problem is that people have different goals for Perl 5.  Some of these goals mesh well, but others conflict.  Some of the remedies support many goals, some only one or two. And some remedies work against some goals.  Placing some goals above others has big implications for changes to the development process and for priorities for new development.

I've started brainstorming some of the goals that I've heard or read or imagine might be out there.  Maybe if we can find some common ground around some goals, getting to common ground about methods won't be quite so difficult.

Read these over and tell me what you think, here or on a blog or site of your own.  Do  you agree with some?  All?  None?  If you had to pick just one or two, what would it be?  How would you know if they happened? What would it look like? What would be different?

What do you want Perl 5 to be?

  • I want Perl 5 to be more innovative
  • I want Perl 5 to be less dependent on the heroic efforts of a shrinking pool of maintainers
  • I want Perl 5 to be rock solid for enterprise use
  • I want Perl 5 to be a better language for new development
  • I want Perl 5 to be popular
  • I want Perl 5 to be less buggy
  • I want Perl 5 to be portable to all the platforms I use
  • I want Perl 5 to be more maintainable
  • I want Perl 5 to be easier to teach
  • I want Perl 5 to be more like Perl 6
  • I want Perl 5 to be more useful to those who contribute most to it
  • I want Perl 5 to be better at solving particular types of problems
  • I want Perl 5 to be more fun

My own view is a mix of several of these, and I'll try to articulate that further in a future post.

This entry was posted in perl programming and tagged . Bookmark the permalink. Both comments and trackbacks are currently closed.

6 Comments

  1. Andrew Rodland
    Posted July 23, 2009 at 12:16 am | Permalink

    I want Perl 5 to be a better language for new development.
    I want Perl 5 to be more maintainable.
    I want Perl 5 to be what the community wants it to be.
    I want Perl 5 to live long and prosper, and not be what we use to mark time while we wait for Perl 6 to descend from the heavens.

  2. :m)
    Posted July 23, 2009 at 12:16 am | Permalink

    I would like to go for the typical "new features go into the new version" scenario.

    Reduce perl5 efforts to bug squashing and begin to let it be a legacy language.

    Put all energy available into getting parrot & rakudo out the door and do improvements there. That's what new versions are for.

    Backport some features to perl5 to ensure that projects that cannot be moved to perl6 remain attractive. Although I suspect that if there are massive problems with code, this code might be sloppy or obfuscated and really needed a fresh start.

    Aim No.1: Get rid of the image that perl is a nasty, unmaintainable language which produces unreadable, unmaintainable code.

    Sometimes you need to leave things behind, even get rid of things you have loved much to better your life. :-)

  3. Posted July 23, 2009 at 1:45 am | Permalink

    You forgot:
    I want Perl 5 to be much faster
    I want Perl 5 internals to be much cleaner

    And many more :)

  4. Posted July 23, 2009 at 5:31 am | Permalink

    @:m) Perl 6 ist a new language. Any transition from Perl 5 to Perl 6 is a transition to a new language, not to a new version of the same language.

  5. Posted July 23, 2009 at 6:45 am | Permalink

    I think what I want is close to "I want Perl 5 to be rock solid for enterprise use".

    What I want is actually: "regular code that was written for a previous version of Perl 5 should still work when I upgrade". What I mean by regular is that assumes no knowledge of the internals and doesn't rely on undocumented features.

    I want this for 2 reasons: when I upgrade Perl, I don't really want to go back and test 13 years worth of big projects, internal modules, quick tools, cron jobs, one liners. Some of this code has tests, but not all of it. Maybe I am just a terrible developer, but a job that spans from sysadmin to web development to data munger doesn't always let me follow best practices (all 256 of them). I would be willing to bet that I am not alone in that case.

    Beyond my specific situation, I also think that one of the best assets of Perl as a language is its ubiquity. It is installed everywhere, often because it is used during the OS installation. I want to keep it this way. Any time backward compatibility is broken, people who write install scripts get really pissed. And sometimes they decide to rewrite their tools in a different, even more primitive, language. I'd rather they stick to Perl. Or move to Perl from trendier languages that break compatibily.

    Beyond that, improving the internals to make it both easier to maintain the core and easier to extend it from external modules seems important.

  6. Ed
    Posted July 23, 2009 at 4:58 pm | Permalink

    I *really* like the concept introduced in 5.10 of suppressing new features by default, so that upgrades are safer. Note that I am only for this for very established versions - 6.x shouldn't have code to suppress new features like that until 5.x is clearly on the way out due to 6.x ascendancy.

    That having been said...
    # I want Perl 5 to be rock solid for enterprise use
    # I want Perl 5 to be a better language for new development
    # I want Perl 5 to be more maintainable
    # I want Perl 5 to be more popular
    # I want Perl 5 to manage memory better.

One Trackback

  • By zero-blog » Corehackers: What I Want on August 2, 2009 at 10:10 am

    [...] of discussions concerning the problems plaguing Perl 5. David Golden challenged me to respond to his post concerning what I want from Perl 5 moving [...]

© 2009-2014 David Golden All Rights Reserved