If you have a Perl-related news item you'd like to share, you may post it in the Perl Newssection.
Please try to avoid duplicating news; but pointers (with summaries) to important stories on other sites are acceptable here.
The Type::Tiny 1.1 (1.001_00x) development cycle has been going on since September 2014. Apparently I'm either very concerned about stability or very lazy. You can make up your own minds about that.
But Type::Tiny 1.2 should be released in a few weeks. If your application uses Type::Tiny, you may want to download the latest development release and check that nothing breaks. (It shouldn't, but you never know until you try.)
The headline changes are:
Type::Params now has compile_named and validate_named.
Type::Tiny's constraint parameter may be a string of code.
Fixed bug where Types::Standard::Int would sometimes accept an overloaded object. (It never should.)
Various performance enhancements and bug fixes.
I'll explain the first two in more detail, because they're interesting.
Type::Params is a module for type-checking the parameters to functions. For example, specifying that the $quantity parameter should be an integer. It was mostly written with positional parameters in mind, like eat_apples(2, "red").
Named parameters like eat_apples( quantity=>2, colour=>"red" ) could be made to work, but it was a bit of a hack. The Type::Tiny 1.1 development versions introduced a better way of doing this. It's not only neater, but it provides better error messages and it benchmarks a lot faster. Below is some code showing the old way and the new way.
Normally when creating a type constraint, you'd provide a coderef which checks the variable $_ to see if it should pass the constraint. Recently the development versions of Type::Tiny have started accepting a string of Perl code instead. This can not only lead to very concise code, but is an easy way to allow Type::Tiny to optimize its checks. (You can manually optimize them even better by telling Type::Tiny how to inline type checks, but that requires a little bit of extra effort.)
The German Perl Workshop is an Open Source conference for everyone, organized by community of the Perl Programming Language yearly in Germany. The 2017 GPW takes place in 21107 Hamburg, Mengestraße 20. The Venue is called Bürgerhaus Wilhelmsburg. Most of the talks will be held in German, but talks in English are welcome as well of course.
The workshop starts on June 25th with the preconference meeting.
For accompanying family members with we have organized a partner program on the 3 conference days.
The Perl Developer Survey ran from 7th of March to the 14th of April, 2017. I hope you took part! The results have now been published:
part 1part 2
I find the results intriguing, but since this was a self-selected (not random nor representative) sample, it's quite hard to generalise the results to the overall Perl developer population. Did you take part? Do you find yourself in the pie charts?
Along with the clone feature I added last cut that allows you to clone instances for specific projects/purposes, this new version provides a fetch command that automatically updates the Perls that are available, displaying the most recent point release available for each major version.
If any of your existing installed versions don't match what available lists, we'll automatically register those instances as custom, which allows them to continue to be maintained by berrybrew.
Here's the full blog post.
I applaud this decision by Github, as it allows expression to be expanded without fear. I do understand the concern that an employer could have (as I did run a few small businesses), but hacking out a few lines of code while at work during a break, for Open Source projects shouldn't be claimed as corporate IP.
This is a thing of opinion depending on the reader, but I digress. I am totally in favour.
This was posted at Perl is dead over on blogs.perl.org with that title (here's the actual follow-through link to the real article). The title is over the top, but this topic has been brought up here recently, so I thought I'd put it here for our mathematicians/statisticians and other interested Monks.
Personally, I don't care. I love Perl, and likely always will. I have learned other languages while knowing Perl, but as I learn other languages, I just learn new ways to incorporate what I know into Perl. Learning new things and incorporating them into experience I've gained is how I approach everything anyways.
And in my estimation, the recent, highly publicized StackOverflow analysis is probably severely flawed because once all the popular questions are answered, they generally never have to get asked again and so fewer questions would have tags from languages that have been around awhile. So their analysis would skew toward brand new languages. Using GitHub would seem to be a much more accurate sample method.
it is my pleasure to announce that O'Reilly has posted an early release (i.e. incomplete and not fully edited version) of a new book on Perl 6:
Think Perl 6 - How to Think Like a Computer Scientist
by Laurent Rosenfeld (with Allen B. Downey)
Early Release Ebook ISBN: 978-1-4919-8048-4 | ISBN 10: 1-4919-8048-6
At this point, only the first seven chapters (about 150 pages out of a total 450 pages) are publicly available as HTML. The book is fully written, the rest only needs to be processed in O'Reilly's editing process, which should take another few weeks.
If you want to learn how to program and think like a computer scientist, this practical guide will get you started on your programming journey with Perl 6, the new version of the popular programming language. Ideal for beginners, Think Perl 6 contains numerous exercises with multiple solutions and over 1,000 code examples. Even experienced programmers will learn a lot from this book, especially those familiar with Perl 5.
In an interview with LinuxVoice (July 2015), Larry Wall said: “We do think that Perl 6 will be learnable as a first language.” Hopefully this book will contribute to make this happen.
If you see anything that would need to be corrected or that could be improved, please kindly send your comments to the following address: think (dot) perl6 (at) gmail (dot) com.
In my interpretation, the discussion moved on from removing restricted and locked hashes towards realizing that restricted and/or locked hashes can get a different hash implementation in the backend than plain hashes and maybe even plain hashes can get different implementations. This makes me somewhat happy because I really like using locked hashes for DBI query results and don't really care for the (potential) performance overhead.
Other people see a benefit in removing the performance overhead incurred by supporting restricted hashes, which I don't know about. But as these people know more about the internals, I'm inclined to trust them on their judgement as well.
Allowing different implementations of hashes opens up the interesting question of if or how a hash can move from one implementation to another, and personally I expect that only to happen for explicit assignments:
use feature 'superfast_hashes';
my %hash_with_implementation_A = ( foo => 'bar' );
no feature 'superfast_hashes';
my %hash_with_implementation_B = %hash_with_implementation_A;