So I'd change that to "after a production release of a Perl 6 compiler"
Out of curiosity (because I think it will illuminate some of the difficulty
Rakudo devs have in declaring something to be a "production release"):
- What constitues a "production release"?
- What was the first production release of Perl 4?
- What was the first production release of Perl 5?
- What was the first production release of Linux?
- At what point was each of the above declared a "production release";
was it concurrent with the release, or some time afterwards?
Pm
Larry responded to a post of mine asking about when Perl6 would be
finished - the post was about the time that Pugs was still being
actively developed. He pointed to the difference between the waterfall
model and the strange attractor model for software development, perl6
progress being measured using the strange attractor model.
Many of the questions and answers about a 'production release' imply the
waterfall model. The concept here is that some one 'in authority' sets
criteria which define 'finished'. Once the software / language / project
fulfils the criteria - the edge of the waterfall - it is 'finished'.
This has the advantage that everyone knows when to break out the
champaign and have a party. It has the disadvantage that criteria of
'finished' can rarely be written in advance because to do so requires
precognition, or knowledge of the future. Is there any sophisticated
piece of software that is 'perfect', has no bugs, is easy to use? Was MS
Vista 'production' quality? Perl 5.0 was quickly replaced by Perl 5.004
(I think), which include references.
The strange attractor model implies a process that is never ending, in
that there will always be deviations from the solution 'orbit' or
'path'. However, there comes a time when for most normal purposes, the
solution orbit will be so 'narrow' that the blips will be not be noticed
for most situations.
In this respect, qualitative statements such as 'when developers accept
it' or 'providers such as ActiveState etc' bundle it are recognition of
the strange attractor measure of progress of Perl6.
Personally, I think that we are in sight of acceptance for Rakudo Star.
This is an implementation of a subset of Perl6. I also believe that when
Rakudo begins to implement Sets, Macros and deals with the problems
posed by GUI, we will see further changes in the Perl6 specification. It
is unlikely that such changes will 'break' Rakudo *.
A question that would be useful to ask is:
When will Rakudo Star be useful for some of your purposes?
a) It is already useful;
b) When running precompiled Rakudo * versions for a test suite of
example programs is as fast as running Perl5 versions, on average.
c) When running (from human readable text to final result) Rakudo *
versions for a test suite of example programs is as fast as Perl5
versions, on average.
d) When Rakudo * implements a larger subset of Perl6 and/or access
well-written C/C++ libraries efficiently, presupposing (c).
Another question would be what should be in the test suite of example
programs?
The example programs are not the test suite, which verifies consistency
with the specification. The example programs should be designed - I
suggest - to test speed and memory footprint. Ultimately, programmers
are interested in solutions that are quick and use least hardware
resources (the human resource of writing a simple and understandable
program being the strongest part of Perl6, at least I think so).
