Hacker News new | past | comments | ask | show | jobs | submit login

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.




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.


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?


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.


I don't mind conservative changes to the language honestly. Knowing that what you get is what you get is quite empowering. But I'm not going to confuse and lie to myself into thinking there's going to be massive new features in any new version of Perl (5). That's what Perl 6 was supposed to be, but "Perl 6" isn't Perl and that's not a great thing, as choices to add to my tool box just puts Perl 6/Raku in line against Python, Ruby, Scala, Java, etc, etc, etc. I'm not saying anything new... that's the existential crisis created by not having backwards compat. Does Perl 6/Raku seem AWESOME?! Yeah; but not production-ready.

The idea of extending things via modules in Perl 5 was a great one, but there's a limit on what you can without features guaranteed to be in core. I also get the idea that keeping the core small is probably a good one (by not shipping every module in the world), and keeping the language opinionated (by letter you select just what type of meta-object system you want, but after a while, it doesn't seem like these things help with architecting a future for the core language.

So it goes, I suppose.


Rurban is working on modernizing Perl 5, eg http://perl11.org/cperl/perlclass.html

It is doubtful this will ever be backported into the official distribution, because $drama...


It will not, given the current culture war, but perl5 will just die off, and cperl is the replacement. esp. when it will be 2x faster.


mst doing some interesting work with babble, a babel for Perl 5. Hoping we get a typescript workalike in Perl.


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?


"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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: