Three years ago someone asked the question "Is Perl still a useful, viable language?" on programmers.stackexchange.com. I'm not sure what would happen to a "useful, viable language" over time that would cause it to not be that any more - but I'm obviously biased.
The thing that I find intriguing is that the referrer logs for the Map of CPAN show that every day, at least one person follows the link from that question to the mapofcpan site. Every. Single. Day.
It's not even a particularly prominent link. How many people must be asking that question and finding that StackExchange page every day?
The P6SGI standard is progressing reasonably well now. There are a number of issues yet to be worked out it is a reasonably good start. However, before we can really be sure of that, we need an implementation that puts the standard to use and helps us find the warts as well as provides a way to get started working with it.
Perl has Plack. Perl 6 has Smack. So far, the basics of it's own standalone server are built and working and CGI is started. Some of the built-in apps and some standard middleware have been drafted, but there is a large amount of work to be done.
I have a regular job, 3 boys, and limited spare time. If you have any interest in helping work on the next generation of Perl application servers, your help would be most welcome.
I want a registry of environment variables. If I see someone using one, I want to know what it does and what code or programs uses that. Or, given a program, what are all the variables that might affect it?
Rather than do the whole thing, I let myself do part of the first bit. I crawled all of my installed modules to pull out the keys used with %ENV. My solution (here's the gist) does some dumb matching then passes the result to PPI. It's probably another easy step to make PPI find uses of %ENV too (and skip all the mentions in the docs).
Some modules define their own variables, and some of those are even documented. Many use variables that they expect you to know about already, such as $ENV{HOME}.
From just the stuff I had installed (about 20 different perls), here are the most frequent, with their count:
We've had another hackathon at work. This time Bosko, Bruno, Frederico, Yati, and I hacked on the Perlito Perl5-to-Java compiler.
We started adding unit tests - so that we can automatically extract a list of implemented features; the existing Perl tests are not properly organized "by feature".
I am pleased to announce that Enlightened Perl Organisation (EPO) has kindly extended the support of Strawberry Perl project by sponsoring our build server (VPS) for the next 12 months. I would like to thank Mark Keating for arranging the funding.
For those interested in technical details: the build server is MS Windows 2012 virtual private server, 4 CPU, 16 GB RAM, 120 GB HDD.
And just for curiosity: the server sits (at least they claim so) in the heart of Europe, in the neighbourhood of this beautiful gothic castle (it does not make it run faster but still...).
If you are also considering supporting Strawberry Perl project you can do it indirectly by becoming EPO member or via donating EPO.
I love Perl 6 asynchronous features. They are so easy to use and can give instant boost by changing few lines of code that I got addicted to them. I became asynchronous junkie. And finally overdosed. Here is my story...
I was processing a document that was divided into chapters, sub-chapters, sub-sub-chapters and so on. Parsed to data structure it looked like this:
YAPC is always a special time - for all of us. YAPC::EU was my first YAPC and no matter which YAPC I attend, I always remember it as the first YAPC I had (back in Italy), where I met Ovid, Aristotle, and other people I nowadays get to call friends, for the first time. It was my first community event.
I had not been expecting to attend YAPC::EU this year. In fact, I have never been to YAPC anywhere. But about a month ago, the announcement in Perl Weekly caught my eye. Skimming through the program of talks, I became more intrigued. The location in Granada also looked enticing.
The main obstacle was that I live on the southern tip of Africa. The journey would be long, arduous and expensive. Nevertheless, plans were drawn up, family and colleagues consulted, and funding secured. This was going to happen.
Twenty four hours after setting out from Cape Town, I arrived in Granada. Over the next five days I got various doses of Perl education, folklore, insights, whizz-bang craziness, and inspiration. I was also struck by the diversity and camaraderie of the Perl community, and the cultural richness of Granada.
But perhaps the most uplifting take-away for me was the realisation that Perl is a state of mind, an approach to problem solving, more than it is a particular language, and that this transcendent aspect will probably be as present in Perl 6 as it was in all the previous Perls. As I prepare for the long journey home with my bag of virtual goodies, it is this one that I treasure most.
The Swiss Perl Workshop was recently hosted in Olten, Switzerland, at the end of August, 2015. The Perl 6 team is targeting an official release by Christmas of 2015, and the workshop provided a great opportunity for core Perl 6 developers to complete a lot of Perl 6 development and training.
One of the last big changes before we're ready for Christmas is the Great List Refactor - an effort to improve performance, syntax and semantics of lists (especially lazy lists) in Perl 6.
At the workshop, we were working hard on the GLR - finalizing any outstanding design decisions, going through the ticketing system, the design docs, and the test suite. By the time the workshop was over, we were down to 100 failing tests (out of over 100,000), and the module installer (panda) was working with the newest version. Many new tests were added supporting the new behavior.
RPerl v1.1, codename 'Jupiter', has been released to CPAN!
Jupiter supports fully-automated compiling of the long-awaited N-body application software, which is a solar system simulator used by the Alioth Benchmark Game to rank programming languages by speed.
RPerl and the new PhysicsPerl software suite enable the N-body app to run at the speed of C++, dropping from over 19 minutes runtime to barely 13 seconds!
For now, see the INSTALL notes file for instructions on running N-body using RPerl & PhysicsPerl.
Also, take a look at the pre-release user documentation, Learning RPerl!
Please visit us on IRC for real-time tech support:
At this year's YAPC::EU, we've been having a blast in Granada, Spain, an incredibly beautiful city. The conference has been fun and Dave Cross gave a great lightning talk about Modern PERL (sic). These are devs who are using 5.8, often aren't allowed to use modules, and use CGI.pm for param handling, but print cookies manually. In a similar spirit, I present a subroutine from some client code. It's here with their permission, and it's one of reasons they've hired All Around The World to fix their system. Pay close attention to the sprintf lines.
About a year and half ago, the CPAN community started to join Gratipay (formerly known as gittip), possibly under the influence of this post and that mashup.
Since then, laws and regulations have caught up with Gratipay, forcing them to radically change their model
(there's something to be said about doing a little bit of bibliography/research on the problem area before diving into the code).
So if you joined Gratipay at that time, and received some tips, you should read this.
Since receiving co-maintainer for BZ::Client about a year ago, I have been gradually sprucing things up with code style tweaks, including patches from RT etc.
Over the last few days I've gotten quite stuck in, taking the time to convert to Dist::Zilla releases, tweaking and stripping out a lot of Pod (left to Dist::Zilla to insert), removing subroutine prototypes. Which has resulted in a couple of new minor releases interspersed with dev releases.
Version 5.0 of the popular bug tracking software Bugzilla was recently released and in so doing sent the 4.0 series to EOL. It's actually one of the few examples of software that RedHat has not re-written in Python (then started rewriting yet again in Ruby)
If you're at YAPC::EU, please blog about the conference and your experience, and preferably do that before the end of this weekend: (1) the thoughts are still fresh in your mind, and we'll get your raw unedited thoughts, and (2) you stand a better chance of getting a mention in PerlWeekly :-)
Once you've published your blog post, tweet about it with the #yapceu and #perl hashtags — that will increase your audience. For extra credit, please add a link to your blog post on the list of blog posts.
Writing your own commify function may well be right up there with writing your own web framework or templating system. Most of us have done it and it probably wasn't worth the effort. Enter CLDR::Number. (I should note here that it's not obvious from the name that this module will commify for you -- that's one of the reasons I'm writing this up.)
A long while back (I’ll find the reference if I can) Stevan Little, author of Moose, commented that part of what he wanted for a p5mop was the ability to have truly private data in classes. Much in the way Perl 6 has $!data attributes that are simply private data, he wanted to just be able to use Perl’s regular variables in this same way.
I took this as a bit of a challenge and several iterations later, I had a working system. I then spent months trying to decide if I wanted to put it on CPAN. I kept weighing utility vs practicality. Though it is an interesting thought exercise, I have no idea if its a good idea.
