There has been requests and talk of a production release for years now. Fancy 
titles released have come out monthly and quarterly for some time. At some 
point you have to say it simply isn't a good product or it is going to 
production how long are we going to hear excuses of my dog died past week and 
the production release is delayed for a year. Perl 6 at this point seems like a 
bad dream at best and there really isn't a need since moose and perl 5 have 

Sent from my iPhone
Wendell Hatcher

On Jan 5, 2011, at 6:13 AM, "Anderson, Jim" <> 

> Hear! Hear!
> -----Original Message-----
> From: Daniel Carrera [] 
> Sent: Wednesday, January 05, 2011 7:15 AM
> To: Richard Hainsworth
> Cc:
> Subject: Re: Production Release - was Re: Questions for Survey about Perl
> 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
> <> 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.
> ----------------------------------------------------------------------
> This message w/attachments (message) is intended solely for the use of the 
> intended recipient(s) and may contain information that is privileged, 
> confidential or proprietary. If you are not an intended recipient, please 
> notify the sender, and then please delete and destroy all copies and 
> attachments, and be advised that any review or dissemination of, or the 
> taking of any action in reliance on, the information contained in or attached 
> to this message is prohibited. 
> Unless specifically indicated, this message is not an offer to sell or a 
> solicitation of any investment products or other financial product or 
> service, an official confirmation of any transaction, or an official 
> statement of Sender. Subject to applicable law, Sender may intercept, 
> monitor, review and retain e-communications (EC) traveling through its 
> networks/systems and may produce any such EC to regulators, law enforcement, 
> in litigation and as required by law. 
> The laws of the country of each sender/recipient may impact the handling of 
> EC, and EC may be archived, supervised and produced in countries other than 
> the country in which you are located. This message cannot be guaranteed to be 
> secure or free of errors or viruses. 
> References to "Sender" are references to any subsidiary of Bank of America 
> Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are 
> Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a 
> Condition to Any Banking Service or Activity * Are Not Insured by Any Federal 
> Government Agency. Attachments that are part of this EC may have additional 
> important disclosures and disclaimers, which you should read. This message is 
> subject to terms available at the following link: 
> By messaging with Sender you 
> consent to the foregoing.

Reply via email to