If my thesis is correct -- that much of the work done on the Perl language, the Perl culture, and its ecosystem including CPAN in the past ten years has made the language easier to use and Perl programs more maintainable -- then Perl fans have a lot of work to do to overcome the weight of bad code and creaky tutorials found in the wild.
Browse PerlMonks for ten minutes, and you'll see that many petitioners receive the useful advice to use the strict and warnings pragmas in new code. Similarly, I've started all of my recent tutorials with the line use 5.010; to take advantage of say, given/when and other new syntactic features. Add to that some of the nice CPAN code which extends the language and adds even more great features....
... and the result is that a "modern Perl program" will contain at least three and probably several lines of identical boilerplate code which serves only to enable nice new features to make it easier to write powerful, effective, and maintainable Perl programs. Worse yet, many of these features should be on by default.
Do you really want to tell people that they should use say instead of print ... "\n" because the former is shorter and more concise and more convenient if you have to explain that they have to use the feature pragma to enable it explicitly?
I wrote a proof-of-concept module called Modern::Perl to solve this problem. It has five lines of code. Add use Modern::Perl; to your program and it will automatically enable the strict and warnings pragmas, and will make available all of the features of Perl 5.10.
There's still more than one way to do it, but isn't that easier than telling people to copy and paste long lists of modules to enable great features that should be available by default? Surely modern Perl should minimize copying and pasting and should remove artificial barriers between novices and experts.
A nice idea although I don't see it being very useful unless it becomes core. Yes, installing CPAN modules is an important part of Modern Perl but probably not the first thing you want to teach in a tutorial.
Also, I assume that you are familiar with Toolkit?
use Modern::Perl;
Thats an inspirational idea! Well done.
/I3az/
use utf8 is also important thing along with strict and warnings.
why not creating an open book, like
http://www.djangobook.com/
I like the idea of Modern::Perl. I even added it to a program I'm writing just to try it out. Today I got to thinking about it though... I have perl scripts from 10 years ago that still work fine. They don't have "use strict" in them because I wasn't into that back then. They're not modern, but they *do* work and they've kept working even though I haven't touched them in years and years.
So, what is Modern::Perl going to do when the next pragma or module gets elevated to "best practice" status by the community? If you don't add it to Modern::Perl then the name isn't correct. But if you do then the script I just wrote yesterday is possibly going to die when perl 5.13 (will perl 6 be out by then? :-) adds a new keyword that conflicts with my code...
Perhaps the solution is:
use Modern::Perl 2009;Which locks my code to the best practices of 2009. The idea behind the years is that ideally best practices are determined slowly and are so the granularity of one year should be reasonable. And what happens if in August every new module in CPAN is using Moose and so it should clearly get added to Modern::Perl? Well, I think instead of adding Moose to 2009, you add it to 2010 which will keep 2009 frozen and give the people on the edge a little taste of being in the future by writing 2010 when it's still a few months off.
Some of your articles make it sound like you have a thing against backwards compatibility, but the more I think about it the more I feel I can't use Modern::Perl unless something like this is in place.
I use Modern::Perl v. 1.02.
And I have the warnings: "v-string in use/require non-portable at /usr/lib/perl5/site_perl/5.10.0/Modern/Perl.pm line 18".
Modern/Perl.pm includes strict/warnings pragmas twice.
Please, fix it.
Using Modern::Perl in your code seems more like setting a contract than grabbing some convenience. It's easy enough to make a wrapper for your favorite modules or use a little templating magic in your editor. By using an external module, you're explicitly declaring that you plan to maintain your code according to that module's standards. This is chromatic's module, so those standards are probably quite reasonable. However, if you are concerned about the rules shifting under you in the future, maybe you should have your own Modern::Porkrind (or whatever) contract for your projects. The concern is valid, but I think there are solutions beyond imposing any granularity on the particular contract in Modern::Perl.