Raku Perl 6.d [pdf] | Hacker News Reader

Raku Perl 6.d [pdf]

marketing.perl6.org

94 pointskbenson46 comments

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

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.

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.

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.

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

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.

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.

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

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

"There's more than one way to name it"

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

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

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

The difference is that Javascript is outrageously popular, while Perl 6 is confined to an audience of a handful of nerds (me included). I think this is a great time to just switch names, as the number of people affected is tiny.

There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

Same info as plain text, if a PDF doesn't work well for you: https://github.com/perl6/roast/blob/master/docs/announce/6.d...

Thank you.

Hacker News is really inconsistent in marking PDFs.

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.

(This is the opposite of LiveScript which was renamed to JavaScript to mentally associate it with Java during its prime hype days. Either way, it's a tweak on the mental association.)

Secondly, the PDF is very well put together. This is much nicer than your typical release notes cobbled together from git commits: it's actually pleasant to read. (Though if you really prefer an HTML version, that's also available: https://github.com/perl6/roast/blob/master/docs/announce/6.d...)

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 applaud the perl6 folks for bringing experimentation and FUN back to dynamic languages. Perl6 is a hoot.

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.

Interesting thread from this summer: https://www.reddit.com/r/perl6/comments/8p26bb/is_perl6_fast...

That was 5 months ago. A lot happens in this space in two weeks let alone half a year. Rakudo is released monthly still, with quarterly(ish) distribution releases. An example bit of insight:

https://github.com/rakudo/rakudo/search?o=desc&q=fast&s=comm...

That's just the compiler rather than VM or NQP level, where you will see even more performance related work.

One of the bigger breaking changes in 6.D at the language spec level is for performance of scheduling multi threaded work. https://github.com/rakudo/rakudo/pull/1004

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.

>now people will wait for the performance to improve. In the meantime, the userbase has left for Ruby or Python or something else.

Performance and Python aren't exactly related (I know you can call into C code with numpy etc., but still Python itself and idiomatic code in it is often super slow).

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

"Raku" is the name I'm going with. Raku programming language. Now when is it going to be installed by default on OSes?

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

Where are the Windows binaries?

https://rakudo.org/files

This is the release of a programming language (tests + documentation), not of a compiler.

If you're looking of the compiler, check https://rakudo.org/files

Does Hacker News not mark PDFs anymore?

I think the app only check the URL, the rest is manual editing.

The original news server only marked pdf on the scribd site [1]

[1] https://github.com/arclanguage/anarki/commit/a939a35c03c469d...

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.

Perl 6 would have been great had it been released 10 years ago. I'm surprised that people continue to put their time into it, I don't think it's going to see much adoption now

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.

So, which language(s) have you designed that exhibit good choices?

I don't think you need to design your own language to criticize another. I think Rust and F# are great language designs. I think Perl (5) and JavaScript are terrible. Python is somewhere in between (I'd like the typing system to be optional but actually checked, I think the module system is broken, the only reason I use it is because of very good libraries). TypeScript makes JavaScript usable actually enjoyable.

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[1] 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.

Perl is not for numerics for a number of reasons. Javascript isn't either. Python is ... well ... python. It's the MSBASIC of the 201x years. As my comment above noted, I believe that Julia will quickly replace Python, as it has a saner syntax, trivial library integration, great package/module system (though the 1.0 transition has been bumpy with mass deprecations that could have been handled better), is compiled, has an optional strong type system, works in parallel out of the box (no GIL), ...

edit: included missing reference.

[1] http://julialang.org

Very good points, the instability of Julia has put me off in the past, but it sounds like they made much saner decisions in general.

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.

How do you think Ruby's worse?

Reply on news.ycombinator.com