Today on StackOverflow, an old thread popped up that prompted me to answer. That answer became a slightly longer compendium of recent developments in Perl and Perl-for-web.

I will copy the text here, but I am asking you to vote it up so that it will show for future viewers. So that I will not be getting undue points, I have made it community wiki (also means you can amend if you want).

Vote here: http://stackoverflow.com/a/8828209/468327

== Post Content ==

This is an old question, but I thought I should update the readers. I am happy to report that in my opinion Perl is more viable for web development than ever! Along with old friends Catalyst and (recently revamped) Mason, there are some great new entries Mojolicious (or visit mojolicio.us) and Dancer. I’m sure there are others too.

Perhaps the biggest improvement is PSGI/Plack (or visit http://plackperl.org/).

PSGI is an interface between Perl web applications and web servers, and Plack is a Perl module and toolkit that contains PSGI middleware, helpers and adapters to web servers.

With these improvements have come more cloud hosting platforms: for a couple examples read more here.

Perl itself is experiencing a renaissance of sorts. Between Moose object framework (and lighter clones like Mouse) and the ideals of the Modern Perl movement (readability while using modern best practices), Perl seems to be growing and its users are excited and motivated.

Personally I have been enjoying Mojolicious. I like its built-in servers and templating engine. I also like that you can make a Mojolicious::Lite application in a single file! That said I really haven’t played with Dancer or other frameworks, so if you are coming back to Perl or new to Perl, I would encourage you to take a look at those too.

In closing Perl-for-web has come a long way since CGI.pm. If you’ve been away for a while, its worth another look.

I use Moose to write scientific simulations, including one very large simulation with a user api. To this point all of the numerical quantities, kept in attributes, needed to be of Num type. This always meant an implied covenant between the me and the users, which was to use SI units.

However I have a few quantities that I want to use eV units, which makes a lot more sense. Therefore I setup a simple type with coercion to accept a string num eV and coerce it to a number given by qe * num. This got me to thinking, why can’t I do this for all my units?

To answer this need, I present MooseX::Types::NumUnit which provides a couple static types, but also provides the function num_of_unit, which creates anonymous types which will automatically coerce a string to a number of the desired unit. For example:

package MyTest;

use Moose;
use MooseX::Types::NumUnit qw/num_of_unit/;
#$MooseX::Types::NumUnit::Verbose = 1;

has 'length' => ( 
  isa => num_of_unit( 'm' ), 
  is => 'rw', 
  default => '1 ft'
);
has 'speed' => ( 
  isa => num_of_unit('ft / hour'),
  is => 'rw', 
  required => 1 
);

no Moose;
__PACKAGE__->meta->make_immutable;

my $test = MyTest->new( speed => '2 m / s' );

print $test->speed, "\n";
print $test->length, "\n";

__END__

prints:
23622.0472440945
0.3048

Now my users can use whichever units they want, and I know that my simulation will see the number in the units system that it needs!