|laziness, impatience, and hubris|
Re: Hockey Sticksby Anonymous Monk
|on Jan 18, 2012 at 03:52 UTC||Need Help??|
So what is the conclusion at the end of this, "Perl 6 is still not ready".
Sorry to be playing the bad guy part here, but measuring the progress of a project by measuring number of tests it passes, is very similar to measuring the progress of a project by lines of code.Unless you have uniformly distributed the test cases across feature sets. Test cases are probably a measure of stability not progress.
Now lets come to what would actually constitute progress in Perl 6's case. At this time feature set with an acceptable performance will do. We need not have to ensure Rakudo or Niecza runs on a million virtual machines at this moment, Frankly that's the last thing any body wants. A full feature set implemented with decent performance will do.
Most Perl 6 people say, Perl 6 specification is just like any other language, evolving always. That is true, but you must also know those other languages have 'stable' compiler releases. You are all welcome to try your experiments. But make a production release with a feature complete release. Then incrementally evolve your spec and continue your experiments in the period of two stable releases. I believe this is how all projects are run. They have a aim, once that is met then comes the 'next step'.
Now Perl 6 project has become like the dichotomy paradox(http://en.wikipedia.org/wiki/Zeno's_paradoxes).
That which is in locomotion must arrive at the half-way stage before it arrives at the goal.
This is what is happening. In order to finish you need milestones. You need to plan and work towards those milestones within a time frame. Instead what you are doing is dividing a milestone into many milestones, and those milestones into further many milestones. So ultimately you never hit the original milestones because you now have some many several sub/sub-sub milestones in which you get lost and never go and achieve the original milestone as planned.
While working on a project, Instead of completing the feature set in the project you find some interesting thing that can bring your in x% performance gains. You leave the feature set aside and go in its pursuit. Then you realize while making the x% performance gain, you can add something to the compiler that can bring some thing which enables it to run on multiples VM's. Now you go into the VM thing. While doing that you figure out, you figure out another thing which can help a native call interface.
You have totally lost the sight of the goal by now. You have so many sub tasks to chase within a small milestone. That you can humanly never scale and come out of it. Since the original milestone never completes, you don't go to the next milestone. Since you don't go the next, you don't go the next after it and so on and so forth...
Ultimately you never reach your goal.