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)

Comment on
Re^5: The current state of Perl6
Replies are listed 'Best First'.

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?

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.

yes I would completely omit those. because I'm not sure how rewarding it would be after 5 more years of Perl 6 coding to see that the time spent proves to be worthless.

The idea is, let the people who have money to invest and spend in stuff like Haskell and Java compilers experiment all they want, learn from their mistakes (which you cannot possibly reproduce in a useful timeframe with a handful of people who are developing today on Perl6) and use what you've learned so far in your compiler.

Since it is year 2010 I doubt that each and every feature of what you mentioned is novel. Actually, I'm sure it has been implemented in some compiler somewhere. The Perl6 team needs to find all of those and see how succesful they have been without the effort of implementing them. This is all a question of time, if you waste the precious time on useless things the failure will be of epic proportions.