Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

perl5 road map?

by xiaoyafeng (Chaplain)
on Mar 23, 2012 at 13:29 UTC ( #961209=perlquestion: print w/ replies, xml ) Need Help??
xiaoyafeng has asked for the wisdom of the Perl Monks concerning the following question:

Hi monks!

Today, I've read a great article here by Dave Rolsky. This is awesome article to describe the history of perl release, and I enjoyed reading.

But along with this reading, more confusion come into my mind, who leads perl5 develop? who determines if add X Y feature into perl5? For example:

  • does future perl has an optional type system for optimize other than runtime check?
  • when can we use a reliable, standard perl module for pre-compile?
  • built-in function signature and try::tiny?
  • can create 1000+ fast,light, reliable threads easily without any crash like erlang
  • etc etc.....
And here is a real problem. I deployed a program written in perl to many servers with perl5.12.2. But next month, perl 5.16 will be released, and as this 5.12 won't be supported soon. Do I need to upgrade my perl I installed even though new perl doesn't bring exciting features?

In nut shell My question is, where I can find perl5 road map to know its plan? are there a perl5 speakman/woman to clarify all questions about perl development? Is there a place to allow perl5 programmer voting for their favorite modules into core list? because this answer could help us to determine if upgrade my perl or not.

I searched on google and browse perl foundation but don't find any clue.

Please enlighten me, Thanks

update: Thanks ww, correct some language mistakes ;)





I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction

Comment on perl5 road map?
Re: perl5 road map?
by jdporter (Canon) on Mar 23, 2012 at 13:49 UTC
    who lead perl5 develop?

    Go to http://dev.perl.org/perl5/

    5.12 won't be supported soon

    I don't think you need to worry about that. 5.12 will continue to exist, and your programs written to 5.12 will continue to run just fine! How much "support" do you think you're getting for 5.12 now?

    Does I need to upgrade my perl

    Absolutely not. You may want to, in time, but you certainly don't have to. If your programs work great under 5.12, stay at 5.12.

    I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
Re: perl5 road map?
by moritz (Cardinal) on Mar 23, 2012 at 15:10 UTC
    who lead perl5 develop?

    The Perl 5 Pumpking, currently Alberto Simões Ricardo Signes. (thanks JavaFan for correcting that).

    who determine if add X Y feature into perl5?

    Well, you need three ingredients for that: somebody who implements it (including documentation and tests), the approval of a big part of p5p, and the approval of the pumpking.

    Jesse Vincent (the previous pumpking) has given some great talks on his future plans for Perl 5. Your search engine of choice will find them.

    There's also a perltodo file.

      The Perl 5 Pumpking, currently Alberto Simões
      Alberto was never a Perl pumpking. The current pumpking is Ricardo Signes.
        Ha! Schizm?
Re: perl5 road map?
by JavaFan (Canon) on Mar 23, 2012 at 16:11 UTC
    who lead perl5 develop?
    Noone in particular. There are a handful of a developers who do most of the work, and hence, by just doing the work, "lead" perl 5 development. And there's a pumpking, who may make decisions if decisions have to be made, and no consensus can be reached. He also will be the main person deciding what are "blockers" for a next release (but not the only one), and he's the person who keeps in touch with the release manager of the month. But the last the pumpkings aren't C programmers, and hence don't add much core features (nor solve bugs).
    who determine if add X Y feature into perl5?
    Mostly by the person actually implementing feature X Y. That's were it starts. If noone actually implements X Y, it does not get added. A feature may not be added if the p5p mailing list decides it either 1) breaks existing syntax, 2) is inefficient, 3) can be done with a CPAN module instead, 4) add too little value to compensate for the added complexity in the internals, 5) has the potential to be confusing, 6) is poorly designed, 7) some other reason. But noone is saying "this is what will be implemented".
    But next month, perl 5.16 will be released, and as this 5.12 won't be supported soon. Does I need to upgrade my perl I installed even though new perl doesn't bring exciting features?
    No. It just means it's unlikely that someone will release 5.12.5. 5.12.4 will not stop working. Now, it may be that 15 years from now, 5.12.4 no longer compiles out of the box, because you've upgraded your OS 17 times, and your C compiler is 5 major version further, but it seems unlikely you would upgrade your Perl in those cases. Now, just because it's unlikely 5.12.5 will be released, if someone is willing to do the work, some years from now, we may have a 5.12.17. And a 5.8.33. And perhaps a 1.0.22. But considering the people that actually do significant core work is very, very low, and they have shown no interest in maintaining 5.12 next to 5.16 and 5.14, I don't think 5.12.5 will happen.

    But again, a release of 5.16 does not mean people will come over to you in the middle of the night, demanding you to delete your 5.12 from your system.

    But next month, perl 5.16 will be released, and as this 5.12 won't be supported soon. Does I need to upgrade my perl I installed even though new perl doesn't bring exciting features?
    Which modules are included in the core isn't determined by vote. For a module to be included in the core, there has to be a good reason ("needed for the build process" is a good reason; "needed to bootstrap fetching and building from CPAN" is a good reason; "tightly tied to the core" (as in, will need a rewrite if the perl internals get reshuffled) is a good reason; and that's about it for good reasons).
Re: perl5 road map?
by BrowserUk (Pope) on Mar 23, 2012 at 16:26 UTC
    create 1000+ fast,light, reliable threads easily without any crash like erlang

    Perl's been able to do that for years:

    [16:20:43.22] C:\test>perl -mthreads=stack_size,4096 -mthreads::shared + -E"my $n:shared=0; async{{lock$n; ++$n;} sleep 1e3}->detach for 1..1e3 +; sleep 1 while threads::list > 1; say $n" 999 [16:20:44.72] C:\test>

    (Let's see your Erlang one-liner to do that in 1.5 seconds?)

    Of course, I cannot actually think of a valid use for it, but doing it is not a problem.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    The start of some sanity?

      How much time it will take if you add -MMoose I wonder? The thing is that in Erlang time and memory required to create a new process (it doesn't have threads) don't depend on what modules are loaded. At any time you can spawn several dozens of thousands of processes and it won't generally consume all available memory. Perl creates full copy of the interpreter for every thread, so you can't have too many of them, especially if you want to use something heavy in threads, like Moose. Don't pretend you don't know that.

      Comparison doesn't really make sense and one-liners are not a strong side of Erlang, but here's an example from Erlang Programming that creates 10000 processes (in the book they actually starting at 100000):

      -module(myring). -export([start/1, start_proc/2]). start(Num) -> start_proc(Num, self()). start_proc(0, Pid) -> Pid ! ok; start_proc(Num, Pid) -> NPid = spawn(?MODULE, start_proc, [Num-1, Pid]), NPid ! ok, receive ok -> ok end.

      And running it from the erl:

      3> timer:tc(myring,start,[10000]). {14283,ok}

      Time is in microseconds.

        The thing is that in Erlang ... create processes (it doesn't have threads)

        Sorry, but you are wrong. Erlang does use threads.

        • Firstly: Erlang processes are actually 'green threads'.

          That is, user-space execution contexts, running in shared memory space, managed by an custom-written, in-process scheduler.

        • Secondly: Since the release of R13B in 2006; as a result of the realisation that green threading didn't scale on modern hardware -- whether multi-processor SMP or multi-core SMP or a combination of the two -- Erlang now uses kernel threads internally, in order to achieve scalable concurrency.

          For a little more detail of the history and reasoning, please see one I prepared earlier.

          And see the Erlang development team paper: "Inside the Erlang VM: with focus on SMP. Prepared by Kenneth Lundin, Ericsson AB Presentation held at Erlang User Conference, Stockholm, November 13, 2008 ". (I linked to the PDF in the earlier reference.)

        here's an example from Erlang Programming that creates 10000 processes (in the book they actually starting at 100000):

        Yes. And the Go language proponents promote that it can do the same thing:

        package main import ("flag"; "fmt") var ngoroutine = flag.Int("n", 100000, "how many") func f(left, right chan int) { left <- 1 + <-right } func main() { flag.Parse(); leftmost := make(chan int); var left, right chan int = nil, leftmost; for i:= 0; i< *ngoroutine; i++ { left, right = right, make(chan int); go f(left, right); } right <- 0; // bang! x := <-leftmost; // wait for completion fmt.Println(x); // 100000 }

        The Mercedes CLK63 AMG Black has so much power that Jeremy Clarkson (Top Gear) managed to sustain a power-slide for so long that he completely destroyed a brand new pair of £1,000/pair rear tyres in about 10 minutes. It was spectacular to watch; and I bet it was fun to do; but as a measure of the utility of the vehicle, it is entirely pointless!

        And the same goes for both the Erlang and Go threading demos. They are entirely useless as demonstrations of anything practical or useful.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        The start of some sanity?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://961209]
Approved by davies
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (8)
As of 2014-07-23 07:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (135 votes), past polls