use Perl

I have no experience but I've considered it a few times. If I remember correctly it speaks HTTP/JSON like CouchDB so accessing via perl (or anything) is easy.

a few members of pdx.pm (including me) are working on a benchmarking framework with the intent of being able to build nice charts and graphs to show rakudo getting faster and to compare it to perl5. We're using the euler problem set just as an example for now but if you have specific specs that you would like us to hit I would love to hear them.

http://github.com/notbenh/euler_bench/tree/master

{after some poking from Eric Wilhelm I'll post this here as well}

I'm part of PDX.pm and we've started a project to collect solutions to euler problems as a way to benchmark rakudo. We would love to have you join in the fun. Currently everything is up on github (http://github.com/notbenh/euler_bench/tree/master).

I'm part of PDX.pm and we've started a project to collect solutions to euler problems as a way to benchmark rakudo. We would love to have you join in the fun. Currently everything is up on github (http://github.com/notbenh/euler_bench/tree/master).

You can simply enforce typing:

use Carp::Assert::More;

sub recip {
      my ($num) = @_;
      assert_nonzero($num);
      return 1/$num;
}

Then write one test to make sure that it works:

is( recip(2), .5 );

one to show that it dies correctly:

dies_ok sub{recip(0)};

and your done, any bugs that come up later can be tested then.


      package My::Map;
      #stuff

      package My::City;
      use Moose;
      has [qw{longitude latitude}] => (
            is => 'rw',
            #could make your own type, though for consistency
            isa => 'Num',
      );
      has name => (
            is => 'rw',
            isa => 'Str',
      );
      has map => (
            is => 'rw',
            isa => 'My::Map',
            default => sub {
                  use My::Map;
                  My::Map->new;
            },
      );

      #needless, but here for consistency
      sub setMap { shift->map(@_) };
      sub routeTo {
            my ($self, $targetCity) = @_;
            #stuff
      }


So the code is not that much different, Though you gain one big plus, type checking for setMap.

Our work setup is that everything runs thru a QA branch (trunk -> QA -> branch ). This is a patch for us not having a proper path to live so we just have a branch for stage. But this affords us a single path to trunk. So it would be feasible to merge to QA, run the fast tests on QA, if I feel good enough about my changes and I'm lazy then you can have a process that runs at night that:

• locks the QA repo (no more commits)
• runs the long tests
• if all passes then merge to trunk
• else email all the developers the output of the tests.

This doesn't make the wrong things wrong-er but it does make the right thing easier.

I think that my most common 'non-perl-ism' would be 'elseif', easily fixable but still annoying, though that said I think that perl is a flexible enough base that we ~could~ address most of these (though ~should~ is a very different point). So, whats the next step? Do we write a bunch of editor hacks that clean up our fingers output? Do we start writing modules that allow for such errors to become valid?