Grant Proposal: RPerl User Documentation Part 3


The Grants Committee has received the following grant proposal for the March round. Before the Committee members vote, we would like to solicit feedback from the Perl community on the proposal.

Review the proposal below and please comment here by April 12th, 2017. The Committee members will start the voting process following that and the conclusion will be announced approximately in one week.

RPerl User Documentation, Part 3

  • Name:

    Will Braswell

  • Amount Requested:

    USD 2,400


RPerl v2.4 has been released, and now includes auto-parallelization along with a raft of other new features, as expected. Approximately 150 pages of new documentation have been published as part of the RPerl User Docs grant part 2, comprising chapters 2, 3, and 4. Yet, several more chapters remain to be written before the book is done. This grant proposal is to continue work on the Learning RPerl textbook.

Benefits to the Perl Community

The number one request and obvious need at this time is still quality RPerl user documentation, to help new RPerl users learn how to write fast software. Learning RPerl is the canonical guide to RPerl and must be completed to enjoy the maximum benefit to the Perl programming community.


Deliverables for this grant proposal are:

1. Write Learning RPerl Chapter 5

2. Write Learning RPerl Chapter 6

Project Details

I've already written all of the code for the solutions to exercises from chapters 1 through 6 of Learning Perl:

Learning RPerl Github

I've already got a partial copy of Learning RPerl on the website:

Learning RPerl Website


Chapter 5 Data I/O



1c. printf Operator

1d. die & croak Operators

1e. Filehandles & filehandleref Data Type

Chapter 6 Hash Values & Variables

2a. Hashes vs Arrays

2b. 1-D Hash Data Types

2c. How To Access Hash Elements

2d. keys Operator

2e. 2-D Array Data Types & Nested Arrays

2f. Converting From Array To String

2g. Hashes & The foreach Loop

Project Schedule

I will begin work immediately upon granting.

I expect work to take approximately 60 to 90 days.

Completeness Criteria

I will release a new version of RPerl to CPAN with the new documentation.

I will release a new version of the RPerl website with the new documentation.


I am the creator and lead developer of RPerl.

I've been working on RPerl for over 4 years.

I've successfully completed work on 2 TPF grants.

I would like to start work on the 3rd grant now.


this is awesome, moving forward to learn RPerl! Great job!

Extremely beneficial! Looking forward to the new works!

This is much YES!

I heartily recommend this prposal for acceptance. The RPerl project, and the perl11 org in general are doing great work for the community. Don't we all want a faster Perl? Moreover one that can easily bootstrap itself?

I support this project.

I like & love Perl. The way of Perl is cool enough. But having a faster Perl engine is a blessing to all of us. It would be nice if this proposal was approved. :)

+1. RPerl definitely deserves a well written textbook.

I look forward to the continued progress of RPerl!

An even faster AND well documented Perl is always welcome. Please allow this to happen.

I think RPerl is the natural stage of evolution of Perl. Perl is a powerful tool itself. Why shouldn't you let the world have a faster Perl? Please, get this proposal approved.

+1 RPerl has been impressive thus far.

Having the book done is a kind of prerequisite for adopting RPerl by companies and casual hackers, taking it seriously, making sure the developers have documentation for reference, etc.

Promoting RPerl in this way will help people trying it. Old perlers will rejoin and new ones will come.

I would like to see RPerl used more. Having a fast restricted Perl is a big argument against "Perl is dead!" that we keep on reading all over the web.

Thank you for supporting such projects!

I would love for RPerl to move forward. It has been impressive so far and I am looking forward to seeing it being used in many more places.

Please get the proposal approved. Thank you.


I'm all in favor of this project.

Rperl is awesome


+1 to RPerl! Fast Perl is really needed.

RPerl++! Much Perl, such fast!

QUESTION 1: We would like to see that Perl core developers are engaged in the RPerl development discussion and future integration planning, if any.

ANSWER 1: Yes we have the beginnings of engagement with the Perl core developers, here is an RPerl ticket filed by RJBS, in relation to a private e-mail discussion thread including myself, RJBS, Dave Mitchell, Karl Williamson, Andreas Koenig, and Sawyer X.

(This ticket is likely already solved, by the same mechanism as in answer #3 below, I will update the ticket status soon.)

RT CPAN Ticket

QUESTION 2: We also would like to see more collaboration (rather than argument) on RPerl itself. We hope an effort is made to involve more people in the RPerl development.

ANSWER 2: Sorry, I'm not sure who is arguing about RPerl... (Spurious claim?)

I have made every effort to involve as many people as possible in RPerl development, such as creating a Facebook group for RPerl system developers and another group for RPerl application developers:

RPerl System Devs Group

RPerl App Devs Group

Additionally, I have a private Trello board with an intake list of all prospective RPerl developers, I field numerous private messages regarding RPerl development on a daily basis, and we are live 24/7 in the #perl11 channel on the chat server. We've also got the normal RPerl page on Facebook and the Twitter account for general RPerl promotions:

RPerl Facebook Page

RPerl Twitter Account

QUESTION 3: Assuming the documentation will trigger more people to try out RPerl, we hope the test will be successful on more platforms soon (CPAN Testers Matrix).

ANSWER 3: I have made a major effort to increase the CPAN Testers Matrix coverage, including work with running RPerl in Windows, BSD, and other alternative operating systems.

Most importantly, I have created the new Alien::astyle CPAN distribution, which solves the issue of test failures due to missing astyle binary.

Alien::astyle CPAN Distribution

When this question was originally asked at the beginning of 2016, RPerl had far more failures than passes:

OLD: Pass 20, Fail 179
RPerl v1.51 CPAN Testers Matrix

Now, thanks to our ongoing efforts, we have quite a few more passes than failures!

NEW: Pass 60, Fail 40
RPerl v2.45 CPAN Testers Matrix

We will continue to whittle down the RPerl test failures until we reach 100% passes, which Alien::astyle has already achieved.

QUESTION 4: We would like to have Will's inputs on these comments made at reddit. The discussion is from a half year ago but it still seems relevant.

ANSWER 4: Although this is a mostly-troll posting, and the labyrinthine complaints therein are difficult to decipher in places, and most of the information referenced is so out of date as to be deprecated... Nevertheless, I shall at least give answers to the points in the original post.

POINT 4A: It promises to make perl programs 17 to 300 times faster, as long as you avoid certain language constructs.

ANSWER 4A: Yes, this is correct. Nothing mysterious or new there.

POINT 4B: It seems to have little readable documentation, and I've been unable to install it anyway, even though it's apparently reached 1.0 status recently.

ANSWER 4B: This grant proposal is related to RPerl documentation. This person was asking for documentation before it was available. Problem solved.

This person was unable to get RPerl v1.0 to install, which is not at all surprising or uncommon. Thanks to the upgrades and CPAN Testers Matrix passes referenced in answer #3 above, in addition to the new RPerl installation script, most users on most operating systems can now get RPerl installed one way or another.

On a modern operating system with good support for Perl & C++, such as Debian or Ubuntu, you can install RPerl by simply typing `cpan RPerl` or the equivalent.

On a more complex OS setup, you can fall back to the RPerl installation script:

RPerl Installer

This person failed to install RPerl, and then failed to ask anyone for assistance. If you don't ask for help, then it is your own fault!

POINT 4C: Its creator has a rather quirky vibe, even for a Perl guy, frankly he seems more like a character from a Wondermark comic than a real person.

ANSWER 4C: Ad-hominem personal attacks only serve to discredit this person's other points. Thus, my characterization of this as a "mostly-troll" posting.

POINT 4D: So, has anyone used it?

ANSWER 4D: You have numerous postings in this very grant proposal thread, made by RPerl users and enthusiasts. This show of community support speaks for itself.

That being said, I am not currently aware of RPerl being deployed in a production commercial environment, at least not yet!

Of course, the same can be said for Perl 6, which has received countless thousands (hundreds of thousands?) of dollars of support from TPF and elsewhere, not to mention thousands of more man-hours of labor than RPerl. After 15 years of development, I am unaware of Perl 6 being deployed in any production commercial environment, same as RPerl. If anything, RPerl has far GREATER adoption than Perl 6, with respect to the resources and effort afforded to each thus far.

POINT 4E: Got a quick how-to?

ANSWER 4E: Sure, try Chapter 1 of Learning RPerl!

Learning RPerl Section 1.21

POINT 4F: Can anyone show me a regular perl script going in, a compiled perl script coming out the other end, and the compiled script running 300 times faster?

ANSWER 4F: Yes we have several code examples.

Here's before-and-after for Bubble Sort: Uncompiled Compiled

Here are the before-and-after files for the N-Body solar system simulator: Uncompiled Compiled Uncompiled Compiled Uncompiled Compiled

I'll give one more example for now, the before-and-after files for the Pi number generator: Uncompiled

PiDigits Compiled

As for the request to show RPerl actually running, I am happy to give in-person demonstrations for anyone who is unwilling to install RPerl for themselves.

POINT 4G: What are the language constructs which it requires me to avoid?

ANSWER 4G: That's easy, check out the Low-Magic Perl Commandments!

The Low-Magic Perl Commandments

For more details, please read Learning RPerl!


Is anyone, other than Will, actively using RPerl for anything approaching production purposes?

I've not seen any evidence of people actually using RPerl. Are "we" paying for documentation that isn't going to be used in anger?

Hi Anonymous,

I've already answered your question, but here, I'll paste the answer again for your convenience:

"POINT 4D: So, has anyone used it?

ANSWER 4D: You have numerous postings in this very grant proposal thread, made by RPerl users and enthusiasts. This show of community support speaks for itself.

That being said, I am not currently aware of RPerl being deployed in a production commercial environment, at least not yet!

Of course, the same can be said for Perl 6, which has received countless thousands (hundreds of thousands?) of dollars of support from TPF and elsewhere, not to mention thousands of more man-hours of labor than RPerl. After 15 years of development, I am unaware of Perl 6 being deployed in any production commercial environment, same as RPerl. If anything, RPerl has far GREATER adoption than Perl 6, with respect to the resources and effort afforded to each thus far."


To reiterate, Perl 6 has lots of people using it, so does RPerl. Neither Perl 6 nor RPerl is in public production use yet. If you are suggesting that we should only support projects which are already in production use, then I suggest you are either out of line or unfamiliar with the basic processes of computer science R&D which drive the development of all major software advancements.

~ Will

I think efforts should go on packaging rperl for different distros so it would be easier to go and play with it. For example where are debian packages?

This is kind of major show blocker for us to going to production easily or even to consider this.

I'm also watching Perl news and blogs closely and not seeing anything about rperl. Needs more PR?

Just a few thoughts.

This looks like the third grant request for documentation of this project. I believe that the two previous grants were approved and successful.

I wonder if this might be a good time to step back and take a higher-level look at this project. I'd like to see opinions on the following questions from the grants committee and the wider community.

Do we feel that the previous two grants have produced material that is being used by the Perl community? Do we feel that RPerl is a net benefit to the community? Do we have an idea of how many of these grants Will is planning to ask for in total?

Personally, I'm not convinced of the usefulness of RPerl, but I can see from the previous comments here that many people disagree with me on that. I'm certainly not saying that we shouldn't accept this grant proposal - I'd just like to see more of the big picture.

Hi Jarkko Haapalainen, I would love to have your help in creating Debian (and Ubuntu) packages for RPerl. However, this is not related to RPerl documentation, which is the topic of this particular grant proposal.

We post news regarding major RPerl releases and events online, although again this is not directly related to the RPerl documentation grant proposal...

RPerl on Facebook

RPerl on Twitter

I would love to have your help is creating more publicity for RPerl! :-)

Thanks for your interest in RPerl, and I hope to hear from you soon.

~ Will the Chill

Hi Dave Cross,

Yes you are correct, this is the third RPerl documentation proposal and the first two were successfully completed by yours truly.

I wonder if this might be a good time to step back and take a higher-level look at why you, Mr. Cross, would post negatively-slanted questions which are already clearly answered by the overwhelmingly-positive community feedback provided in the previous comments, as you yourself have openly admitted?

I can only assume the answer is that it is because you, yourself, are "not convinced of the usefulness of RPerl", as you have stated, and that you are attempting to hinder any legitimate RPerl progress as a result of your own inability to appreciate real compiler work.

Have you installed RPerl on your own computer?

Have you executed the RPerl applications showing hundreds of times serial speed improvement?

Do you believe that actual runtime performance has any significance in the design and implementation of a computer programming language?


You have also posed the loaded question of "how many of these grants Will is planning to ask for in total?"

The answer is quite simple: as many grants as it takes to get the job done. How many ongoing grant allotments have been paid out to Dave Mitchell over the years, for example? Dozens? Hundreds? Why is it okay for Mr. Mitchell to receive practically infinite grant payouts, but I can't even ask for number three in as many years?

I reject your questions and premises as purposefully skewing the issues against RPerl, in an unwarranted attack against the only viable path to a full Perl 5 optimizing compiler.

Just because you like your Perl 5 code to run slow, doesn't mean the rest of us should have to suffer as well.

~ Will the Chill

As a name dropped in the comment, I feel a need to point my position: The single ticket filed does *not* constitute interaction with core. At the very least, Will has gone on record to note he does not intend to work with the Perl 5 Porters.

Please do not add my name to "prove" any "interaction" with P5P. I disagree with it, and I maintain there is no interaction, other than a single ticket regarding compilation. There are no discussions, no conversations, and open hostility towards the group (including rjbs and myself) have been expressed publicly.

While this is not the forum to talk about it, I don't want there to be any misunderstanding here.

If you're going to compare with Perl 6: I've seen a lot of different people blogging about their experiences with Perl 6, and how they solved various problems with Perl 6. I don't remember seeing any such blog posts of other people writing code with RPerl.

To answer SawyerX's comments:

Although it may be a "minimum level of interaction", there is still SOME interaction between the RPerl effort and the Perl 5 Porters by way of the RT ticket discussed (and associated private e-mails). In other words, Sawyer is simply wrong, because even one single RT ticket DOES "constitute interaction with core", albeit on a minimal and introductory level.

I have also reached out directly to RJBS and Sawyer in the past, but have received little to no response, which I take as yet another indication of passive-aggressive attempts to slow or disrupt RPerl development. Now we can all see Sawyer's true colors. He is clearly an anti-RPerl activist, which does not bode well for any part of the Perl community.

It is true that I am not an active member of Perl 5 Porters, but this is simply due to the fact that RPerl is not quite ready for me to jump head-first into P5P matters. Perhaps in another year or so, when we start adding high-magic support to RPerl, then will be the time to more fully engage with the P5P group.

HOWEVER, the more troubling aspects of Sawyer's comments center around his overwhelmingly-negative attitude toward RPerl, including false claims regarding my own "hostility towards the group". For the record, I have absolutely no hostility toward the Perl 5 Porters, or Sawyer, or RJBS, or anyone else in the Perl 5 core development team, other than the need to defend myself (and my friends) from continual anti-RPerl attacks as can be seen quite clearly in this blog post thread. In fact, as seen with the RT ticket, I have gone out of my way to address any issue brought forth by RJBS and his partners.

I can only assume that the reason why Sawyer is anti-RPerl is two-fold: first, RPerl is part of the Perl 11 effort, which also includes cperl, which is a direct (and some might say superior) fork of the mainline Perl 5 core, and I'm one of the few people who is not afraid to openly discuss the benefits of cperl. Second, in the future RPerl itself may also be a direct replacement for some-or-all of the existing Perl 5 core, which is again a threat to the old hulking dinosaur of code which is Perl 5.

So, as you can see, while I personally have nothing against the Perl 5 Porters, they apparently have open hostility toward ME!

I hereby officially challenge Sawyer to provide real proof that I have ever harbored hostility toward himself or his development team. (He will fail, because no such proof exists.)

The only "misunderstanding" is that fostered by P5P itself in an attempt to quash any alternative Perl development projects such as Perl 11, cperl, or RPerl.


Addressing "Anonymous" once again: Perl 6 has had over 15 years for people to play with it and create a few dozen blog posts. By comparison, RPerl has had maybe 3 or 4 years for people to even start hearing about it. Give RPerl another 12 years and I suspect we will be even farther along than the Perl 6 team is today.

HOWEVER, this is in no way a race or competition between RPerl and Perl 6. I have a huge amount of respect for Saint Larry and his Perl 6 development team. I am merely pointing out the double standard where we can give Perl 6 seemingly infinite time and money, but RPerl is to be thrown to the wolves.

This is both clearly unfair, and directly harmful to the future of the Perl community as a whole.

We need to stop attacking alternative Perl projects, and start embracing them as an integral part of the Perl's legacy and inheritance.

~ Will the Chill

Leave a comment

About TPF

The Perl Foundation - supporting the Perl community since 2000. Find out more at

About this Entry

This page contains a single entry by Coke published on April 4, 2017 1:19 AM.

Grant Proposal: Improving the Robustness of Unicode Support in Rakudo on MoarVM was the previous entry in this blog.

Maintaining the Perl 5 Core: March 2017 report is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


OpenID accepted here Learn more about OpenID
Powered by Movable Type 6.2.2