Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re: The current state of Perl6

by BrowserUk (Pope)
on Apr 20, 2010 at 05:01 UTC ( #835651=note: print w/ replies, xml ) Need Help??


in reply to The current state of Perl6

The questions I'd like to see an answer to--were we allowed to ask them--are:

  • Can any current implementation of Perl6 do everything that Perl5 can do without extensions and modules?
  • If not, what is missing? And why? (That is: what is the limitation preventing it.)
  • How's the current performance?

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.


Comment on Re: The current state of Perl6
Re^2: The current state of Perl6
by Anonymous Monk on Apr 20, 2010 at 06:13 UTC
    I think lack of contributors is the limitation they have currently.
      he specifically asked what features Perl5 has that Perl6 doesn't yet. he didn't ask for the cause it doesn't have them. many contributors with small time-slices are probably not going to make a lot of progress IMHO
        Questions about the current percentage of spec coverage can be answered only by the developers who are working on it. Or probably testers.

        But why was the pugs project abandoned? Why did Rakudo developers start from the scratch when something like pugs was already available to build upon?
Re^2: The current state of Perl6
by moritz (Cardinal) on Apr 20, 2010 at 09:53 UTC

    Thank you for asking a sane, answerable and non-FUD question in this thread :-)

    I can only talk about Rakudo, but I'm quite sure it's the most usable compiler these days.

    Can any current implementation of Perl6 do everything that Perl5 can do without extensions and modules? If not, what is missing?

    No. Rakudo mostly lacks IO to be a proper superset, as well as concurrency.

    And why? (That is: what is the limitation preventing it.)

    For IO: priorities, spec uncertainties, and a champion.

    Rakudo development so far has focused mainly on language features, and a few contributors that are too scared to hack the guts (like me) have filled in many built-in functions. But with IO it's not that easy, because you have to interact with parrot in scary ways (or so it seem to me). The specification for IO stuff is currently in the weird state of being both over engineered in some areas, and under engineered in others. So it would take somebody with quite some experience to implement the sane parts, adapt the spec where it's insane, and expand it where necessary.

    Concurrency support mostly blocks on parrot, which doesn't expose threads to HLLs in a usable way (has a few blocking bugs, and has had them for quite some time). Still there is hope: We've received a quite good google summer of code proposal to fix up threading. Nothing is decided yet, but I have hopes that it will be funded.

    How's the current performance?

    Bad. You should expect Rakudo programs to run 100 up to 1000 times slower than comparable perl 5 progreams.

    Perl 6 - links to (nearly) everything that is Perl 6.
      > > How's the current performance?

      > Bad. You should expect Rakudo programs to run 100 up to 1000 times slower than comparable perl 5 progreams.

      Did you mean "prog-dreams"? ;-)

      My 2 to this discussion:

      The most interesting parts of the Perl6 project were:

    • a JIT compiler tuning the execution nearer to C-speed
    • an orthogonal redesign allowing much easier language extensions in the future, while Perl5 is stuck in a byzantine labyrinth of patches and patches of patches.

      Unfortunately for most of the messages I read from the Perl6 team, I have to admit:

      I'm really sorry, but I don't understand... 8-(

      Cheers Rolf

      Rakudo mostly lacks IO to be a proper superset, as well as concurrency.

      Why don't you people get the spec finished before starting to implement anything ?

      If you write code while not having a finished spec you're probably writing code that will get deleted on further revisions of the spec so you're basically wasting time.

      So why don't the people with a good CS background in the Perl6 team just meet up and finish the spec and then you can start implementing ?

      I think (although old) the waterfall methodology of developing software is the best one. Agile is really not good, except for teams of people who really have to rush to get something done(crappy, real-world software), but it is not the case with Perl6 if you say you want to write something good, there should be no hurry involved, just finish the spec already so you can get to the next phases.

        I think (although old) the waterfall methodology of developing software is the best one.

        Sorry, but you just outed yourself as not having a clue. The waterfall methodology was never any good.

        Just maybe, if the designer is (re)designing his 4th or 5th data entry system, (or other simple, linear flow, data in-process-results out system), and the project is small enough that one person can envisage and retain the entire systems flow in their head. Then, just maybe.

        But for anything that involves leading edge development, or more than one man can keep in his head at one time, waterfall is useless. And the cause of many billions of wasted £/$/¥ over the past 40 years.

        Waterfall lives up to its name: once you're over the edge, there is no way but down. The smallest change in requirements; or misinterpretation of those requirements; or miscalculation regarding scale, speed, or technical feasibility; and the end result is a dog of a system that condemns your users to perpetual pain; your programmers to constant make-do; or the project to cancellation. Or all three.


        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.
        Why don't you people get the spec finished before starting to implement anything ?
        The best way to test a spec to see if it actually makes any sense is to (try to) implement them. It's only after you've spend a lot of energy implementing something that you realize there's a much better (for some value of 'better') way!
        If you write code while not having a finished spec you're probably writing code that will get deleted on further revisions of the spec so you're basically wasting time.
        Not really. Image you're in a fork of the road. You don't know which path to take. You turn right. It's a dead-end. You return to the fork in the road. Have you wasted time? After all, you're not any closer to your target. It may look so, but you've gained valuable knowledge - you now know which road not to take. Wasn't it Knuth who wrote that after you've finished a program, it's time to throw it all away, and start over again, using the gained knowledge to write something better?

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (8)
As of 2014-08-22 21:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (167 votes), past polls