Perhaps in about 2 years time when Debian Jessie becomes stable, with perl 5.20 as the system perl, but working under a grumpy sysadmin who refuses to install any Debian or CPAN package without a request in triplicate and a 6 month evaluation period.

Don't laugh, admins like that exist, and it is no fun trying to get any work done on a system they control.

• reduce the maintenance burden of the core to fit the available volunteer effort
• reduce the effort and quality put into any specific piece of the code to match the increased size of the code

In other words, the decision is very likely between yearly releases with bugfixes and optimizations and improvements or keeping things like CGI.pm as a core library. Even "core library" is a misnomer, as it's been a dual-lived module for a long time. At least with the yearly releases, people who don't use the CPAN will eventually get bug fixes and improvements to CGI.pm every five years or so, when their administrators get around to upgrading, but is that really the dominant use of Perl that the p5p development process should optimize itself for?

I agree that CGI has not been best practice for a long time, but it was best practice for a while because the alternative was to parse and http queries and generate html entirely by hand.

Most of have worked in environments where external modules are forbidden, either because management is excessively risk adverse, or because the hosting company charges extra for installing non core modules.

Much as we in the perl community hate these backward working practices that don't embrace CPAN, they continue to exist and won't go away. We need to support those unfortunate users who have to work within such constraints.

For this reason, I think that if CGI.pm is removed, we ought to replace it with something else that is lightweight and represents best practice. My vote would be for Plack as it is small, has few dependencies, and is easy to enable in Apache (via Plack::Handler::Apache2::Registry). Idealy we should also add a templating module as well so that Plack users don't have to fill their pgsi with big blocks of sprintf to generate their html.

The only problem is having this over and over in test files: "Boilerplate Considered Harmful". How about moving this into Test::Simple or Test::More, or a module of its own, Test::Some.

I would suggest exporting a single routine, run_some(), which contains the innards of the if() block. Then all a user needs do is to begin main with

     return &run_some if @_;

or the more verbose but digestable

     my @args = @_;
     return run_some( @args ) if @args;

Of course, that means main() is a boring list of tests to run. Test::Some could supply that main() if it was requested to in the use line. The user would only need to invoke main(), passing an arrayref of the test file names, in the order they should be run, followed by \@ARGV.

Your comment is so true: "having useful information is important, but presenting that information in a way that's easy for machines to interpret is just as important".

The $sql is what should be passed to DBI's prepare method, not $sth.

$ perlbrew install 5.16.1 --as 5.16_threads -Dusethreads

$ perlbrew upgrade-perl

$ perl5.16.1 -E 'say for map m|5.16_threads/lib/(.*)|, @INC'

site_perl/5.16.1/i686-linux-thread-multi

site_perl/5.16.1

5.16.1/i686-linux-thread-multi

5.16.1

$ perl5.16.3 -E 'say for map m|5.16_threads/lib/(.*)|, @INC'

site_perl/5.16.3/i686-linux

site_perl/5.16.3

5.16.3/i686-linux

5.16.3

site_perl/5.16.1

site_perl

As you can see, my precious site_perl/5.16.1/i686-linux-thread-multi is gone...

http://www.youtube.com/watch?feature=player_detailpage&v=8kotnF6hfd8#t=2693s

Couldn't you just change your diag line to instead be:

$DB::single = $ENV{DD_DB};

Then still do your local $ENV{DD_DB} trick? I usually make a variable in the $DB namespace, e.g.:

$DB::single = $DB::stop;

I'm not sure local will be very different but is an interesting idea.

What it says matches my understanding: that hash algorithms operate on bits which are easy to get from bytes. But if you have text, then you need to encode it as bytes before you hash. The hashing should be treated like another output.

I'm wondering why you opted for doing the hashing in the database. I would have opted for the other way, if only to minimise the layers that have access to the raw password.

On further thought I would strongly disagree with hashing in the database because your application now relies on an assumption that you don't actually know. What if that assumption changes with database versions? Or maybe the assumption is actually being made inside DBI or DBD::Pg?

A final comment is that at my work we had some bugs caused by differences in date manipulations between the database and perl. So it always pays to be extra careful when you have two different layers attempting to perform the same action.

I believe that the 'Pumpkin Perl' proposal meets every requirement you've given (with the possible exception of "why aren't you using a bigger cluebat", though "because I think I can get permission to wield this one" is the answer to that, as to most "why not name X?" questions).

The breakdown of the what, the why and the who, and a run through of your checklist is up on my blog.

http://perl5.git.perl.org/perl.git/shortlog/refs/heads/dagolden/revive-strictperl

Note to readers: I'm not advocating this as a default anytime soon. For the moment, I just want to use it as a tool to explore what in the Perl core isn't strict-friendly, so that sometime in the future, that decision is at least an option.

https://metacpan.org/module/LOGIE/Lucy-0.3.2/lib/Lucy/Analysis/Normalizer.pod

[0] http://www.unicode.org/faq/normalization.html

1b. Maybe you should use both. (Both 's' and "\x{1e69}" should probably match "\x{1e9b}\x{0323}", to use the Figure 9 example from the Unicode note.)

2. If somebody did a version of the NFK?[CD] routines that did not normalize singletons, then I would be happy. Never understood this bit. To my mind, \x{ef} and \x{69}\x{308} unambiguously carry the same _meaning_, just as surely as \N{ANGSTROM SIGN} and \N{KELVIN SIGN} has a different (more precise) meaning than \N{LATIN CAPITAL LETTER A WITH RING ABOVE} (Å) and \N{LATIN CAPITAL LETTER K} (K). For a scientific search capability I worked on we had to go through hoops like you wouldn’t believe….

There is a module for "Mac" normalization http://search.cpan.org/~tomita/Encode-UTF8Mac-0.03/lib/Unicode/Normalize/Mac.pm

BTW Maybe for search it's better to use NFKC/D form ?

use Unicode::Normalize;
use open qw/:std :utf8/;
use utf8;
print NFKC("₉") eq "9";
print NFKC("⁹") eq "9";

(prints two true values).

This way you can, with appropriate comparison level, find "naïve" by searching for "naive". Isn't that a win?

has 'typo ', is => 'ro', default => 'oops';

over some of the alternatives, such as

has typo => ( is => 'ro', default => 'oops' );

I don't have a lot of experience with Moose (unfortunately), but to me that small alteration looks like a win in both readability and automatic error detection (due to the parser, such as you mention).

The bad thing is when the core has to change for other reasons, and those modules break. Method::Signatures? PadWalker? EndOfScope? Coro? The core supports what these people wanted -- not always well, but enough -- and they made it happen. And now they're effectively part of the language. I wouldn't want Perl without M::S and Coro and AnyEvent and a dozen other modules that really are effectively Perl 5+.

But this comes at a price. The failure modes are second class citizen status, bit rot (when the core devs don't care about breaking the modules), and fossilized internals (when they do).

That line is, in practice, much blurrier than I make it sound--you're absolutely right about that, but I do think that Squeak/Slang demonstrate that it's possible.

OTOH their core model was created by and for mathematicians, so its orthogonality puts even Python to shame. With that foundation, adding syntactic sugar is reasonably most of your activity.

use 5.010;
package MyClass;
my $handle = 123;
sub transaction(&) { say "begin"; shift->(); say "commit ($handle) "; }
1;
package main;
my $handle = 345;
MyClass::transaction {
say "aha"
};
1;
__END__

begin
aha
commit (123)

(tested on 5.10.1)

MyClass->transaction {
$myobject->mymethod($args)
}

looks more elegant than ordinary

MyClass->transaction(sub {
$myobject->mymethod($args)
})

Ideally I need to find some time to peruse Filter::Keyword[1] (not yet on CPAN) to inline-rewrite try/catch invocations into the corresponding eval. Then Try::Tiny will be truly useful again.

[1] http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=p5sagit/Filter-Keyword.git

With this I cannot disagree.

> When those conditions are true, I think this code is clearer

Disagree.

# perl 5.10+
MyClass->transaction {
$myobject->mymethod($args)
}

looks clearer.

1) transaction code is most likely should be class method, not instance method. if your class (not object) does not
contain required data (i.e. database connection handle) to perform the transaction, it's just implementation problem.

2) method name has no meaning without object, and in your example it's passed as separate argument.

btw, in Ruby such things always implemented like

transaction do
...
end