3 ms·

This is an interesting bit that HN seems to discuss a lot: Some community members believe "Perl 6" is a very confusing name: it uses a digit as part of the na

This is an interesting bit that HN seems to discuss a lot: Some community members believe "Perl 6" is a very confusing name: it uses a digit as part of the name and it conflicts with the name of a sister language "Perl". Some outsiders don't realize "Perl 6" is a brand new language—vastly different than "Perl"—and so avoid it, thinking they know what it is already. At the same time, some who love "Perl" come to "Perl 6" and feel tricked, because the language isn't the next release of that language, but an entirely different one. To clear up the confusion, Larry Wall created a second name for the language, a "stage name" if you will. That name is "Raku". It can be used interchangeably with the original "Perl 6" name or even be combined with it to form "Raku Perl 6". Pick the one that works the best for you and use it consistently

justinator 8y ago
This is such a blunder in naming in a line of blunders that is this language. So we have, * Perl 6 * Raku * Raku Perl 6 and we're told to, "Pick the one that works the best for you and use it consistently". And don't forget there's, Rakudo, a compiler for Perl 6 -aka- Rakudo Perl 6 Compiler If you wanna rename things, fine - just do it, don't do this halfsies thing. Don't make the name collide with something else, especially in a very related project.
- haolez 8y ago
  It might be a good idea, regardless of the confusion that this can cause in the short term. Do you have any suggestion of a better "fix", apart from choosing a more appropriate name at the time of its inception?
  - justinator 8y ago
    "Raku" sounds fine with me - just rename it. Deprecation time where the name is known as, "Kaku (formerly: Perl 6) for the next year until Raku.e (or whatever they call it) comes out.
- kbenson 8y ago
  My initial thoughts were womewhat similar. Raku when there's already a Rakudo? I guess the reasoning is that they don't want to impart some special status to Rakudo, but they might as well if it's this close. For the last few years I've actually been of the opinion that if they were ever going to change the name, making it Rakudo would make the most sense. Just make Rakudo the reference implementation of the Rakudo language (the language formerly known as Perl 6), and call it a day. Actually, the more I think about it, using "Rakudo (the language formerly known as Perl 6)" as a descriptor would probably do the best job encapsulating what it is succinctly. It was a continuation of Perl, but now it's its own thing. As opposed to "Perl 6", which doesn't really convey how radically different it is. I'm not really one of the "Perl 5 needs to reclaim the Perl 6 name" camp, even though I'm a full time Perl developer and have been for close to two decades. Perl 5 will do what Perl 5's going to do, and freeing up the Perl 6 name won't help all that much with that (it's not like there's enough changes worth making a Perl 7 from, and a purely marketing driven name change would just be laughed at). It might actually be more beneficial to Perl 6.
  - justinator 8y ago
    I think it's also time to just call it on Perl 5: It's a dead end: no one can work with the internals unless you're a wizard, and getting the porters to decide on any large features is impossible (function signatures, anyone?), and the, "experimental" pragma is broken. Is it still useful? Damn right it is, but there's not going to be a Perl 5++. Speaking as someone who's been writing Perl since oh, 1997 or so. So another multi-decader (and no plans of stopping) - where do we all meet? At the bar?
    - smueller1234 8y ago
      I don't think working on the perl5 internals is quite as hard as you make it sound. Yes, there's brittle dependencies between many parts. Yes, it's a very complex piece of software (and in intrinsic and implementation specific ways). But the single biggest barrier for Perl devs to hack on it is that most of them aren't also great C programmers. To wit, I'd tried many times to get the hang of it as a Perl dev and struggled. After I learned C properly for unrelated reasons, the nextb attempt went swimmingly. I've also seen folks show up on the porters list and get up to speed in just a few weeks. Now, I'll concede the point regarding language design though: the Perl 5 Porters have become very conservative wrt language evolution. I used to be highly skeptical of this (I convinced folks of strict by default in 5.12 and oh how much I lobbied behind the scenes for fully @_ eschewing function signatures!) but since we made a number of blunders in such changes in the decade prior, I understand the conservativism.
3rdAccount 8y ago
I've been in hundreds of P6 conversations and it is always such a bummer to see that this is always the number 1 thing discussed. Not the merits of the language, not the grammars, or concurrency, MOP, functional and OO syntax, junctions, running multiple languages, gradual typing, restricting inputs with types, Unicode....none of that. The fact that it is always brought up to me makes me think they should've just called it something entirely different. Hindsight is 20:20 though.
- s_kilk 8y ago
  > Hindsight is 20:20 though. Well... a lot of folks saw this coming. As you say, it's been brought up again and again, since the start. Foresight is also 20:20, if the right people are willing to listen to what's being said.
zeade 8y ago
This sounds exactly like a Larry Wall solution, especially the "use interchangeably" and "pick the one that works the best for you" parts.
- fasquoika 8y ago
  "There's more than one way to name it"
- petre 8y ago
  I like Larry Wall solutions. Why just throw away a perfectly working implementation when people are still using it and maintainers are still motivated to work on it? Why not do a new spec which improves on the old one and if it's succesful people will switch anyway. It allows the language to evolve while it also doesn't force users into the new thing against their will. None of that "Python 2.7 is going to be EOL in 1/1/2020".
  - bionoid 8y ago
    > I like Larry Wall solutions. Me too, historically anyway, but I'm not a fan of this half-way approach. Someone explicitly requested that Larry create an alias for the language [0]. > If another name is truly as superior as the full-rename proponents claim it would be, I believe the alias can become a defacto name through its sheer amount of use. Thus, the creation of the alias can be seen as a means for the full-rename proponents to prove their claims. Emphasis mine. Among other things, this does not compute for me. Adopting three names for the language (Raku, Raku Perl 6, Perl 6) is the exact opposite of what the full-rename proponents are suggesting. You're not giving them an opportunity to prove their claims, you're giving them the middle finger. Or that's how it seems to me, anyway. [0] https://rakudo.party/post/A-Request-to-Larry-Wall-to-Create-a-Language-Name-Alias-for-Perl-6 https://rakudo.party/post/A-Request-to-Larry-Wall-to-Create-...
    - petre 8y ago
      Perl 6 is still Perl and the name was in use for quite some time, so an alias makes better sense rather than a full rename. Full renames are annoying. Just look at ECMAScript. Is anyone using this name? No, everybody's still using JavaScript. People are only using ES5/6/7 when they refer to the specification. The name stuck. It's too late now. And people are needlessly wasting too much energy over a name. “There are only two hard things in Computer Science: cache invalidation and naming things.” -- Phil Karlton

justinator 8y ago

This is such a blunder in naming in a line of blunders that is this language. So we have, * Perl 6 * Raku * Raku Perl 6 and we're told to, "Pick the one that works the best for you and use it consistently". And don't forget there's, Rakudo, a compiler for Perl 6 -aka- Rakudo Perl 6 Compiler If you wanna rename things, fine - just do it, don't do this halfsies thing. Don't make the name collide with something else, especially in a very related project.

haolez 8y ago
It might be a good idea, regardless of the confusion that this can cause in the short term. Do you have any suggestion of a better "fix", apart from choosing a more appropriate name at the time of its inception?
- justinator 8y ago
  "Raku" sounds fine with me - just rename it. Deprecation time where the name is known as, "Kaku (formerly: Perl 6) for the next year until Raku.e (or whatever they call it) comes out.
kbenson 8y ago
My initial thoughts were womewhat similar. Raku when there's already a Rakudo? I guess the reasoning is that they don't want to impart some special status to Rakudo, but they might as well if it's this close. For the last few years I've actually been of the opinion that if they were ever going to change the name, making it Rakudo would make the most sense. Just make Rakudo the reference implementation of the Rakudo language (the language formerly known as Perl 6), and call it a day. Actually, the more I think about it, using "Rakudo (the language formerly known as Perl 6)" as a descriptor would probably do the best job encapsulating what it is succinctly. It was a continuation of Perl, but now it's its own thing. As opposed to "Perl 6", which doesn't really convey how radically different it is. I'm not really one of the "Perl 5 needs to reclaim the Perl 6 name" camp, even though I'm a full time Perl developer and have been for close to two decades. Perl 5 will do what Perl 5's going to do, and freeing up the Perl 6 name won't help all that much with that (it's not like there's enough changes worth making a Perl 7 from, and a purely marketing driven name change would just be laughed at). It might actually be more beneficial to Perl 6.
- justinator 8y ago
  I think it's also time to just call it on Perl 5: It's a dead end: no one can work with the internals unless you're a wizard, and getting the porters to decide on any large features is impossible (function signatures, anyone?), and the, "experimental" pragma is broken. Is it still useful? Damn right it is, but there's not going to be a Perl 5++. Speaking as someone who's been writing Perl since oh, 1997 or so. So another multi-decader (and no plans of stopping) - where do we all meet? At the bar?
  - smueller1234 8y ago
    I don't think working on the perl5 internals is quite as hard as you make it sound. Yes, there's brittle dependencies between many parts. Yes, it's a very complex piece of software (and in intrinsic and implementation specific ways). But the single biggest barrier for Perl devs to hack on it is that most of them aren't also great C programmers. To wit, I'd tried many times to get the hang of it as a Perl dev and struggled. After I learned C properly for unrelated reasons, the nextb attempt went swimmingly. I've also seen folks show up on the porters list and get up to speed in just a few weeks. Now, I'll concede the point regarding language design though: the Perl 5 Porters have become very conservative wrt language evolution. I used to be highly skeptical of this (I convinced folks of strict by default in 5.12 and oh how much I lobbied behind the scenes for fully @_ eschewing function signatures!) but since we made a number of blunders in such changes in the decade prior, I understand the conservativism.

3rdAccount 8y ago

I've been in hundreds of P6 conversations and it is always such a bummer to see that this is always the number 1 thing discussed. Not the merits of the language, not the grammars, or concurrency, MOP, functional and OO syntax, junctions, running multiple languages, gradual typing, restricting inputs with types, Unicode....none of that. The fact that it is always brought up to me makes me think they should've just called it something entirely different. Hindsight is 20:20 though.

s_kilk 8y ago
> Hindsight is 20:20 though. Well... a lot of folks saw this coming. As you say, it's been brought up again and again, since the start. Foresight is also 20:20, if the right people are willing to listen to what's being said.

zeade 8y ago

This sounds exactly like a Larry Wall solution, especially the "use interchangeably" and "pick the one that works the best for you" parts.

fasquoika 8y ago
"There's more than one way to name it"
petre 8y ago
I like Larry Wall solutions. Why just throw away a perfectly working implementation when people are still using it and maintainers are still motivated to work on it? Why not do a new spec which improves on the old one and if it's succesful people will switch anyway. It allows the language to evolve while it also doesn't force users into the new thing against their will. None of that "Python 2.7 is going to be EOL in 1/1/2020".
- bionoid 8y ago
  > I like Larry Wall solutions. Me too, historically anyway, but I'm not a fan of this half-way approach. Someone explicitly requested that Larry create an alias for the language [0]. > If another name is truly as superior as the full-rename proponents claim it would be, I believe the alias can become a defacto name through its sheer amount of use. Thus, the creation of the alias can be seen as a means for the full-rename proponents to prove their claims. Emphasis mine. Among other things, this does not compute for me. Adopting three names for the language (Raku, Raku Perl 6, Perl 6) is the exact opposite of what the full-rename proponents are suggesting. You're not giving them an opportunity to prove their claims, you're giving them the middle finger. Or that's how it seems to me, anyway. [0] https://rakudo.party/post/A-Request-to-Larry-Wall-to-Create-a-Language-Name-Alias-for-Perl-6 https://rakudo.party/post/A-Request-to-Larry-Wall-to-Create-...
  - petre 8y ago
    Perl 6 is still Perl and the name was in use for quite some time, so an alias makes better sense rather than a full rename. Full renames are annoying. Just look at ECMAScript. Is anyone using this name? No, everybody's still using JavaScript. People are only using ES5/6/7 when they refer to the specification. The name stuck. It's too late now. And people are needlessly wasting too much energy over a name. “There are only two hard things in Computer Science: cache invalidation and naming things.” -- Phil Karlton