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
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.
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.
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?
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".
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 .
> 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.
“There are only two hard things in Computer Science: cache invalidation and naming things.” -- Phil Karlton
Finally! Marketing is important, even for a programming language. First, coming up with a new brand name will go a long way to get rid of the conflation with Perl 5. Raku sheds that confusion; even though for now we all know it's Perl 6, this helps the language take a direction of its own and progressively stop the instant association with Perl 5.
Finally, the site https://marketing.perl6.org also seems to have other material that's pretty well put together. As someone who is not immersed into the community, this helps promote the feeling that the project is vibrant. (Side-note: they should get a domain to reflect this.)
Yes there's waaaay more to a language ecosystem than marketing, but I'm glad to see this effort.
the depth of perl6 is shocking and easy to get lost in (in a good way). It's the sort of thing you could spend a lot of time mastering and really learn something new constantly. I think the sheer number of concepts mashed together (pretty well) is very educational.
I love Perl5, and would like Perl6 to succeed. I just don't see it happening though. It took this long for the features to settle, but now people will wait for the performance to improve. In the meantime, the userbase has left for Ruby or Python or something else.
The main canary test for performance used by the community is the Text::CSV module. The vanilla Raku implementation is about 2x slower than the C wrapping Perl equivalent. The nice property of the Raku library is you can run it in parallel quite trivially and then its suddenly faster than the Perl version. In general the simple introduction of hyper/race keywords into user code is a big win for performance, but perhaps not cost.
There are a tonne of features of the language specific for performance most people walking through the door aren't so aware of. Native type decorating your code and variables for example, usually invokes significant improvements to numeric work. The JIT does some of that automagically but simple issues like your code implicitly switching between rational and floating point types will break optimisation. If you don't say what you really want to do Raku always assumes you want to do the safest and usually slowest thing like use bignum or rational type things, that are harder to speed up down at the CPU.
I use all of the three language in my day-to-day computer usage (i.e. I have scripts in each one of them), and I don't think Python or Ruby really replaces Perl 5 at what it's doing good: being a very powerful Unix citizen. Perl 5 is still better at regexps, at string manipulation, at how it combines these features w/ Unix I/O, and at offline documentation. Ruby has the best syntax and language flexibility among all (I hate Python's significant indentation and general unnecessary "stinginess" of the syntax), and Python shines with its wide array of libraries and availability of jobs. Also, AFAIK Python supports Windows better, and has a better REPL than Ruby (Irb can not run all the code the interpreter itself can run).
Considering that Python 3 is barely getting installed by default on OSes (Arch were the pioneers, doing it very early, but everyone else either did it 5+ years after the Python 3 launch or haven't done it yet, 10+ years after the launch), I wouldn't hold my breath.
And Python is a much popular language, compared with Perl, plus the Python 2 -> 3 changes were much smaller than Perl 5 -> 6.
I'd venture to say that besides some very niche distributions, Perl 6 will never be included in the base installations, unless it gets some killer app.
Someone's always playing programming language games
Who cares they're always changing programming language names
We just want to dance here, someone stole the stage
They call us irresponsible, write us off the page
From all the 6d changes and features already implemented in cperl, the only one intersection, the default value of Num was chosen correct by cperl: 0.0 and not NaN as chosen previously by rakudo. So no new incompat's and deviations.
It's interesting that this language won't die. To me Perl is a great course in how not to design a language. And Larry Wall somehow seems to default to being wrong about design choices. Perl is one of those things that people spend a long time learning and pride themselves in it, not realizing what they're learning is useless. Only Ruby seems to be worse, but at least it has fewer sigils.
Just by using a language you will find a lot of design choices that you either like or don't. There's no reason that you need to design a language to criticize the choices made in a a language.
IMO, Julia is Python done right, without all the annoying bits of python, and (much) faster.
Perl is (still) a fantastic language to use when you have complex tasks and don't want to spend more time on boilerplate and specific formalisms of the language, than the problem space. Perl is still (as in has been for many years) the goto language for a number of difficult problems. If your tooling is helping you write in the tool versus helping you solve your problem, you might be using the wrong tool.
I agree with you that I find the language design of Perl horrible. But I wouldn't call it useless, there's still plenty of Perl (5) jobs around. I just wouldn't go anywhere near that. But that's a personal choice.