Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^2: The current state of Perl6

by moritz (Cardinal)
on Apr 20, 2010 at 09:53 UTC ( #835748=note: print w/ replies, xml ) Need Help??


in reply to Re: The current state of Perl6
in thread The current state of Perl6

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.


Comment on Re^2: The current state of Perl6
Re^3: The current state of Perl6
by LanX (Canon) on Apr 20, 2010 at 10:54 UTC
    > > 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

Re^3: The current state of Perl6
by Anonymous Monk on Apr 23, 2010 at 11:05 UTC
    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.
        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.

        I see no aplicability for scale, speed or technical feasibility here since this project is not meant to be fast at this moment. Moritz mentioned earlier that Rakudo is 10^2 to 10^3 times slower than Perl5.

        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.

        Obviously there's no concern for money spent because this is a volunteer project as Moritz mentioned and Chromatic also mentioned this. And time is also not a problem since as they both mentioned they want to build something cool that has never been attempted before. So it doesn't matter how long this takes. Maybe forever, maybe never, maybe in 20 years. They want to build something that has never been attempted, it's like talking about the atomic bomb (except that at Los Alamos they trained hardcore physicists that were inventors, and they really knew what the hell they were doing and the government invested huge amounts of money in the project)

      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://835748]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (14)
As of 2014-08-27 23:00 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (253 votes), past polls