Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Re: Rakudo Star, Red Queen Edition

by raiph (Chaplain)
on Jan 24, 2012 at 05:05 UTC ( #949570=note: print w/replies, xml ) Need Help??

in reply to Rakudo Star, Red Queen Edition
in thread Hockey Sticks

chromatic, you have said yourself:

Rakudo Star is a useful and usable subset of Perl 6 you can use right now.

As I've consistently argued, it's up to you to decide what "useful" or "production" or "stable" mean.

At that time you had used Rakudo Star and seemed to accept the subjective definition of notions like "useful" and "production".

But I note that you introduced "stable". In the 2009 post announcing Rakudo Star Patrick himself explicitly focused on his discomfort with the moniker "stable", subjectively defined or not, in the context of Rakudo Star (let alone the in-development Rakudo compiler):

So, once we eliminate the notion of "finished", the wording is often changed to try to make it more tractable, often by asking when there will be a "stable release". ... part of me thinks "Huh? Those questions don't really fit with the way things really happen in language development... "
Rakudo Star is likely to be more stable than the plain Rakudo compiler, but it is clearly not something anyone should be building a business project on.
One year ago, in January 2010, Rakudo Star was unusable for my business projects.

Was Rakudo Star ever usable for your business projects?

While I'd objected to the nom fork-and-rewrite
Do you think your objection was influenced by the fact that Rakudo (Star or otherwise) was unusable for your business projects?
I decided against using whatever the "stable" branch of Star was at the time
There are no (non-master) branches of Star, "stable" or otherwise.
because it was also clear that it was a branch abandoned to bitrot
New quarterly Star releases were published in April and July, with 200 commits after the creation of the compiler nom branch in February. Given the nature of Rakudo Star as it was intended (not as a basis for business projects!) its treatment seems reasonable to me and not consistent with "abandoned to bitrot".
That means no bugfixes.
Check the commit log. I see bug fixes.
It's almost a year later, and nom isn't up to the point where its predecessor was. (It's ahead in some ways, but it's regressed in others. If you're claiming that Star provides stability, you don't regress.)
You're confusing the Rakudo compiler and Rakudo Star.

The Rakudo compiler appears to be far ahead of where it was a year ago in many regards, chiefly because of the nom branch, as one would expect.

Rakudo Star, which is a package including many things, has not yet switched to the nom version of the compiler, so it can not have regressed due to the nom branch. As made clear near the start of this comment, while Rakudo Star is said to be more stable than the plain compiler, the team explicitly avoided stability promises of the sort that someone doing a business project might require.

It is unfortunate that you misunderstood Rakudo Star's purpose and scope. I agree the team would be well advised to see if it can further clarify Rakudo Star's purpose and scope, and I will mention this on #perl6.

Replies are listed 'Best First'.
Re^2: Rakudo Star, Red Queen Edition
by chromatic (Archbishop) on Jan 24, 2012 at 07:40 UTC
    In the 2009 post announcing Rakudo Star Patrick himself explicitly focused on his discomfort with the moniker "stable"...

    I was in the room with him! His concern as I recall was in part due to the fact that he (and everyone, really) rightly expected that the specification would change. It has.

    If you read my posts, you'll find out that that's never been my concern.

    Please do us both the courtesy of reading my posts.

      OK. I assume you didn't mean your posts in this Meditation. (I've carefully read all of those, but I think that was obvious.) So I just went and explored the 25 matches to a google for " rakudo star". This seemed an appropriate best effort response to your request. Maybe this wasn't what you meant; if so I'd appreciate an elaboration of "my posts" or better still some specific URLs or quotes.

      The only posts of the 25 saying something substantive relevant to this exchange were Why My Side Project Doesn't Use Perl 6 and In Search of Minimum Viable Utility. I'd read both of those before.

      Imo your link to "my list of requirements to use Rakudo for practical purposes" in the earlier post is the most revealing element. I don't think Rakudo Star was intended to meet those sorts of requirements. I plan to ask Patrick if he thinks Rakudo Star was, should be, or will ever be, about trying to meet those sorts of requirements. If he chooses to answer, I'll post back here to update.

        Update. I screwed up in this chat. chromatic explains that I completely misrepresented his position. See this post for the details.

        Patrick Michaud (a leading dev of Rakudo, a leading Perl 6 compiler) was kind enough to provide his response to chromatic's "list of requirements to use Rakudo for practical purposes" inasmuch as they applied/apply to Rakudo Star.

        I've edited out some stuff I consider unnecessary. Here's what's left:

        <pmichaud> #1 (work on future releases)  Rakudo Star was intended to support that to the degree that the Perl 6 language would support it.  If the language changes significantly, there's not much Rakudo can do about that short of providing some sort of release cycle for code migration

        <pmichaud> #2  (tied to one release)  I think that question is more about other implementations than Star itself; but no, Star has never been intended to be its own walled garden of Perl 6

        <raiph> #1 but what about regressions due to other factors?

        <pmichaud> Star was intended to avoid regressions, yes; but it didn't work out that way.

        <pmichaud> I think jnthn++ (and I) really underestimated the degree of regression that would be involved.  But I'm not sure it could've been helped either.

        <pmichaud> The alternative would have been to not release any form of Star at all, I think.

        <pmichaud> #3 (library guarantees of reliability)   Yes, we were hoping to provide a stable platform for library development.

        <pmichaud> #4 (stuck on cycle of monthly upgrades)  Star was explicitly intended to enable people to break the cycle of monthly upgrades, by providing standard checkpoints.

        <pmichaud> Again, there were some problems there, but not entirely Rakudo/Star's fault (Parrot made some significant changes that we had to react to and that caused some babysitting)

        <pmichaud> #5 (abandon code due to compiler rewrite)  I can't say what Star intended here.  We wanted to have a more consistent platform, yes; but again, much of the changes in the new implementation were due to language requirements and not a capricious "oh let's rewrite the compiler again"

        <raiph> chromatic summarizes that he said in dec 2010 "don't do nom, not needed, will take too long".

        <pmichaud> I disagree with the "not needed part", vehemently.  We had to rewrite the object model.

        <pmichaud> What we had in Star at the time was completely inadequate for long-term growth.

        <pmichaud> And the politics of the time meant that there wasn't a way to get crucial object model changes into Parrot in a timely fashion.

        <pmichaud> it's been a hot-button issue for him, certainly.  I have a great deal of respect for chromatic, and generally agree with him in most respects, but this has always been a place where we've had to agree to disagree.

        <pmichaud> I don't think he's wrong about the negative impacts of doing nom; I just don't see what we could have done differently.

        <raiph> right. so here's a key thing: would you say the rakudo project committed to anything?

        <pmichaud> we committed to getting some form of official release in July 2010, and have a regular release cycle after that.

        <pmichaud> But Star was never intended to be the end product, no.  It was the next stage of development.

        <pmichaud> (we didn't necessarily plan on a full compiler rewrite, but that's effectively what ended up happening.  Again, it was what made sense at the time)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://949570]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2018-06-19 04:01 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (111 votes). Check out past polls.