OK, Raku

So, Larry Wall agreed to rename Perl 6 to Raku. Here’s the quote with a nested quote in it:

I am in favor of this change, because it reflects an ancient wisdom:

“No one sews a patch of unshrunk cloth on an old garment, for the patch will pull away from the garment, making the tear worse. Neither do people pour new wine into old wineskins. If they do, the skins will burst; the wine will run out and the wineskins will be ruined. No, they pour new wine into new wineskins, and both are preserved.”

This blog will soon be renamed from Perl 6 Inside Out to Raku Online, and most likely you will read it from raku.online instead of perl6.online (DNS changes are still not always that instantaneous as language renaming).

The major two ideas behind renaming is to:

  • Allow Perl 5 to continue its development, and
  • Avoid Perl in the name of Perl 6 to have new adopters.

There were a number of long and painful discussion rounds, and I would not say that they were human-oriented. There are still a few issues that you cannot cancel, but I am ready to reset it.

The Raku language is a great language and it is ways better than the Perl 6 as it was originally thought 19 years ago. It is not only about changing the syntax of the for loop; during the past two decades, the language design got some killing features, among which are, first of all:

  • Grammars — the next level of world-standard regular expressions, and
  • Features for parallel and concurrent computations (including a lot of syntactic pleasures such as reduction operator).

Even without the other features of the language, these two items can potentially attract new adopters of the Raku language.

But.

But what is missing from the rename proposal is the fact that the current Rakudo compiler is not actually production-ready. I’ll explain.

When I was promoting Perl 6, I was always mentioning that it has a compiler that can be used even in production. Indeed, it does not crash anymore (at all!), it is quite reliable, feature-complete and more or lest fast at the execution phase. But fast enough for test and joy. Not for production.

My plan for the next round of Perl 6/Raku life cycle is to:

  • Establish an annual international Raku conference (having the RakuCon name in mind), and
  • Initiate the compiler speed boost.

As for the conference, I propose we have the first RakuCon conference on Cyprus in May 2020, at the place we proposed for the PerlCon 2020 earlier this year in Riga. I am sure that in the long term, PerlCon and RakuCon will part, so there’s no need to wait before it happens naturally. I would prefer to force it. The presence of Raku at PerlCon is up to their organisers. From my side, RakuCon is open for Perl 5 talks (the most interesting topics are Perl 5 adopting the Perl 6/Raku features and changes in the Perl 5 compiler(s) to make it faster).

As for the compiler question, I am less confident in this area. I am confident in that if the compiler is faster, the language gets stronger perspectives.

Let me tell the truth, even if the Rakudo team will hate me once again. The Rakudo compiler is over-engineered. It has at least three layers that include NQP and MoarVM, which helped to build the compiler for the complex language, but slows up real-life applications.

I see two ways to achieve the goal (the goal is, if you missed it, to make Raku a popular programming language):

  • Create a new Raku compiler.
  • Learn Rakudo to produce binary or bytecode output that can be executed at machine speed. I think it is fine that only a subset of the language will be allowed here.

From the Perl 5 and the former Perl 6 community, I am seeking for help to implement the above items. In a few weeks, we will approach the companies to explain our view of Raku perspectives and to ask for supporting the conference and possibly the development. If you want to help my team, please indicate your intention.

I want to reset all previous grudges and start it over.

This is the only way Raku can prosper and thrive.

Ah, yeah, and tell me if it is Ráku or Rakú.

On renaming Perl 6

In short: I am against renaming.

The longer story

Once in a while, another round of the non-ending battle starts, and this time, unfortunately, I was the one who allowed to start it from a public stage. There were a lot of noise around the keynote speakers of PerlCon 2019 in Riga, and in the end, two speakers cancelled their participation, and we as the organisers replaced them with other prominent members. Actually, initially we were going to have three Perl 6 keynotes, and in the end it became more balanced: two Perl 6 and one Perl 5 talk.

I was very happy about the presence and the content of the Perl 5 talk, as well as about the Perl 6 Concurrency one. In the third keynote, actually, it was proposed to rename the language from Perl 6 to Camelia.

The same day, an issue in the problem-solving repository was open. Soon after that, a pull request was created to replace all mentions of Perl 6 (including the filename extensions and methods like .perl) to Raku.

Why Raku? Because the discussion led to the idea that Raku is better then Camelia. (Raku is the name that was proposed a year ago as an alias of Perl 6).

A bit of a history

Let me express what I feel about this all movement. I am following the Perl 6 development for many years, starting from its very beginning. Years ago, I was surprised how easily the development teams change their internal mechanisms. If you can recall that, there were IMC (intermediate code/compiler), PASM (Parrot assembler), PBC (Parrot bytecode) and a lot of other abbreviations which you can only understand if you follow the development of the language and is subscribed to different mailing lists of different development teams.

Originally, it was thought that Perl 6 compiler will use a virtual machine, and Parrot was the first attempt, which failed due to internal communication issues. Later, an attempt to switch to other virtual machines was made, including the JVM. As it was thought that Parrot virtual machine dit not serve the needs of Perl 6 and was instead aiming to supporting other languages, the MoarVM project appeared.

While the Perl 6 language is a beautiful language, the language design is quite complicated to be implemented, which resulted in the fact that we now have only one working compiler, Rakudo. It became very stable and reliable and can even work in production in a lot of applications. Even in those applications that require high performance. Rakudo is slow at compiling, but MoarVM is fast at executing.

Who is the owner of Perl 6

The Perl programming language is created by Larry Wall and it was released in 1987. Since then, it turned to its fifth version, which is still in active development (let me refer you to the Day 1 keynote of PerlCon 2019).

The Perl 6 programming language was originally thought as a continuation of the same Perl language, with a note that it should be a community rewrite. Does that mean that Larry is not the author of Perl 6 any more? No. He still is.

What is proposed in the renaming issue is to rename the language, and to vote on that within the current development team. The development team is working on both Rakudo compiler and the language specification, so it is a valid institute to raise discussion about the language. But. But there is one strong but: Larry is still the author of the language, and it’s his right to keep or break the language name.

In the renaming issue, it was only once mentioned that it is possible to rename the fork (read: implementation) and keep the language name unmodified. To support that, I am referring you to Larry’s words in his keynote given in 2017 at the Perl Conference in Amsterdam. He said there that using different names is fine when it is done for marketing purposes.

Up to date, we have no direct statement by the author of the language that he wants or agrees to rename it.

Do I need Perl 6?

I have been programming for the internet since 1999 and while my native language is C++, I am considering myself as a Perl programmer.

When Perl 6 was announced, I was among the first who wanted to start using that. I created the first web site in the world that was running on Perl 6 (give me a link if you disagree). The site was running on the very first implementation of Perl 6 written in C (even before Parrot) and was using pre-compiled byte code to serve pages.

Since that time, I changed a lot of places of work, being a developer, an CTO, a business owner and a bare life-lover. Today, I am much less connected with writing code (whatever code, not only Perl), and my activities shifted to other fields.

But still, Perl 6 for me is a beautiful language with a great potential. And it is very interesting and pleasant to blog about it, to help organising events, and to promote the language in different ways. So, despite I am not very much able to use it in my practice, I am willing the language to become widespread.

Back and forth

Earlier this year, Perl 6 entered the TIOBE index. Yes, somewhere at the end of the list and not very stable, but it was obvious that we can make its positions stronger if we make some simple SEO correction and include the Perl 6 programming phrase into our publications, as this is how TIOBE ranks the languages.

What is proposed now, effectively cancels all efforts of many people who was working during the recent years to make Perl 6 more popular and to demonstrate how great it is.

Once again, the Perl 6 path is making a sharp turn and loops itself. Intermediate language, Parrot assembler, Parrot bytecode, Java virtual machine, MoarVM, Perl 6, Raku, Camelia. Hey, what’s up? It is an endless game of naming and tool changes or a way to make the language popular? What currently happens, is another round of an idea that renaming can help. This is like inventing a name and buying a domain name for a start-up that has no chances to work as it mostly focuses on its name rather than being the best among the others.

What is behind the scene

Unfortunately, and what is mostly sad for me personally, I have seen a bit more than only public discussions that you can see too.

Conference attendance cancellations are not caused only by those reasons that were publicly announced. There are other things happened under the hood. People are being bullied, words are misinterpreted, and I have no wish to make that public. I can only hope that the current heroes will understand how badly they play.

Titus 3:10-11. 10 Warn a divisive person once, and then warn them a second time. After that, have nothing to do with them. 11 You may be sure that such people are warped and sinful; they are self-condemned.

It is not correct at this point to demand, to vote, and to approve to rename the language.

On a separate line, I want to thank all the developers that made Perl 6 possible. But I want to distinguish between the desire to constantly working on the process flow rather than making the product.

A simple solution

The best solution is to allow the Perl compiler (interpreter, translator, whatever) to accept both Perl 5 and Perl 6 code. This was, actually, the idea of the first Perl 6 compiler projects. It was supposed that the compiler will be able to determine the language even without a use vX instruction, but by just looking at the code. For example, does the file start with class? It is a Perl 6 program.

As the Perl 5 and Perl 6 languages became much more separated in their syntax, it is a very simple to determine the language by reading a few lines of code. This is not an impossible task for a computer program, isn’t it? Let the common compiler decide which backend language to use at this particular case. /usr/bin/perl stays in its place and does the job.

🦋 109. 42 via the cubes

In the recent days, you might have seen the calculation that leads to getting an exact value of 42, the answer of Life, the Universe and Everything. Let me copy it here, using the power of Perl 6 and its arbitrary precision arithmetics , not to mention the coolness of using superscripts directly in the code.

$ time perl6 -e'say 80435758145817515³ - 80538738812075974³ + 12602123297335631³'
42
real 0m0.151s
user 0m0.173s
sys 0m0.035s