Perl 6: Managing breakages across Rakudo Star versions

(Update: Moritz pointed out to me that the subject of this discussion was supposed to be Rakudo Star, a packaging of a Rakudo compiler version, modules, docs, and so on, not the monthly Rakudo compiler release. I've changed the title and some of the details to address this.)

Patrick Michaud, Rakudo lead dev, wants to know what Perl 6 stability policy should be. Or at least, how you would like to see the Rakudo team manage breakages across versions of Rakudo Star in the near term.

Discuss on the perl6 compiler list or the #perl6 IRC channel on freenode.

Comment on Perl 6: Managing breakages across Rakudo Star versions

Replies are listed 'Best First'.
Re: Perl 6: Managing breakages across Rakudo versions by Anonymous Monk on Jul 17, 2012 at 08:59 UTC
I don't get it. I always thought that Rakudo or any other Perl 6 implementation is currently in a stage where they would like to break things and continue that until they announce a release that will remain compatible with any release further. In fact I thought that was explicit goal of Perl 6 to break compatibility once and once only and fix as much as its possible with that jump. Besides if this is not supposed to be a production release then why even bother? Because until you announce one, you always have the luxury to experiment, break, fix and add new stuff till as much as you can. Or should we take this is as an Indication that a Production release is imminent in the very near future and a support policy is being drafted for it?	[reply]
Re^2: Perl 6: Managing breakages across Rakudo versions by jdporter (Paladin) on Jul 17, 2012 at 10:32 UTC
Concur 100%. Until there's a production release, who gaff what the stability policy is? At this stage of the game, you shouldn't be thinking about stability at all.	[reply]
Re^3: Perl 6: Managing breakages across Rakudo versions by moritz (Cardinal) on Jul 17, 2012 at 10:49 UTC
Our users think otherwise, and we do need users. Perl 6 - the future is here, just unevenly distributed	[reply]
Re^4: Perl 6: Managing breakages across Rakudo versions by Anonymous Monk on Jul 17, 2012 at 11:10 UTC
Re^5: Perl 6: Managing breakages across Rakudo versions by moritz (Cardinal) on Jul 17, 2012 at 11:35 UTC
Some notes below your chosen depth have not been shown here
Re^4: Perl 6: Managing breakages across Rakudo versions by jdporter (Paladin) on Jul 17, 2012 at 12:30 UTC
Re^5: Perl 6: Managing breakages across Rakudo versions by moritz (Cardinal) on Jul 17, 2012 at 12:58 UTC
Re^2: Perl 6: Managing breakages across Rakudo versions by raiph (Deacon) on Jul 17, 2012 at 19:19 UTC
I thought that was an explicit goal of Perl 6 to break compatibility once and once only Yes. if this is not supposed to be a production release then why even bother? Imagine you were managing the Rakudo release process. There are already Rakudo users and some are using it in production settings. Would you completely ignore their desire for management of breakages just because you aren't ready to make the sort of compatability promises Perl 5 makes? Further, imagine that you thought there was a good chance you could ship a release in 2013 explicitly announced as suitable for deployment in production settings. Would you prefer to wait until after that release has been shipped before starting to discuss and develop a framework for handling breakages? Would you discuss it 3 months prior to your estimated final ship date? 6 months? Would you do anything to support users who are writing or distributing Perl 6 modules? Bridges to other libraries, especially CPAN, are very important. What about supporting those who are interested in completing those bridges? The Perl 6 spec includes versioning features (for both modules and the compiler). But they are not yet implemented. Would you ignore interim measures in the hope that those features get implemented in the next few weeks? Or should we take this is as an Indication that a Production release is imminent in the very near future and a support policy is being drafted for it? If by "very near future" you mean this year, I think there's about zero chance of that. But I've been watching Perl 6 closely for 12 years, and to me it's obvious why some folk have begun to deploy Perl 6 in production settings (it's already sufficiently attractive, despite some big problems~~, most notably weak documentation and lack of stability~~.). cf Larry Wall's recent comment about productizing Perl 6.	[reply]
Re^3: Perl 6: Managing breakages across Rakudo versions by chromatic (Archbishop) on Jul 17, 2012 at 19:31 UTC
I'm all for Rakudo improving the experience of deploying and maintaining serious code, but it's disingenuous to hand-wave away any differences between "some people are doing this with it and they don't mind babysitting their code between releases" and "you should take this seriously because it's ready for deployment like any other mature piece of software you might expect". I've been burned before. Rhetorical flourishes and linguistic contortions to redefine away objections won't convince me that I can ship a project built in Rakudo to paying customers (without losing money on support) because people have good intentions now, or Larry wrote a message somewhere. When the Rakudo developers meet the commitments they've made and demonstrate that they can continue to meet those commitments, I'll take ~~them~~those commitments seriously. Edit to add: I mean that last paragraph sincerely. I believe everyone involved is acting in good faith. All I mean is that I'm not going to be an early adopter.	[reply]
Re^4: Perl 6: Managing breakages across Rakudo versions by raiph (Deacon) on Jul 17, 2012 at 20:36 UTC
Re^5: Perl 6: Managing breakages across Rakudo versions by Anonymous Monk on Jul 18, 2012 at 08:56 UTC
Some notes below your chosen depth have not been shown here
Re^3: Perl 6: Managing breakages across Rakudo versions by Anonymous Monk on Jul 18, 2012 at 04:55 UTC
Dear Lord!!! You've taken Larry's comment totally out of context, I don't think he means there will be a compiler product two or three years from now. He is just saying there are somethings that need to be done in an year or two to make Perl 6 productized in the future Secondly for a minute I cannot imagine any serious person using a non backwards compatible language in production settings. I would seriously doubt credibility of such a business. I think you are referring to IRC bots and Rosetta code wiki submitters, which in case their use cases hardly count for production settings. Rakudo doesn't have serious users. Nor people who wish to learn it to do useful stuff. That is why backwards compatible release is so important, to bring that seriousness back.	[reply]
Re^4: Perl 6: Managing breakages across Rakudo versions by raiph (Deacon) on Jul 18, 2012 at 22:48 UTC
Re^5: Perl 6: Managing breakages across Rakudo versions by Anonymous Monk on Jul 19, 2012 at 04:07 UTC
Some notes below your chosen depth have not been shown here
Re: Perl 6: Managing breakages across Rakudo versions by sundialsvc4 (Abbot) on Jul 17, 2012 at 13:23 UTC
Let me be frank: please stop calling this thing “Perl 6.” Call it Rakudo ... present it as a new language. (With a sexy trendy name. Do the whole faux-Ninja thing, to appeal to the twenty-three year olds among us who still love spending all day and all night hacking software.) `;-)` This is IMHO a much better positioning of this project at this point in time, and not a criticism of the effort or its extreme lateness. In support of this notion, I offer these points three: If it’s source-code compatible with Perl, it’s not better, and it is now at cross-purposes with itself. The internal complexity of the system shoots up, and stability goes down. Various other projects, including `ADD 1 TO COBOL GIVING COBOL.`, have encountered this issue before. You really can’t change an existing language that much and call it the same language. If it’s not source-code compatible, then “it is a different language,” and everything of significance is going to have to be ported, so the CPAN library effectively splits. Very well, then: let it split, and do it cleanly. There is a mammoth installed-base of Perl5. These installations consist not only of the interpreter executable, but also the CPAN libraries. The possibly major changes to these libraries which might be attempted in order to accommodate Rakudo might well de-stabilize them, causing significant business problems for installations which have no interest in adopting Rakudo at this time. If Rakduo, called Rakudo, is deployed in a parallel but separate track, the cost/benefit analysis holds up. If, instead, it disrupts existing installations in any way, it produces cost without benefit. Perl has a history now. It has a legacy to support. Once again, this is not a flame; this is a Meditation. I invite equally cordial comments; not just +/- votes. What do you think in response to my comment, and why or why not?
Re^2: Perl 6: Managing breakages across Rakudo versions by chromatic (Archbishop) on Jul 17, 2012 at 17:00 UTC
What do you think in response to my comment, and why or why not? I think every time it comes up, Larry says no.	[reply]
Re^3: Perl 6: Managing breakages across Rakudo versions by jdporter (Paladin) on Jul 17, 2012 at 17:16 UTC
Yay for community. Yay for open source software.	[reply]
Re^4: Perl 6: Managing breakages across Rakudo versions by chromatic (Archbishop) on Jul 17, 2012 at 19:07 UTC
Re^5: Perl 6: Managing breakages across Rakudo versions by jdporter (Paladin) on Jul 17, 2012 at 19:18 UTC
Some notes below your chosen depth have not been shown here
Re^2: Perl 6: Managing breakages across Rakudo versions by raiph (Deacon) on Jul 18, 2012 at 02:29 UTC
please stop calling this thing �Perl 6.� I'm torn on this. I know I'd be delighted and relieved if Larry decided it was wise to rename. But Larry seems to be steadfast in his veto over renaming his latest version of his language. I've been a marketing professional, and the negative aspects of Perl 6's reputation bug me big time. However, in the years since I began thinking a renaming would theoretically be the right thing to do, I've never been fully persuaded it's actually the right thing to do. One thing to bear in mind is the decadal view. I have absolutely zero doubt that, in ten years, Perl 6, or whatever it is called, will be considered a member of the Perl family, and a natural heir for most users to what is currently called Perl 5. Ultimately, I trust Larry's instincts on the decision more than my own instincts, or marketing theory, or popular opinion. So, some almost certainly futile bikeshedding... I assume you accept the familial resemblance, even if you don't accept more than that. Akin to, say, C and C++ and C#. So maybe PerlVI, Perl++, or somesuch? (I'm pretty confident Larry would have an especially negative reaction to Perl++ due to association with C++.) Maybe P6rl, with use of unicode to make the 6 small, like an upside down reflected "e"?	[reply]
Re^3: Perl 6: Managing breakages across Rakudo versions by Anonymous Monk on Jul 18, 2012 at 03:12 UTC
Maybe P6rl, with use of unicode to make the 6 small, like an upside down reflected "e"? How about a symbol, like the artist formerly known as prince?	[reply]
Re^4: Perl 6: Managing breakages across Rakudo versions by raiph (Deacon) on Jul 18, 2012 at 23:23 UTC
Re^5: Perl 6: Managing breakages across Rakudo versions by Anonymous Monk on Jul 19, 2012 at 01:59 UTC
Some notes below your chosen depth have not been shown here
Re^2: Perl 6: Managing breakages across Rakudo versions by sundialsvc4 (Abbot) on Jul 18, 2012 at 15:42 UTC
Heh... and why, exactly, should anyone in this case particularly care “what Larry Wall thinks?” “Ooops!” he said, looking fearfully straight ahead and wondering what it will feel like to become a pillar of salt ... A few hundred million source-code lines ago, the Perl language ... having not yet achieved(!) the viability that it has achieved now ... had many options to become viable. But, once it did, it suddenly became the case that the financial(!) value of what has been made using Perl, and put into daily service, vastly outweighs the ($0.00 ...) cost of Perl itself. At this point, what matters is that those mission-critical applications keep running. No one is asking to rewrite them; no one is in a particular hurry to spend the millions of dollars and to risk the business instability that could occur by doing so. There is no benefit; there is considerable cost; there is one hundred percent risk. Therefore, I would frankly argue that the best thing that could be done for this Perl-6 project, if (and I now consider it to be a very big “if” ...) it ever actually sees the light of day and if, having done so, it actually proves itself to be a viable product. Being tapped as the successor of a noble ancestor, by anyone at all for any reason at all, does not guarantee or validate success. The evil spirit replied, “I know Jesus, and I know Paul, but who are you?” -- Acts 19:15b; New Living Translation This is “nothing personal” and “everything practical.” There is no place for a “Perl 6” because that multi-million real-dollar place is already taken by the system that is in service. Any successor project will forever stand beside Perl-5 and must not in any way whatever jeopardize it ... most specifically, there must be zero impact to the mission-critical parts of CPAN.
Re^3: Perl 6: Managing breakages across Rakudo versions by chromatic (Archbishop) on Jul 19, 2012 at 17:40 UTC
Heh... and why, exactly, should anyone in this case particularly care �what Larry Wall thinks?� He created and leads the project. ... most specifically, there must be zero impact to the mission-critical parts of CPAN. I like the DBI. I don't miss sybperl.	[reply]
Re: Perl 6: Managing breakages across Rakudo versions by raiph (Deacon) on Jul 29, 2012 at 19:03 UTC
(updated to use code tag instead of pre tag per message from jdporter) An update: The rakudo.org compiler release announcement for July 2012 is out. It includes this section that reflects what this meditation was (supposed to be) about: Starting with this release, we will also identify changes to the imple +mentation or specification that can cause breakages in existing Perl +6 code. The following features have been deprecated or modified due t +o changes in the Perl 6 specification, and are being removed or chang +ed as follows: * IO::File and IO::Dir will go away, and &dir now returns values of ty +pe IO::Path (which is currently the superclass of IO::File and IO::Di +r). The return values of &dir will still stringify to the base name o +f the returned file and directory names, and you can call .path on th +em to obtain the full path. * Leading whitespace in rules and under :sigspace will no longer be co +nverted to <.ws>. For existing regexes that expect this conversion, a +dd a <?> in front of leading whitespace to make it meta again. Schedu +led for the 2012.08 release. * The ?-quantifier on captures in regexes currently binds the capture +slot to a List containing either zero or one Match objects; i.e., it +is equivalent to � 0..1″. In the future, the ?-quantifier wil +l bind the slot directly to a captured Match or to Nil. Existing code + can manage the transition by changing existing ?-quantifiers to use +� 0..1″, which will continue to return a List of matches. Sch +eduled for the 2012.08 release, but may end up in 2012.09 . * The method Str.bytes will be removed. To get the number of codepoint +s in a string, use .codes instead. To get the number of bytes in a gi +ven encoding, use $str.encode($encoding).bytes . Scheduled for the 20 +12.08 release. * The method Str.lcfirst will be removed without replacement. Schedule +d for the 2012.08 release. * The method Str.ucfirst will eventually be removed, and replaced by S +tr.tc. No schedule yet, depends on having tc implemented first. * �abs� is currently a prefix operator, and will be changed to a norma +l subroutine. Scheduled for the 2012.08 release. * The integer argument to IO::Socket.recv will be interpreted as numbe +r of characters/codepoints. Scheduled for the 2012.08 release. [download] Constructive feedback would probably best be directed to the #perl6 IRC channel on freenode, or the p6c mailing list.	[reply] [d/l]

Back to Meditations