I think the success criteria on http://dev.perl.org/pm/pos.html
should be more measurable.
> SUCCESS CRITERIA
> 1.Benchmarks of text processing programs show improved performance on
perl6 over perl5.
Yes, but how much improved? Is 50% in everyone's minds, or is 10%
enough? How much improvement is feasible?
> 5.The internals API is simpler than in perl5.
I have no suggestions on how to measure this. I think it needs to
say more, though. I haven't been following -internals, but I'd like
to hear some of their feedback on how much simpler it's going to get.
Also some comments on the risks listed on this page:
> RISKS
> 1.perl5 is adequate for peoples' needs, and nobody wants to change to
perl6.
If Damian Conway keeps throwing out these modules like Switch.pm
that show his RFCs can happen in Perl5, and if you guys get your way
with this prototyping thing, we may all feel this way in a few months.
(Okay, probably not.)
> 2.We can't agree on features to remove or add.
Mitigated by Larry Wall. If feedback to Larry's design is
appropriately limited, we should be able to slowly extricate ourselves
from the brainstorming phase and move into consensus.
> 3.We don't have enough implementation programmers to finish the
> interpreter.
Keep this one in, but I don't think it will be a problem.
Programming is actually the easy part; I'm afraid we won't have enough
designers and so on to give the programmers enough to do quickly
enough (the "thinker-throughers" are more expensive than the
programmers).
> 4.We produce a slower interpreter.
This is a very definite concern, and we need to come up with ways to
mitigate this risk quickly. As Fred Brooks says, "Performance
Simulator. Better have one. ... Start it very early. Listen to it
when it speaks." I propose that the QA group be charged with the
responsibility of seeing to it that Perl6 is not slower than Perl5.
They should take care of setting up some benchmark tests, and solicit
volunteers to run those benchmarks weekly/monthly/whatever during the
implementation phase.
It is very easy to create something that is unacceptably slow and
not realize until toward the end of the process.
J. David
