Although everything you said is technically true, I must point out
that without a definitive release, potential users will tend to avoid
the software. For people not involved in the process (i.e. 99.995% of
Perl users) it is impossible to know when the software is good enough
for use. You may talk about strange attractors and orbits, but I
haven't the faintest clue how big the "orbit" of either Perl 6 or
Rakudo is. Therefore, I cannot recommend it to other people, and I
will hesitate to use it on anything that is very important.

Daniel.


On Wed, Jan 5, 2011 at 12:38 PM, Richard Hainsworth
<rich...@rusrating.ru> wrote:
>
>>>> 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).
>
>
>



-- 
No trees were destroyed in the generation of this email. However, a
large number of electrons were severely inconvenienced.

Reply via email to