Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re: Five Features Perl 5 Needs Now

by JavaFan (Canon)
on Dec 19, 2008 at 12:41 UTC ( #731534=note: print w/replies, xml ) Need Help??


in reply to Five Features Perl 5 Needs Now

1. Regular releases
Yes, that would be very nice. But making a release is a lot of work. It has to work on all the platforms supported, not break any test, and there shouldn't be loose ends.

Unfortunally, making a release boils down to a lot of work done by very few people.

2. Moose, Mouse, and autobox.
While I think a better OO system for perl5 would have been wonderful 14 years ago, I don't think perl5 "needs" Moose or Mouse in the core. And they already exist on CPAN. I also don't think changing the OO system this late in the game is worthwhile. Nor do I think it's going to happen. Many people will say "yes". Much bikeshedding will go on. And noone will actually do it.
3. Python's ctypes.
Ah, yes, the old "XS is hard" argument. I can't argue with that. And it would be nice if someone invented something easier, and implemented it. Actually, someone already did, and called in Inline. Again, who's going to do the work?
4. Better CPAN integration.
Easier said then done. There's CPANPLUS and it took a lot of effort to get that integrated in the core. On the author side, there is Module::Build and a few other alternatives to Extutils.
5. mod_perlite
That seems to be an existing Apache module. What's the "need" for perl5?

Nicholas Clark is fond of saying "perl development is driven by people who haven an itch". Which basically means "something is only going to be added/changed if someone is motivated enough to do the work".

Perl5 isn't dead. And Perl5 won't die even if it doesn't implement any of the points mentioned by chromatic. 5.12 will happen. Probably even before perl6.

Replies are listed 'Best First'.
Re^2: Five Features Perl 5 Needs Now
by chromatic (Archbishop) on Dec 19, 2008 at 18:37 UTC
    But making a release is a lot of work.

    We've seemed to manage it 24 months in a row for Parrot.

    Much bikeshedding will go on. And noone will actually do it.

    I ported a proof-of-concept of roles to Perl 5 several years ago, and I wrote the class patch for Perl 5 last week.

    It would be nice if someone invented something easier, and implemented it. Actually, someone already did, and called in Inline. Again, who's going to do the work?

    I backported Parrot's solution as a proof-of-concept for Perl 5, again several years ago.

    What's the "need" for perl5?

    CGI is dead-ish, and mod_perl isn't easy to configure or deploy, and it's a lot of overkill for a shared-hosting account. Somehow mod_php has managed to make thousands of PHP apps as easy to install as "Drop this file in a directory." Isn't ease of deployment important?

    Nicholas Clark is fond of saying "perl development is driven by people who haven an itch". Which basically means "something is only going to be added/changed if someone is motivated enough to do the work".

    How much more code do I have to write to earn the right to make suggestions?

      Nicholas Clark is fond of saying "perl development is driven by people who haven an itch". Which basically means "something is only going to be added/changed if someone is motivated enough to do the work".
      s/do the work/maintain the work/

      Proofs of concept are easy(ish), patches are harder, maintaining features/modules in core is harder yet. There are a lot of great suggestions that seem to stall for lack of volunteer labor. Oh, well, that's life.

      I wish these kinds of threads could be more productive than this prototypical exchange:

      Tweedledee: X would be a cool feature! Tweedledum: X is hard/incompatible Tweedledee: but if X could be done, it would be great! Tweedledum: if you want X, then write the code Tweedledee: !?!

      Sometimes a wish list is just a wish list.

      Maybe the original article should have been titled "Five Features I Wish Someone Would Commit to Adding and Maintaining in Perl 5" -- but that doesn't exactly have the same ring. ;-)

      -xdg

      Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

        I deliberately chose the smallest, easiest syntax change which represented a useful feature, and the negative responses have been:

        • You can't add syntax to Perl 5. (Fine, now you have to use the feature pragma to enable it.)
        • It might break existing code which defines a class method featured in an indirect call on a bareword which passes a hash reference as its argument. (See the previous point.)
        • I don't understand how it's useful. (Fine, don't use it. I don't understand how the Perl 4-style package separator is still useful fourteen years, two months, and three days after the first release of Perl 5 which used a much better package separator.)
        • It doesn't do enough. (I thought small patches were easier to review, and I'm not interested in wasting my time writing a complete replacement of Perl 5's object system if I can't even get a simple dumb patch like this accepted.)
        • Moose hackers reserve the right to modify syntax and features to explore alternate approaches, and reportedly don't want old code to go stale in the core, if the Perl 5 release policy remains as it is. (Of course, I've only heard this secondhand and probably shouldn't include it in the list, but it is an objection I've heard. Remember though, that my patch represents the Perl 6 syntax which has remained stable for longer than Moose has existed. I helped design the Perl 6 object system.)
        • I prefer the existing syntax. (Then don't use it. It's optional. If you adamantly oppose adding new features to make a language easier to learn and to use, boy do you have the wrong language.)
        • You can already get the same syntax with a source filter, a CPAN module, a minilanguage written by hijacking and copying parts of Perl 5's tokenizer into an XS module. (Clearly this is a problem many people have wanted to solve. What's so bad about solving part of it once and for all for everyone?)

        It's no surprise there's a lack of volunteers lining up to add and maintain features for Perl 5. I'm motivated or stupid or gullible or stubborn enough to have patched Perl 5's parser and lexer twice this year. I don't mind doing hard work, but I'm not motivated or stupid or gullible or stubborn enough to waste my time if there's no chance my work will ever be used.

        Update: Rephrased the Moose comment to reflect reality more clearly.

Re^2: Five Features Perl 5 Needs Now
by jdporter (Canon) on Dec 19, 2008 at 18:15 UTC
    Easier said then done.

    That's true of all these things. Saying it adds no information.

    Perl5 isn't dead.

    Then why are you so down on the idea of adding significant features, such as the above, to Perl 5? You make it sound like it's too late. Like maybe p5p should only be concerned with bug fixes from here on? Don't forget that Perl 5 has been moving toward Perl 6 for some time now. Should that trend stop? You seem to think so.

    In any case, I think chromatic is in a pretty strong position to say what Perl needs now.

    Between the mind which plans and the hands which build, there must be a mediator... and this mediator must be the heart.
      Then why are you so down on the idea of adding significant features, such as the above, to Perl 5?
      I never said that. I don't think they are features that are needed now. Some of them are certainly nice. But perl5 will survive if they won't happen.

        OK, thanks for clarifying. I guess the question is what does "needed" mean. chromatic asked, How can the language stay relevant? and offered this list as an answer. So by disagreeing with him, you're saying that Perl 5 can remain relevant without these significant additions. It's a good question, and open to much debate, but as it stands, I tend to agree with those who say that stagnation = death. By some measures, Perl (5) already has one foot in the grave. Do we want it to become an undead zombie like COBOL? Do we want Perl (5) merely to survive, or to thrive and surpass?

        Between the mind which plans and the hands which build, there must be a mediator... and this mediator must be the heart.
Re^2: Five Features Perl 5 Needs Now
by xdg (Monsignor) on Dec 19, 2008 at 21:00 UTC
    Easier said then done. There's CPANPLUS and it took a lot of effort to get that integrated in the core. On the author side, there is Module::Build and a few other alternatives to Extutils.

    That wasn't his point. He was suggesting that the build/test/install cycle is kludgy. Which is one reason why there is PPM. Of course, someone has to build and maintain PPM files and the latest and greatest releases aren't always available. Which is why some people still want to build/test/install direct from CPAN. (c.f. Strawberry Perl.)

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

      The reason for PPM is that most Windows installations lack a C compiler plus the compiler that's used for the most spread Windows distribution of perl is not free.

        the compiler that's used for the most spread Windows distribution of perl is not free

        That's not quite true. The express edition is free (as in beer, at least) and works fine with ActiveState. (It just doesn't come automatically installed and configured like in Strawberry.)

        And just because PPM is useful on Windows doesn't mean it can't be used elsewhere to avoid build/test/install. I'm not saying one should, but I'm clarifying chromatic's point that the standard CPAN build/test/install cycle is kludgy and PPM is one example of an alternative.

        -xdg

        Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Re^2: Five Features Perl 5 Needs Now
by matze77 (Friar) on Dec 20, 2008 at 13:45 UTC

    Update: I cant see the forest for the trees ;-). But i like "say" its really better than "print $var, \n;", you know any simple new features which are good?

      I think this particular feature would clear the brush a bit, making it possible to actually see the trees.

      /J

Re^2: Five Features Perl 5 Needs Now
by Anonymous Monk on Dec 21, 2008 at 17:07 UTC
    Actually, someone already did, and called in Inline. Again, who's going to do the work?
    The exact equivalent is Win32::API/C::DynaLib, but they're broke/old/unmaintained.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://731534]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (4)
As of 2018-05-27 14:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?