OTOH JSON is simple, easy to parse and totally sufficient for what we need for the meta data.

About the module itself: There are various policy modules these days, for example Modern::Perl. I have mixed feelings about them:

For one I understand the desire to write less boilerplate code, but on the other hand it's more stuff to install, more things to remember when reading the code (does Modern::Perl enable strict refs? what about common::sense? Why not both?)

Oh, and I don't like the name. common::sense sounds presumptuous to me.

If one of those policy modules turns out to be widely adopted, that will be less of a problem though.

But all in all these policy modules show me one thing: Perl 5 as a language doesn't follow the needs of application developers close enough. It can't, because it has to preserve backwards compatibility. It is turning from a programming language into a programming platform, where policy modules, OO frameworks (Moose) and other modules shape the language.

This can be seen either as bolting on, or as a proof for Perl's flexibility - it's probably both.

In terms of language evolvement I see Perl 5's future in being a programming platform - programming language feels a bit like a dead end.

Update: I also think that policy modules should document their target group very clearly. For example common::sense excludes some strictness and some warnings, which makes me think it's not intended for the novice, but rather for the experienced Perl programmer. Still it would be nice to see that in the documentation.

"It would be nice to see that in the documentation". <quote from the docs> "This module is aimed at experienced Perl programmers, not people migrating from other languages who might be surprised about stuff such as "undef"." <unquote>

You're right, I should have scrolled all the way down, I just lost interest while skimming over the quotes.
Perl 6 - links to (nearly) everything that is Perl 6.

Thats what I wanted to know. It was supposed to be in meditations but somehow ended up in perlnews. It does use less memory than strict/warnings :)

Because you didn't meditate. And you didn't even make it clear that you were seeking wisdom from others. You just pointed and gesticulated.

As for the module, I was struck with the author's need to include the quotes. It struck me as a demonstration of "I'm so arrogant, I'll include the quotes decrying my arrogance to demonstrate the input I was able to effectively ignore due to my arrogance." Meh.

The module name sucks. All-lowercase. Invents a new top-level namespace that sucks as a top-level namespace. The name maxes out on cuteness at the expense of giving the audience a good clue as to the purpose of the module.

If it were even called Devel::CommonSense, then I'd have little criticism to offer.

Update:

It does use less memory than strict/warnings :)

Actually, for the vast majority of the Perl world, it uses more memory, because it doesn't prevent strict/warnings from being loaded. So, in the author's mindset, it kills trees and kittens... perhaps just not his trees/kittens. Lousy justification.

The customization of warnings is the interesting part. Not something I'll use myself for several reasons.

I disagree that making warnings fatal is a great idea. Even if it magically only makes bugs fatal, I expect it to be a mixed blessing. Fatality can be useful in making bugs extra obvious, forcing them to be fixed (or at least worked around). But warnings are not particularly hard to notice so the added benefit of fatality during development / testing is not clear-cut. Meanwhile, continuing on past a subtle bug can be useful once in Production. The problem with warnings is that they tend to depend very much on context so fatal errors like those exposed by strict.pm are almost always found during development and testing while warnings are much more likely to survive to Production, IME. And a fatal warning is almost always a serious impact in Production while the subtle bug is often the better choice. But it is a good experiment to try.

Also, the module's role is unsettled. If I started using it now, an upgrade to it could easily take a warning that was previously being ignored and instead make it fatal.

The horrid name and the section devoted to demonstrating the author's arrogance are also among the reasons I'm unlikely to use it, of course.

Update: Oh, and I also often (usually, these days) program in a mode where 'undef' warnings indicate a mistake. Yes, the signal-to-noise ratio of that particular warning is likely the worst of any Perl warning. If you didn't consciously choose to use 'undef' as an indicator of "I forgot to initialize that", then it is an annoyingly useless warning. Even when you've made that choice, it does it's best to tempt you to unmake that choice.

But even more so I wish I could use autovivification as an indicator of a mistake. I often (usually, these days) program in a mode where autovivification is a mistake. I just can't convince Perl to tell me when it resorts to autovivification. I've long wanted a "no autovivification;" pragma.

Actually, one should have the choice to make it always fatal or just make it always a warning, including controling whether using undef as a reference in a non-lvalue context should be considered a fatal "symbolic reference" under "use strict 'refs'" (as the module's author rightly complains about).

I guess that is another place where I disagree with the module's author. Although I sometimes dislike that "use strict 'refs'" makes that particular form of autovivification fatal, I don't consider it worth throwing out the "use strict 'refs'" baby to get rid of that particular autovivification bathwater.

- tye