Sunday, May 31, 2009

The promises of Parrot?

I own both Parrot / Perl 6 books. I'm totally aware that they're totally out of date now, but I'm curious how much of the "original" ideas are going to hold on?

1. If you have a "Python" library, can you compile that to parrot bytecode, and then import that into Perl6 transparently and use it transparently in your Perl application?
2. Is the garbage collection system going to support a fallback "reference counted" system? Perl seems to have a "constant" burn (when it comes to memory management) that doesn't hiccup like Python, Java or .NET seems to have (without some tuning of course).
3. Will we ever be able to truly "compile" a Perl application into a binary (without statically linking the entire Parrot system into the executable?)
4. Guys that I work with claim that Parrot will fail to "be the best" because it's not based on LLVM, and because everyone else (Google, with unladen swallow) is playing the "Not invented here" card, instead of helping out Parrot. Competition is good, but it seems that Parrot / Perl has NO friends out there, did somebody burn some bridges or something?

High precision timestamps in Perl5/Perl6?

Why does Perl5 and Perl6 chop off a digit of precision on a high precision time call?

use strict;
use Data::Dumper;
use Time::HiRes qw( gettimeofday );

print gettimeofday() . "\n";
printf("%f\n", scalar(gettimeofday()));



And, in Perl 6...

say time();
printf("%f\n", time());



Perl 6!

I feel bad bugging people for help with Perl 6, especially when you're simply trying to compile the damn thing. Chromatic goes on and on about how doing lots of releases is really important for something to be viewed as "alive" and "progressing". I dunno. I waited with glee for the Parrot 1.0 announcement to go out, and then fumbled until this last week to get Rakudo running on my mac. No big deal, I'm an early adopter. I believe in Perl, and I know that it is going to rock when it's finished, so dealing with the headaches to get it set up are worth the trouble. But, not everyone is like me.

Anyway, I just wanted to point out this one VERY cool thing (in my eyes) that was like the second or third test program I wrote.. Heck, I'd love to make this into a test for the test suite if it isn't covered... (it addresses a weakness that Perl 5 had, that was documented)..

my $foo = "1f9";
say $foo;
say $foo;

This spits out...
A perl 5 equivalent will say...
But Perl 5 supports a simpler increment system (sort of)...

$foo = "f9";
print $foo . "\n";
print $foo . "\n";
This dumps out:
Hooray Perl 6!

(I found the test for this, it's S03-operators/autoincrement.t, it doesn't cover the "1f9" case, which doesn't work in Perl 5). I'll see if I can get commit bit access to this test next week!

My heretical love for compile time safety...

I have to admit, as a first blog post, this one may not be the best to introduce myself. I program in Perl, every day, mostly for work, but it's cool work none the less. I work in the financial industry, with nearly 13% of the US Stock market coursing through my models . We use lots of Perl to get lots of things done. Having only really seen Perl used in a web environment, I was blown away to see what Perl is really capable of.

I have always been a "use strict" guy, like many of you who would read this I have the t-shirt from thinkgeek with that on the front. My current position introduced to a module called "fields". It took me a while to appreciate it, and it was really only after I started writing code where I wasn't using it did I realize how awesome it is.

The point of my post is, quite simply that Perl fills a niche that no other scripting language (that I have seen) is capable of doing. It provides compile time safety on variables, as well as attributes of objects. People have accused me of having flimsy testing suites, and my only reply to that is that my codebase is so incredibly big (and most of it inherited from previous engineers) that we MUST know about the possibilities for a mistake, and are willing to pay any price to find out before we deploy. This simple validation of any changes we make drastically reduces any errors, and provides a cushion for any code path not covered by a regression or unit test.

I'd really like to be able to have compile time safety of methods, as well as their arguments, the closest way to seem to be able to do this, typesafety doesn't work at all for me, on my mac or on a linux box. I'm told that Perl 5.10 (which we haven't upgraded to yet) has a new method resolution system, I'm hoping there may be a way to override the whole thing and disallow sub-routine generation at runtime so I can do compile time checks. It may be just one big pipe dream, but we'll see.

So there you go. Fields is awesome, and it looks like this whole Moose thing kind of glosses over this, so I imagine that Perl 6 will as well, (if I'm wrong, please point this out!). Hash::Util::lock_keys is not the same. I want to do "perl -wc" and see my errors, right now..


use strict;
use warnings;
use Hash::Util qw( lock_keys );

my %hsh = ();
lock_keys(%hsh, qw(x y z));
$hsh{'A'} = 1;

This passes "-wc" with no problems...

We prefer a compile time failure to occur, like this:

package FieldTest;

use strict;
use warnings;
use fields qw(a b);

sub new {
my FieldTest $self = shift;
unless (ref $self) {
$self = fields::new($self);
return $self;

package main;

use strict;
use warnings;

my FieldTest $tmp = new FieldTest();
$tmp->{'c'} = 'whatever';