Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Five Features Perl 5 Needs Now

by Arunbear (Parson)
on Dec 19, 2008 at 11:35 UTC ( #731526=perlnews: print w/ replies, xml ) Need Help??

Not breaking news (I didn't notice it until today), but check out chromatic's thoughts on Five Features Perl 5 Needs Now.

Summary:
  1. Regular releases
  2. Moose, Mouse, and autobox.
  3. Python's ctypes.
  4. Better CPAN integration.
  5. mod_perlite

Enjoy!

Comment on Five Features Perl 5 Needs Now
Re: Five Features Perl 5 Needs Now
by moritz (Cardinal) on Dec 19, 2008 at 11:40 UTC
    It's also worth noting that chromatic also submitted a patch to p5p to introduce the class keyword, see for example here and many other recent threads on p5p.
      Yes, but Rafael doesn't like it as it's now, as it adds very little to perl - it just adds syntax. I can't say I disagree with that.
        What's wrong with adding "just syntax" for now?

        "Just syntax" is the difference between how you use the regex engine in Perl, and how you use it most other languages (where load a library, compile a pattern, and match it).

        "Just syntax" is often the difference between a feature that's used very often, and one that's mostly avoided.

        "Just syntax" is also what distinguishes Perl from most other languages, and Perl 6 from Lisp. (Ok, my last point about Perl 6 is not 100% serious, but you get the picture).

Re: Five Features Perl 5 Needs Now
by JavaFan (Canon) on Dec 19, 2008 at 12:41 UTC
    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.

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

      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.

      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

      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.
Two more Features Perl 5 Maybe Needs
by LanX (Canon) on Dec 20, 2008 at 13:27 UTC
    May I suggest two more possible improvements?

    6. Builtin easy aliasing of lexicals:

    something like:

    sub get_hash { my %h; ... ;return \%h} my (*h2)= get_hash(); #I'm not sure about the best syntax print keys %h2;
    such that beginners don't need to learn dereferencing straight away, just because they have nested data structures or want to return them from a sub.

    7. Introducing optional extra Sigils for Hashes and Arrays which behave like the sigils in perl6, that means representing the reference not the list!

    ¥hash{key1}{key2}=$hash{key1}{key2}; €arr1[0]=€arr2; # => €arr1[0][0] == €arr2[0]; push €arr1[0], "string"; # => pop €arr2 == "string";
    I know finding appropriate symbols in all charsets is complicated, but this could facilitate forward compability to perl6, if perl6 could then use these symbols as alternative aliases for @ and %.

    just ideas ...

    Cheers Rolf

      Yeah, those two things are surely necessary to keep Perl 5 relevant.
      </sarcasm>

        32,300 Results for "perl beginner problem nested arrays".

        </argument sarcasm=off>

      I most wholeheartedly agree with the 6., but do not see any need for the 7. The sigils we have are great, the system works and makes sense (and the change in the system of sigils is gonna cause a heluva lot of wasted time while seasoned Perl5 developers struggle to relearn sigils working the Perl6 way), but there is no need to complicate it any more. BTW, IMnsHO the changes to sigils and the concatenation and method call operators were both bad ideas.

      Besides, after a lot of thinking, I (hopefully correctly) inferred the intended meaning of the array examples, but still have no idea whatsoever what did you mean by the first line.

        The new sigils represent all references. The currency symbols are just other representations of $.

        So ¥hr={} means $hr={} and analogous with €ar=[] but the handling is easier.

        --- New --- Internally ¥hr == $hr ¥hr{k1} == $hr->{k1} ¥hr{k1}=¥hr2 == $hr->{k1} = $hr2 keys ¥hr == keys %$hr keys ¥hr{k1}{k2} == keys %{ $hr->{k1}{k2} } print €ar[1] == print $ar->[1] print @€ar[1] == print @{ $ar->[1] }
        hope that's clearer ...

        Tomorrow I'll try to hack a codefilter as a proof of concept.

        Actually if point 7 is realized, one don't really need point 6 any more ...

        sub foo { return ( [], {} ) } my (€ar,¥hr) = foo();

        But your right the first line was misleading! ... I got confused with the new idea of compability to perl6 syntax...but now I think that's far to complicated to achieve with the perl5 parser.

Re: Five Features Perl 5 Needs Now
by Jenda (Abbot) on Jan 16, 2009 at 02:06 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlnews [id://731526]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (9)
As of 2014-10-02 06:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    What is your favourite meta-syntactic variable name?














    Results (49 votes), past polls