This grant request is a must do!
I've been reading up on RPerl for some days now, and mailing with Will Braswell, mostly about the documentation and examples. Last YAPC::NA in Salt lake City, I got a demo of what he was doing. It looks impressive, and I think it has potential for both Perl 5 and Perl 6. I think this proposal is a nice one and I hope TPF will fulfill this grant.
Will is a brilliant developer. Not only do his RPerl projects deserve support for the potential they offer those who need performance enhancement, but he is extremely knowledgeable in all things Perl and does a lot for the Perl community including me. Though I have yet to ask I hope he involves me in his documentation efforts, it may be a way for me to begin to give back, I am looking for this kind of opportunity.
vote for!
Better docs will bring more people to RPerl and potentially attract more to Perl in general. I vote for this.
RPerl is one person, just one person. Deliverables for something as complicated as RPerl are hard to define. When is RPerl done? The architect and the coder are the same person. The specification and design can be changed prematurely, just to finish a task sooner since a grant is involved. Documentation can be easily measured and debated as to its quality and completeness. However, the code behind RPerl is difficult to objectively rate for anyone but Mr Braswell. Thus I, one anonymous voice in the crowd, say that this docs grant is the best one of the three submitted by Mr Braswell.
Many thanks to everyone for showing TPF there is a Perl community mandate to fund RPerl now!
I set each of the RPerl grant proposal dollar amounts as low as possible, so TPF may feel comfortable with awarding all requested funds this quarter.
If TPF follows the community's clearly-established vote to approve multiple RPerl grants, then it is likely I will choose to work on this particular grant first in chronological order.
I have received a few questions about the relationship between these TPF grant proposals and the currently-live Kickstarter campaign. I wrote a response to Karen Etheridge here, pasted below for your convenience:
The TPF grant requests are different than the Kickstarter.
Specifically, there are 3 places that may be confusing:
1. Operators
The Kickstarter page states it will be used to implement "Different Operators Than TPF Grant Proposal If Approved". There are tons of operators in Perl 5, more than enough to fill a dozen grant requests. No double-dipping (paid twice for one job) occurs.
2. Benchmarks
The Kickstarter page states it will be used to implement a "Different Benchmark Than TPF Grant Proposal If Approved". There are about 15 benchmark algorithms listed on the Alioth website, again more than enough for a dozen grant requests. No double-dipping occurs.
3. Medium-Magic Support
If we reach $75K on Kickstarter, then I will be personally funded to work on the many different aspects of supporting medium-magic code. One sub-component of this would be the medium-magic grammar, as described in the TPF grant proposal by Paul Bennett. It is very, very unlikely we will reach $75K this round on Kickstarter, but even if we do then that money would go to me, whereas the TPF money would go to Paul Bennett, so you would have 2 guys working in cooperation to complete the software instead of just 1. No double-dipping occurs.
https://www.reddit.com/r/perl/comments/3er9u2/anyone_got_opinions_about_rperl_i_cant_tell_if/
Are these issues still outstanding? Shouldn't they be fixed first? No regex? No auto-vivification?
Anon, to answer your questions:
Are these issues still outstanding? Shouldn't they be fixed first?
That reddit thread was created not long after RPerl v1.0 was first released on CPAN, we are now currently at RPerl v1.1 which fixes a number of the installation and usage issues.
On an operating system with decent Perl support (such as Ubuntu), you can install RPerl by simply typing the command `cpan RPerl`.
You can see all the various bug fixes since v1.0 hit CPAN:
Changelog
Commits
No regex? No auto-vivification?
RPerl v1.x has always been clearly advertised as supporting a low-magic subset of Perl 5.
RPerl is similar in name and principle to RPython (Restricted Python) and NQP (Not Quite Perl 6).
RPerl must start somewhere, and that somewhere is by-necessity the low-magic restricted subset of Perl 5 which we currently support with RPerl v1.1 on CPAN.
Interested in initial support for medium-magic code? Paul Bennet and I are already in the planning stages.
Interested in initial support for regular expressions? Help us raise $30K for RPerl v2.1 to be developed.
Then isnt RPerl fast just because it can do far less things? How will it benefit Perl 5/6 users? Why don't u patch 5/6?
Anonymous, to address your questions...
Then isnt RPerl fast just because it can do far less things?
I already answered this question:
RPerl must start somewhere, and that somewhere is by-necessity the low-magic restricted subset of Perl 5 which we currently support with RPerl v1.1 on CPAN.
Interested in initial support for medium-magic code? Paul Bennet and I are already in the planning stages.
Interested in initial support for regular expressions? Help us raise $30K for RPerl v2.1 to be developed.
So again, RPerl v1.x is limited in functionality, future versions of RPerl will expand the functionality.
How will it benefit Perl 5/6 users?
If you like to write code using Perl 5, and you want that code to run fast, then RPerl will benefit you by both saving you a tremendous amount of effort, and by running super fast. Perl 6 users will benefit from future versions of RPerl.
Why don't u patch 5/6?
As stated previously:
RPerl is similar in name and principle to RPython (Restricted Python) and NQP (Not Quite Perl 6).
Both RPython and NQP were built to facilitate the (re)writing of their parent language for speed and maintainability. RPerl will be used for this purpose in relation to it's first parent language, Perl 5. After all of Perl 5 has been upgraded ("patched") to work with RPerl, then we can move on to address Perl 6.
...
Does that satisfactorily answer your questions?
I know it's after the comment period, but I just realized this: A very useful document would be an RPerlification case study. Start with Some::Beloved::Module, factor out Some::Beloved::Module::LowMagic for RPerl consumption, and show your work so that other module authors can feel encouraged and learn the ropes.
Bonus publicity if the module's maintainer is willing to make your version official. "Yeah, everyone uses this, and RPerl sped it way up. Like XS, but without the eldritch horror."
Why don't u patch 5/6?
Because it will be instantly rejected by Rik and his cabal which are way too conservative to ever let in something this disruptive.
I would like to add that this opinion was raised by one of the committee members.
The author seems to think that Perl has a big problem with runtime performance, and that this is holding back adoption. I don't see it. And Perl does quite well on the Alioth benchmarks already. It beats Ruby and Python 3 at most of them and ties PHP.
There might be some use for this in number-crunching applications, although PDL is probably a more obvious choice. There are a number of projects like this for Python and they don't seem to get any use outside of scientific and big data work, but it would be nice to have one of our own if it was reliable and well-documented.