Perl 6 aliasing specification

I should have opened this before an alias was chosen. But I think it's still not too late.

We should specify the details on how the alias(Raku) is going to be used. On the website, docs, conferences and everywhere else. And also clarify it for users how they should and shouldn't be using it.

Also we need to decide on ways the users are going to find the programming language via searching "Raku". Are we going to mention Raku on important places on the website so that perl6.org will show up when they search "Raku"? Or are we going to have a dedicated website for Raku(As was mentioned on IRC before)? If so is it going to simply redirect to the Perl 6 web pages or is it going to somehow show the same content but Raku instead of Perl 6? Or both?

I thing we should clarify everything as much as we can to remove people's confusion.

NOTE: Please don't use this issue for showing your protest against the aliasing, use it only for the reason it was created for.

There won't be a consensus on this, so I think you should specify the metrics that show when a decision is deemed to have been reached.

I'd love for Larry to write a clarificatory blog post on all of these points.

From https://colabti.org/irclogger/irclogger_log/perl6?date=2018-11-06#l1350

\ pmurias: and I don't remember the wording of what I said on leaving it for 3-8 months, but my point was is we let the users and 3rd party outlets use the alias to judge how successful it is and organically see how much it should be used in official channels instead of trying to inorganically force its use into everything.

\ Zoffix: waiting to see if Raku pick ups before using it in official channels would work too

\ pmurias: I'm +1 on that. I know I've included "Raku Perl 6" on release brochure, but as I mentioned it earlier, I felt that was required because of the 1.5yr plan to finalize the decision on whether we'll have the alias and not having it in there would leave that question unanswered. I also added "Raku" to the Glossary. I think that's more than sufficient for right now.

\ Ideally, TimToady would write a detailed blog post describing the appropriate uses of the alias.

I must admit to being a bit bewildered by the proposal in the article by @lizmat — "the proposal" meaning what comes after the section, Where do we go from here.

If I'm reading correctly, it says all references of Raku alongside Perl 6 should be removed, and instead content should be duplicated (automatically, where possible, but in cases like on Stack Exchange sites, in the worst possible human-redundant-effort way) merely with each name presented separately.

Is that a correct reading? If so, what's the gain over Larry saying "request denied"? If there is none, then this is a bad-faith suggestion—mitigation that makes things worse isn't really mitigation.

The argument leading up to it, then following the same recommendations, would seem to recommend that every Bob Dylan album be available with the name "Bob Dylan" scrubbed from album art and track listings and replaced with "Robert Allen Zimmerman", but the two names should not appear together anywhere. A Clark Kent/Superman sort of weirdness. This seems also an action with no net gain.

Let me just add, this doesn't seem to be all that different a problem except in historicity from the language developed by Google and promoted at golang.org.

"Go" was already used for other things, including a very common English word, and so the alias "golang" became common for searching. On the web, "Go" is an essentially useless search, but "Golang" is an extremely well-targeted one.

Similarly, right now I have to search ("Perl 6" OR "Perl6" OR ("p6" and "Perl") OR "Rukudo") to get anything that has a good chance of avoiding being totally washed out by Perl 5 results. This feels untenable to me. If Perl 5 were going to wind down and be supplanted with Perl 6 running Perl 5 code in backwards-compatibility mode as fast or faster than the old runtime—as I believe in 2002 was the intention—this would be "growing pains". But since Perl 6 is not going to replace Perl 5, this is just friction, period, like trying to search and/or write about a language called "The". Or "Go".

@lizmat's argument is actually annoyingly logical. To avoid the negative associations with Perl, the names must not be well associated in any way. We who like Perl may still call it Perl 6, while those with a negative opinion of Perl must not be exposed to the connection until they can overcome their preconceptions.

I say "annoyingly" because following the logic will create a lot of work and some unavoidable confusion. Alas, if we could be put off by just the amount of work, Perl 6 would never have become reality at all.

There won't be a consensus on this, so I think you should specify the metrics that show when a decision is deemed to have been reached.

I really don't know, I'm hoping we can figure everything out by identifying the issues and solutions regarding the aliasing. But some things probably will be easier to know if the solution will work or not, for example if a solution fixes the "Raku" search problem.

A general categorization of the problems:

Internal
- Perl 6 domain
- What needs to be done on the website, docs, etc if any
- If Raku will be mentioned in some places, is there a need for guidelines for contributors on how to handle it?
- Raku domain
- Does it need a domain name?
- Will the website be only redirecting to perl6.org?
- Will have its own content or use content from perl6.org,...
- Will have everything perl6.org has or just the important things(e.g. docs)
External
- Users: users or even non-users will do whatever they want, but what is going to be suggested to them? The same thing that was mentioned in the brochure or something else?
- Stackoverflow: see this
- Conferences: I'm only mentioning this because there was an issue with a conference
- Other things people can think of(for example websites, wikis, ... mentioning Perl 6)

I think it should be either "Raku" or "Perl 6" not "Raku Perl 6".

Maybe I should add the raku executable to the list?

@niner I agree the proposal is logical. But it isn't pragmatic, which has always been this community's first cultural touchstone.

If the actions that must be "logically" taken by following the determination made by @TimToady to bless the handle "Raku" is worse than his not having done so, then we need to look past simple logic to pragmatism, since he clearly doesn't intend to make a strictly-worse decision than no decision at all. We need to assume good faith from all members of the community.

It's @TimToady's job to reconcile pragmatism with logic if that's necessary—but the pragmatic interpretation always comes first.

@treyharris: fwiw, that's why I ultimately think we should not have an alias. Because it is not pragmatic. But now that @TimToady has made up his mind that it's ok to have an alias, this implies to me that we have to be pragmatic about that as well. And that's where I think pragmatic and logical actually meet.

@lizmat I'm sorry... I remain confused, but that may be that I'm fundamentally misunderstanding your proposal. It was clear to me from the preamble of your post that you were opposed to the alias, but the remainder of your proposal didn't read to me like an attempt to make the best pragmatic use of the alias, but rather a way to undermine it—and, inadvertently or not, do damage even to members of the community who totally eschewed the alias. It read to me like a bad faith proposal—which I'm convinced means I don't understand it, as I've never known you to be someone to act in anything but good faith.

Hm, let me try to give a couple very concrete examples and you can tell me where I've gone wrong:

We'd presumably have two entire websites of virtually identical documentation but for a global search-and-replace of the language's name vs. alias (and any tools or utilities that descended from the handle-in-use) and a reskinning. But wouldn't that:
1. Result in general confusion about which is canonical
2. Have the issue seen by many forked projects that attempt to port upstream changes when the name is changed where nonsensical changes are made by global search-and-replace and must be each special-cased, e.g.:
  - If all Perl6::(.*) modules were not dually-released as Raku::$0, then references to them would have to be special-cased; worse, if some were dually-released and some not (based, perhaps, on the whims of the authors), even the special casing would have to have special cases;
  - Munging of meta-commentary could result in nonsense like "Rakudo is an implementation of the Raku (a.k.a. Raku or Raku) language" from original "Rakudo is an implementation of the Perl 6 (a.k.a. Perl6 or Raku) language"—this was an ongoing and neverending problem in Info text and docstrings when XEmacs forked from Emacs.
3. Less importantly—but still IMO importantly!—this is practically a prescription for search-engine pessimization; sites that are meaty but largely reduplicative of another site are heavily penalized in rankings. This would penalize sites using the alias more, but would penalize sites using the original too.
On sites like Stack Exchange, without tag aliasing the very same question would get asked about both the alias and the original name. The result would usually be that whichever question was asked second, regardless of its use of the alias or original, will get closed as a duplicate and linked to the first—an untenable ongoing situation that would eventually result in Stack Exchange's bureaucracy ignoring whatever the Perl 6 community's preference is, and either synonyming the two handles or banning one of them.

If these two situations wouldn't result by your proposal, could you explain why?

Or, if I do have a proper grasp on the results, can you explain why it's a good thing? If it isn't, on balance, good, then it isn't pragmatic—no matter how logical it may be. Better to make no proposal and see what organically develops, than to make a proposal that has mostly negative results.

On 15 Nov 2018, at 19:01, Trey Harris notifications@github.com wrote: @lizmat I'm sorry... I remain confused, but that may be that I'm fundamentally misunderstanding your proposal.

I assume you mean the things I proposed under "Where do we go from here” ?

It was clear to me from the preamble of your post that you were opposed to the alias

I have always been opposed to an alias, or a rename for that matter. But Larry has decided that an alias is ok, so I’m trying to work with that.

, but the remainder of your proposal didn't read to me like an attempt to make the best pragmatic use of the alias, but rather a way to undermine it—and, inadvertently or not, do damage even to members of the community who totally eschewed the alias.

I must be too autistic how I damaged members of the community that want to avoid the alias. Am I missing some meaning in “eschewed” here?

It read like bad faith proposal—which I'm convinced means I don't understand it, as I've never known you to be someone to act in anything but good faith.

Thank you. It was not intended as a bad-faith proposal, but as a genuine way forward. Much like you have Linux distributions that market Linux under the name of Red Hat, Suse, etc.

Hm, let me try to give a couple very concrete examples and you can tell me where I've gone wrong:

• We'd presumably have two entire websites of virtually identical documentation but for a global search-and-replace of the language's name vs. alias (and any tools or utilities that descended from the handle-in-use) and a reskinning. But wouldn't that: • Result in general confusion about which is canonical

For Raku users, the raku website would be canonical, for Perl 6 users the Perl 6 site. In my view, Raku would be like a Rakudo Star, so depending on a Rakudo Compiler release, but otherwise free in what it adds to the distribution. It’s always been the idea that Rakudo Star would be the first user distribution, with anybody free to create other ones. So it is in line with that.

  • Have the issue seen by many forked projects that attempt to port upstream changes when the name is changed where nonsensical changes are made by global search-and-replace and must be each special-cased, e.g.:
      • If all Perl6::(.*) modules were not dually-released as Raku::$0, then references to them would have to be special-cased; worse, if some were dually-released and some not (for example, "core" vs. "non-core"), even the special casing would have to have special cases;

FWIW, I didn’t say it would be easy, or practical. But if people want to have a non-Perl related alias, than that is what needs to be done, in my opinion.

      • Munging of meta-commentary could result in nonsense like "Rakudo is an implementation of the Raku (a.k.a. Raku or Raku) language" from original "Rakudo is an implementation of the Perl 6 (a.k.a. Perl6 or Raku) language"—this was an ongoing and neverending problem in Info text and docstrings when XEmacs forked from Emacs.

Well, I look at it this way: we have a language that has text munging as one of its specialities. It’s not like it needs to be performant; I don’t envision live translation of documentation, so it could be done once when there is a new Raku release done.

  • Less importantly—but still IMO importantly!—this is practically a prescription for search-engine pessimization; sites that are meaty but largely reduplicative of another site are heavily descored in rankings. This would penalize sites using the alias more, but would penalize sites using the original too.

I think the docs.perl6.org site is updated continuously, whereas any docs.raku.something site would only get updated once for a release. So I agree that could be an issue, but one of the sites would be continuously changed, whereas the other at most once a month (or once every 3 months or so).

• On sites like Stack Exchange, without tag aliasing the very same question would get asked about both the alias and the original name. The result would usually be that whichever question was asked second, regardless of its use of the alias or original, will get closed as a duplicate and linked to the first—an untenable ongoing situation that would eventually result in Stack Exchange's bureaucracy ignoring whatever the Perl 6 community's preference is, and either synonyming the two handles or banning one of them. If these two situations wouldn't result by your proposal, could you explain why?

No, they would. The argument was made that if someone is deep enough into the language already to be asking questions, it should be clear that the underlying language is in fact Perl 6. So it would be ok to only allow questions about Perl 6 on SO (or have questions marked “raku” automatically also marked “perl6”.

Or, if I do have a proper grasp on the results, can you explain why it's a good thing? If it isn't, on balance, good, then it isn't pragmatic—no matter how logical it may be.

To me, the pragmatic solution would be to not have an alias. But that ship apparently has sailed. The main reason for the alias was to get away from the “Perl” name. Using “Raku Perl 6” then makes no sense at all, and can be seen as a “rebranding” attempt. I don’t think “rebranding” was on Larry’s mind when he decided on the alias “raku”.

Better to make no proposal and see what organically develops, than to make a proposal that has mostly negative results.

The proposal is already there, and I’m not going to remove my blog post, if that’s what you’re suggesting. I’ve said what I wanted to say about the proposal. I will not talk about it any further, unless someone asks me questions about it (like now).

To me, the pragmatic solution would be to not have an alias. But that ship apparently has sailed. The main reason for the alias was to get away from the “Perl” name. Using “Raku Perl 6” then makes no sense at all, and can be seen as a “rebranding” attempt. I don’t think “rebranding” was on Larry’s mind when he decided on the alias “raku”.

Better to make no proposal and see what organically develops, than to make a proposal that has mostly negative results.

The proposal is already there, and I’m not going to remove my blog post, if that’s what you’re suggesting. I’ve said what I wanted to say about the proposal. I will not talk about it any further, unless someone asks me questions about it (like now).

@lizmat Understood. I appreciate your comments and thank you for answering my questions.

I wasn't suggesting you remove the blog post; perhaps "better to follow no pre-defined plan such as your proposal at all and see what organically develops" rather than "better to make no proposal" would have carried my sentiment better.

I won't try to get into a back-and-forth here when you've said you will not talk about it any further. Ordinarily I'd follow-up by asking a few questions about what you just wrote, but given your wishes, I'll just make some declarative statements that might sound a bit stronger than I actually feel because I don't have that benefit of additional input on your feelings here:

My take is that your proposal (by which, I did mean the section of your blog post after "Where do we go from here") does seem like a case of "making a point" — in the sense probably best captured by Wikipedia's contributor behavioral guideline WP:POINT ("Do not disrupt Wikipedia to illustrate a point") — namely that, were the community to follow your proposal, it would be, on balance, worse off.

Dealing with the additional friction of redundant effort and constant reconciliation of documents and code, difficulties in searching the web for software and answers, the penalizing of sites in search-engine rankings because there will be many near-duplicate sites and pages, the oddness of having the "perl6-" mailing lists that clearly deal with issues of interest to both "Perl 6" and "Raku" (even for issues where there is no distinction except naming between them) split in twain, and confusion on the part of casual members of our community and newcomers — these are all bad effects.

The main positive effects, I think, are

A clarity on how the name and alias are to be used (i.e., never together);
A potential morale boost for those who would rather the alias name not exist, by being able to avoid it as much as possible; and
A chance for the idea "Perl 6 is an entirely new language that should be judged separately from Perl 5" to still get friction (though the addition of a new word that will never be used simultaneously with "Perl 6" for the same language seems to make this less likely to me)

The fact that you did not suggest even these positive effects in your blog post, though, I think is significant—you seem to believe Larry's decision is so wrong-headed that there is no salvaging it (in the sense of coming up with a way forward that isn't worse for everyone).

While clarity is a greatly desirable thing—especially when, as you so correctly noted, one "simple line on IRC can wreak so much havoc"—it isn't so desirable as to counterbalance the negatives, I don't believe.

This point-making is a cousin of "bad faith" but isn't, exactly—to you, this proposal might illustrate the problems you see and/or the absurdity of Larry's decision well enough so that @TimToady would reverse his decision. (That's the sort of thing I would have asked you if you had not said you wouldn't discuss further.)

If that's the case, that's basically an argument in form of reductio ad absurdum, but differs from it by being presented in form of a sincerely-proposed solution in response to the decision, rather than being framed as a necessary but unfortunate result of the decision.

The issue here is that, as a community with a benevolent (and, we hope, wise) leader, we shouldn't do that. If we disagree strongly with a decision, we have a responsibility to raise ideas to mitigate the bad effects of that decision and not to undermine the decision with ideas that will make the situation ~~worth~~ worse.

We also should not engage in so-called "malicious compliance" — where, in carrying out a decision we disagreed with, we fail to raise issues or potentially unforeseen negative consequences so that the rest of the community (including the decision-maker and those who agree with it) can suggest mitigations, but instead push forward with actions that make the overall situation worse (perhaps in the malfeasant belief that "that'll teach them", the misfiseant one of "they wouldn't care, anyway", or the nonfeasant one of "they should've seen this coming", or even the more beneficent "I'll trust blindly that this will somehow work out").

Another possibility is that you see this as a sort of divorce—the "Perl 6 community" will, as a result of this decision, eventually include only those who eschew the alias. (By "eschew", I mean "do not introduce it in new usage"; it's a superset of those who disagree with Larry's decision but remain in the community, plus those who agree with or have no position on Larry's decision but choose not to introduce the word in new usage themselves. Presumably, it also includes Larry himself even if he chooses to introduce "Raku" into new usage, but the fact that he probably needs to be special-cased may indicate a problem here.) Those who use the alias will move into a new "Raku community". (There may be people who belong to both, and again, presumably that would include Larry himself, but such dual-citizens will either be duplicating effort, or work on liaisons and interfacing between the two for things like releasing and porting.)

Were such a divorce to happen, then your proposal could very well be the cleanest way to achieve this. But I don't believe that was Larry's intention, nor the intention of anyone in favor of an alias prior to his decision. (I had no position on the matter, personally, so I imagine I'd be one of the dual-citizens in this case, though being in that dual-citizenship category seems like a nuisance.)

I know @zoffixznet wasn't intending a schism of the community in the earliest suggestions of an alias — that was made explicit. And one can assume @TimToady was not intending a schism, either. One can further assume—regardless of whether or not @zoffixznet had the best interests in mind for the entire community or just that subsection that was benefited by the problems an alias addresses—that @TimToady did make his decision with the best in mind for the entire community.

So I think it's up to the rest of us to essentially stop re-arguing the decision that has been made, accept it as a given, and work together to come up with concrete solutions forward that make for the best end results for all. For those who were opposed, that may mean "mitigation" — but it has to be true mitigation that results in a better outcome for the whole community, not help for those who eschew the alias and harm for those who use it (or vice versa, for proponents of the alias), and especially not false mitigation that would result in harm for everyone; if we don't have an idea that can do that, then I'd say we should wait to see what others come up with. (Again, I'm not suggesting you take down your blog post. I'm just saying that, based on what you've said about it, I'm not sure that more examples like it would be helpful at this juncture.)

At this point, "now is the time for all good [people] to come to the aid of the [community]."

@treyharris: food for thought. I will re-read it tomorrow morning and have more feedback then.

On 15 Nov 2018, at 21:46, Trey Harris notifications@github.com wrote:

The proposal is already there, and I’m not going to remove my blog post, if that’s what you’re suggesting. I’ve said what I wanted to say about the proposal. I will not talk about it any further, unless someone asks me questions about it (like now). @lizmat Understood. I appreciate your comments and thank you for answering my questions. I won't try to get into a back-and-forth here when you've said you will not talk about it any further. Ordinarily I'd follow-up by asking a few questions about what you just wrote, but given your wishes

"unless someone asks me questions”. I merely wanted to indicate that I will not take the initiative. Please ask all you want. Achieving clarity about everybody’s position is a must to come to a sound decision.

My take is that your proposal (by which, I did mean the section of your blog post after "Where do we go from here") does seem like a case of "making a point" — in the sense probably best captured by Wikipedia's contributor behavioral guideline WP:POINT ("Do not disrupt Wikipedia to illustrate a point") — namely that, were the community to follow your proposal, it would be, on balance, worse off.

I don’t feel it that way. If anything, to me it feels that people wanting another name for Perl 6 are “making a point" according to that definition.

Dealing with the additional friction of redundant effort and constant reconciliation of documents and code, difficulties in searching the web for software and answers, the penalizing of sites in search-engine rankings because there will be many near-duplicate sites and pages, the oddness of having the "perl6-" mailing lists that clearly deal with issues of interest to both "Perl 6" and "Raku" (even for issues where there is no distinction except naming between them) split in twain, and confusion on the part of casual members of our community and newcomers — these are all bad effects.

I agree to a point. But, apart maybe from search engines, the confusion on the part of casual members and newcomers won’t be much different with “Raku Perl 6”.

The fact that you did not suggest even these positive effects in your blog post, though, I think is significant—you seem to believe Larry's decision is so wrong-headed that there is no salvaging it (in the sense of coming up with a way forward that isn't worse for everyone).

Sorry, to me these positive effects were self-evident. Thank you for emphasizing them.

And no, I don’t think Larry’s decision is wrong-headed. I do think that Perl 6 deserves a chance by getting away from the bad reputation that Perl (5) has. About 10 years ago, I was very much in favour of giving Perl 6 a different name. Larry decided that there was not going to be a name change. And I followed that decision. And did my best to make “Perl 6” a success. And that has been a lot of work, both technically as well as in marketing. And now when finally “Perl” is starting to get a less negative connotation in the world, we’re about to throw all of that away.

While clarity is a greatly desirable thing—especially when, as you so correctly noted, one "simple line on IRC can wreak so much havoc"—it isn't so desirable as to counterbalance the negatives, I don't believe.

This point-making is a cousin of "bad faith" but isn't, exactly—to you, this proposal might illustrate the problems you see and/or the absurdity of Larry's decision well enough so that @TimToady would reverse his decision. (That's the sort of thing I would have asked you if you had not said you wouldn't discuss further.)

I don’t see a question here. I didn’t say I didn’t want to discuss anything. I said that I won’t take the initiative anymore.

If that's the case, that's basically an argument in form of reductio ad absurdum, but differs from it by being presented in form of a sincerely-proposed solution in response to the decision, rather than being framed as a necessary but unfortunate result of the decision.

Not sure whether this an answer to your question, but let me state my opinion on several decisions Larry can take:

Larry would revoke the idea of an alias I would welcome that very much.
Larry states that the alias should be used for a different Rakudo Star like distribution I would also welcome that, as it will give Perl 6 a better chance in the markets where Perl is a dirty word.
Larry states that is ok to use “Raku Perl 6” in all places where “Perl 6” is used I would not like that at all, and would be reason enough for me to reconsider my involvement with this project.
Larry states that “Perl 6” should be called “Raku” from now on. I would feel betrayed and it will most likely mean I will be no longer involved in the project.

I think there is nothing new in these statements as far as my opinion goes.

The issue here is that, as a community with a benevolent (and, we hope, wise) leader, we shouldn't do that. If we disagree strongly with a decision, we have a responsibility to raise ideas to mitigate the bad effects of that decision and not to undermine the decision with ideas that will make the situation worth.

I assume you mean s/worth/worse/ here. As far as I know, I’m the only one raising ideas about this situation so far. I welcome other ideas. Please point me to other ideas if I missed them.

We also should not engage in so-called "malicious compliance" — where, in carrying out a decision we disagreed with, we fail to raise issues or potentially unforeseen negative consequences so that the rest of the community (including the decision-maker and those who agree with it) can suggest mitigations, but instead push forward with actions that make the overall situation worse (perhaps in the malfeasant belief that "that'll teach them", the misfiseant one of "they wouldn't care, anyway", or the nonfeasant one of "they should've seen this coming", or even the more beneficent "I'll trust blindly that this will somehow work out”).

Let me put it this way: in my professional career, which you could argue had 4 stages, I’ve always left the project as soon as it was clear to me that I couldn’t express my opinion and/or was not taking seriously anymore. When I work on a project, I give it my 150%. If I can’t do that, I’m out, because then it becomes work. And you could argue that I’ve never worked in my life, but always have been able to do things that are (generally) fun. So yes, I’m spoilt rotten in that sense.

Another possibility is that you see this as a sort of divorce—the "Perl 6 community" will, as a result of this decision, eventually include only those who eschew the alias. (By "eschew", I mean "do not introduce it in new usage"; it's a superset of those who disagree with Larry's decision but remain in the community, plus those who agree with or have no position on Larry's decision but choose not to introduce the word in new usage themselves. Presumably, it also includes Larry himself even if he chooses to introduce "Raku" into new usage, but the fact that he probably needs to be special-cased may indicate a problem here.) Those who use the alias will move into a new "Raku community". (There may be people who belong to both, and again, presumably that would include Larry himself, but such dual-citizens will either be duplicating effort, or work on liaisons and interfacing between the two for things like releasing and porting.)

Were such a divorce to happen, then your proposal could very well be the cleanest way to achieve this. But I don't believe that was Larry's intention, nor the intention of anyone in favor of an alias prior to his decision. (I had no position on the matter, personally, so I imagine I'd be one of the dual-citizens in this case, though being in that dual-citizenship category seems like a nuisance.)

I agree, it’s not pragmatic. Pragmatic would have been to not have an alias, but simply use the implementation name “Rakudo” in markets that find Perl to be a dirty word. In fact, if the alias were “Rakudo” instead of “Raku”, the problem would be a lot less, as we’re already using that for quite some time now. And this is even what @zoffixznet proposed in 2017!

I know @zoffixznet wasn't intending a schism of the community in the earliest suggestions of an alias — that was made explicit. And one can assume @TimToady was not intending a schism, either. One can further assume that—regardless of whether or not @zoffixznet had the best interests in mind for the entire community or just that subsection that was benefited by the problems an alias addresses—that @TimToady did make his decision with the best in mind for the entire community.

So I think it's up to the rest of us to essentially stop re-arguing the decision that has been made, accept it as a given, and work together to come up with concrete solutions forward that make for the best end results for all. For those who were opposed, that may mean "mitigation" — but it has to be true mitigation that results in a better outcome for the whole community, not help for those who eschew the alias and harm for those who use it (or vice versa, for proponents of the alias), and especially not false mitigation that would result in harm for everyone; if we don't have an idea that can do that, then I'd say we should wait to see what others come up with. (Again, I'm not suggesting you take down your blog post. I'm just saying that, based on what you've said about it, I'm not sure that more examples like it would be helpful at this juncture.)

As I said before, I won’t take the initiative.

At this point, "now is the time for all good [people] to come to the aid of the [community]."

Which I have been since late 1999.

To finish off, I would like to state some facts of the past year:

my open letter on Perl.com was the 4th best visited page ever in the history of Perl.com, even though at the time it had only been online for less than 6 months (from a presentation by David Farrell at TPCiSLC).
my Perl 5 -> Perl 6 articles on opensource.com have been tweeted to more than 100K people, and have (apart from some comments about minor Perl 6isms in Perl 5) been very well received.
my “on Raku” article has the highest score (about 2.5x more than the next highest score) on /r/perl6 for at least the past year, if not longer, and an 87% upvote.

So I don’t feel like I’m the only one with this opinion in the Perl community.

So I don’t feel like I’m the only one with this opinion in the Perl community.

Count me in. And as I said before, I would very much regret you or Wendy leaving Perl6.

Fritz

I hear the strong emotions that the "alias" has evoked - and I recognise the underlying passions. I really appreciate the contributions people have made. Let's keep it being O(fun).

Personally I favour using "raku" not as an alias for "Perl 6" but as a sub-brand of Perl.

To use Apple as an example:

"iphone" is a sub-brand of Apple "ipad" is a sub-brand of Apple too

People refer to "Apple ipad" or "ipad" interchangeably.

All of these brand names: "Apple", "iphone" and "ipad" happily coexist.

Apple's sub-branding strategy means:

Apple lawyers are clear what they're protecting [1]
Apple marketeers are clear which product they're promoting
Apple customers are clear what they search for / buy / recommend

"raku perl" or "perl raku" or just "raku" seems like natural, pragmatic ways of describing a particular flavour of Perl. It means we can be clear within the community which flavour of Perl we're referring too. It means we can be clear externally too.

It will help if Perl 5 gains a sub-brand too and I've started collecting sub-brands for Perl 5 [2]. So far the feedback has been positive.

Let's use "raku" as a sub-brand of Perl not an alias. A sub-branding strategy means we can share our "Perl" heritage while giving space for sub-brands to flourish.

I hope Larry and the Perl Foundation can adopt a sub-branding strategy and we can all move forward under the Perl umbrella.

Please take this suggestion in the spirit it's intended - a desire to help all Perl languages, projects and conferences succeed.

[1] the Artistic License 2.0 refers to trade marks associated with the copyright work [2] Perl Branding Proposal

We already have subbrands, they are called ‚5‘ and ‚6‘. I really hate that people are wasting their strength on this bikeshedding! 😪

I think plenty of people are overthinking the whole idea, reaching overblown conclusions, and then start to freak out about it. For example, I've seen people mock the supposed Raku file extensions, even though no plans ever existed to modify file extensions.

Not sure whether this an answer to your question, but let me state my opinion on several decisions Larry can take:

I think that's forcing the alias into use (or dis-use) instead of following the original idea that the creation of the alias is essentially a testing ground for how much influence the "Perl 6" name has. Larry's involvement was in choosing the alias, so that we put to rest all of the "how about $name" discussions.

Going further from that point, we let the community's use of the alias be a metric for the naming issue and several months in the future, when we have sufficient data to make an evaluation, we can see if any of the core resources need to include the alias. Thus, if no one uses the alias, we forget it. If everyone uses the alias, we include it copiously in the core resources.

IMO, trying to make Larry dictate how we must use the alias by force robs us of that valuable, organic information on alias's viability and it will end up with us either blindly pushing through with a failed idea or not capitalizing on its potential if it is a success.

use “Raku Perl 6” in all places where “Perl 6” is used

As a clarificatory point: the combined use of "Raku Perl 6" is supposed to be a rarity. If alias is sucesful and we decide to proliferate its use in core documents, the "Raku Perl 6" combination will essentially be for use in contested places where either of the names can be used, but we have only a single instance of the resource to use it in.

Elsewhere, Wendy stated that all the effort to promote Perl 6 is ruined by the alias. That's not the case. All the venues receptive of the "Perl 6" name would still use "Perl 6" and not "Raku" or "Raku Perl 6".

As for the point made about creating Raku as a separate, rebranded distribution of Perl 6. Yes, having that separation is a better idea than the alias, the problem is all in its implementation, however. Even with current resources, such as Rakudo Star, we're short-staffed and there's simply not enough resources to create and maintain a distribution on a much larger scale that also includes modified docs, websites, and support channels.

In addition, personally I have a large list of things I don't like in the Perl 6 language and I think should be removed. Were I to go through the huge amount of effort to create and maintain Raku as a separate distribution, it would only make sense for me to make language modifications I desire as well.

And from that point, you're basically forking the original language and dragging a part of the community that likes your changes along with you. I'm against this split.

Full disclosure: I don't quite understand the attachment to particular names—I've been on the boards of two nonprofits that, for legal reasons, were forced to change names quite abruptly. It's annoying, always creates a period of havoc and bikeshedding, and you can feel like you lost some PR in the renaming. But these are just nuisances that can be pushed through.

And, on the other hand, the renaming is an opportunity for free press and awareness in the larger community that normal PR moves can rarely replicate. And that's just when the name is changed for no intrinsic reason (like a legal dispute). This isn't a name change, it's an alias addition, but it has purpose—so the coverage of it can be a way to get out the message "this is a very different language and you should put aside any misgivings about Perl 5" into news outlets and generate awareness.

A statement like "if the name were changed, I would leave" is incomprehensible to me without additional context. A rose by any other name, etc. But it is a well-known issue, at least in the tech-community, when things change names—it's enough to make people leave for some reason; I don't have to know why, and @TimToady doesn't have to know why (perhaps he does, perhaps he doesn't, I don't know), but dealing with that impetus is required either way; I assume that's one reason no one's seriously been entertaining a name change rather than an aliasing.

I've been thinking about cases where there are multiple names for overlapping things and how the larger community deals with it. If you're old enough, consider the many cases back in the days of proprietary Unix, when many GNU tools had to be named differently from their basically-identical Unix counterparts. Some were puns: "more → less", "yacc → bison", etc. Some were not. But people were comfortable talking about them more or less interchangeably. The same, mostly, goes for vi vs Vim. There are many other examples.

And for the most part, the same goes for "Unix" and "Unix-like", and "Linux" and "GNU/Linux". But the fact there are those who feel passionately about not mixing those names up, and comparing them to those who casually use the names interchangeably, could be useful to us here. Because, I think, the intention is for "Raku" to become like that—a name whose distinction from "Perl 6" is meaningless to those who don't need it to be meaningful.

@zoffixznet makes the (arguable, but unprovable one way or another without testing) case that an alias unrelated to "Perl 6" can, in a way, fool those who aren't paying attention—draw them in by a blog post or something that doesn't mention "Perl" to give the language a chance, and at least see a few cool things about it that make them not dismiss it with prejudice when they first realize it's got another name, too, one that they would have prejudicially dismissed.

I think that seems like an idea worth trying, and apparently Larry did, too.

There are those who, at any technical conference, will forever shout "GNU/Linux!" whenever the speaker says the word "Linux" referring to more than the kernel. But that's fine; we're not going to lose anybody at that conference saying, "wait! This OS is GNU?!?!? I'm outta here!" They're already invested, they already know they like it, the relationship to something they might have certain (unwarranted) suspicion of is not going to really matter to them.

Or consider the early days of clang and LLVM; these exciting new technologies were strongly married to old fusty technology, and they arguably revitalized those language communities. Clang got a lot of credit for stuff that was actually LLVM, and clang and LLVM together got credit for things that weren't in LLVM at all, but were simply updates to programming languages clang/LLVM implemented that the community hadn't previously paid much attention to until the new technology brought their attention to it.

So I think there's some reason to think that a name separate from Perl can both exist without creating too much confusion among the dedicated community, while also creating "just enough confusion" to "fool" the uninitiated into thinking it's a whole new language from Perl ≤5. Which it is.

For example, I've seen people mock the supposed Raku file extensions, even though no plans ever existed to modify file extensions.

I did not scoff, just asked a question 🙄

@interlab it's unlikely to be about you. I've seen some mocking, and I don't remember you being involved.

And now when finally “Perl” is starting to get a less negative connotation in the world, we’re about to throw all of that away.

In my experience when you say "Perl 6", people hear "Perl", i.e. without a version number and as a reference to Perl 5. The "Perl 6" brand is almost non-existent outside our echo-chamber. Hopefully, it may change in the future, but we're not there yet.

@zoffixznet's (approved) proposal is just about an alias today. @lizmat's counter-proposal takes the discussion to a new level about intent and future actions. I fail to see how a fork can be pragmatic in this context, when the solution is to simply ignore the alias if one disagrees.

The consequences of the fork proposal are dire and it's not only about the duplication of work and discoverability problem (as @treyharris++ explains above). A manu militari split (following the coup metaphor that I dislike) will lead to two communities, indifferent to each other at best, or more likely, antagonistic. The Linux distributions examples are not applicable to our situation, knowing that there is just enough people to have one Rakudo Star distribution (and the maintainer is leaving) and one compiler. The Perl 6's community is just too small to fork.

There's no aliasing specification, but there's a renaming specification now!

Thank you all!

https://github.com/perl6/problem-solving/blob/master/solutions/language/Path-to-Raku.md

Raku / user-experience

Perl 6 aliasing specification #31