Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re^3: The current state of Perl6

by Anonymous Monk
on Apr 23, 2010 at 11:05 UTC ( #836496=note: print w/ replies, xml ) Need Help??


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

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.


Comment on Re^3: The current state of Perl6
Re^4: The current state of Perl6
by BrowserUk (Pope) on Apr 23, 2010 at 11:35 UTC
    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)

        I see no aplicability for scale, speed or technical feasibility here

        If the Mahattan Project had use Waterfall, it would never have started, because you cannot specify that which you do not know how to do. Or even know if it is possible; eg. its technical feasibility.

        You have to experiment (prototype), and feed what you learn back into the spec, and use it to choose the direction of your next level of experiment. Waterfall doesn't allow that. Waterfall is useless. Period.

        Just in case, as seems likely from your rather incoherent post, you've misunderstood my post to which you replied, I was supporting the P6 cabal against the notion that they should have finished the spec before starting implementation.

        And to put this firmly into the world of reality rather than speculative theory, here are a couple of unknowns from the more tentative parts of the P6 spec, that simply cannot be answered. Neither from the existing knowledge within the designers/programmers heads, nor from the existing research literature:

        • What is the likely net affect upon application code efficiency, of multiple user-space, cooperative concurrency schedulers, interacting with the kernel space pre-emptive scheduler?
        • Can Software Transactional Memory be successfully and efficiently implemented in an on-the-fly compile & interpret environment?

          Ie. Outside of the auspices of the deep analysis available to compile-to-native code, strongly & statically typed, pure functional language compilers.

        Whilst both those concepts are named in the Parrot/Perl6 specifications, they are, as yet, absent from the implementations, because there are no answers to those questions in the existing body of knowledge.

        One can speculate on the basis of knowledge of existing similar concepts, but until someone actually tries to implement them, and use them in a real-world environment, all such speculation is just that, and nothing more.

        As such, Waterfall's only answer to these parts of the requirements, would be to omit them completely from the specification.


        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.
Re^4: The current state of Perl6
by JavaFan (Canon) on Apr 26, 2010 at 13:32 UTC
    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://836496]
help
Chatterbox?
and the web crawler heard nothing...

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

    My preferred Perl binaries come from:














    Results (159 votes), past polls