Perl Hash Tricks

Perl Hash Trick - Merging

Let's say you have two hashes:

my %first = (
  'one' => 'two',
);

my %second = (
  'three' => 'four',
);

How could we merge the first into the second, so it looked like the following?

%second = (
  'one' => 'two',
  'three' => 'four',
);

One thought would be to loop over the first and manually add the key into the second:

while (($key, $value) = each %first) {
  unless ( exists $second{$key} ) {
    $second{$key} = $value;
  }
}

This will work, however there is a simpler and more elegant Perlish way to do this.

@second{keys %first} = values %first;

The beauty is that Perl guarantees that values will return in the same order as keys, see "perldoc -f keys".


2013

2013 and where it leads

As we enter 2013, I've been thinking about the idea of resolutions and if I really have any. The problem with resolutions is that if I label them as such, I tend to not want to do them, since they become obligatory burden. But then after further reflection, when it comes to programming, is it something that I ever find to be obligatory?

I'm not a genius

"It's not something I must do but something I want to do..."
--- James Fixx

Let me just clear something up: I am not a genius programmer. I didn't start programming when I was 5. I don't love math, and in fact I dropped out of calculus when I was a senior in high school. I do, however, have a profound interest in making a computer read and print commands I type to it. I've been programming since high school and have worked hard over the years to improve this, I guess it could be called a craft, by using sheer will power. Using most trusted tool of trial and error, I've been able to take this passion and develop it into a professional career of manipulating and coercing bits to bend to my will. As I try something, fail, and recalibrate every day, like an onion, I add another layer of knowledge of what it means to program.

I love to run

This brings me to the other thing I love to do: run. I really love to run. However, I am very slow. I've been running off and on now for about 5 years. I don't run for competition. Did I mention already that I'm a slow runner? But what's amazing about running is that regardless of how fast you are, it's the journey that is the most important part of a run (or a trot in my case). To me, it's the sense of accomplishment to see how far you were able to push yourself. I love the self-induced trance I find myself in just by listening to rhythmic sound of my feet hitting the pavement. This meditative state is quite pleasant, and it allows me to do my best thinking. Something about running is both cathartic and stimulating to my mind.

And the point is?

Much like slowly trotting up a hill and looking back at the distance I've traveled, it's the same when I've spent time working on a programming problem to pleasantly discover after the toil how simple the answer was. The problem was in fact so simple that it was beautiful and maybe even elegant. Solving the problem might have taken me longer than I expected, but the satisfaction I get from working through these mind puzzles keeps me returning back to this misogynistic art called programming.

2013 and beyond

As I continue down the road for 2013, these are the things I must not do, but what I want to do:

  • Contribute more to the Lucy code base

  • Lucy Webservice

  • Become a better C programmer.

  • Program something in D.

  • Learn a new algorithm and do something neat with it.

  • Write more.

  • Brew lots of beer.

  • Continue running, stick to good ole trial and error.

No obligatory resolutions from me for 2013. Carry on.


Perl is dead

Perl is dead, Perl is not dead maybe?

"When you don't create things, you become defined by your tastes rather 
than ability. Your tastes only narrow & exclude people. So create."
--Why the Lucky Stiff

Last weekend I sat and watched Stevan Little's presentation at Perl Oasis and how he bemoaned that Perl may be dead. Stevan outlined the sad fact that development of Perl, particularly Perl version 5, is essentially deadlocked when it comes to new much needed and maybe radical features. As I was watching this I was asking myself these same questions. Has the Perl community become so stale that they are indeed defined by their tastes? And even personally, have I been defined by my preference for Perl than by my abilities as a programmer? Perhaps? I'm actually not sure, I mean I'm still learning new things in Perl. But I have to admit this is a fear of mine as I watch the job postings seeking rock stars and wizards for the latest cool non blocking language or framework. If someone like Stevan, a trusted and admired leader in the Perl community, is saying such sobering things, this is a bit concerning. I have to admit Perl is quirky and that is probably why I love it so much, and sadly it seems most younger programmers don't share these sensibilities. So what was Stevan's answer to this disturbing issue? Fork the code and call it Moe. In other words, learn and explore.

Time to learn

So I ask the question, what am I doing to make sure I'm not defined by my tastes? Am I seeking knowledge on a daily basis? In the meantime I'll be reading a hard white paper on PFOR-DELTA, exploring Pegex, and maybe taking a crack at learning Scala. So I'll watch Moe and maybe I'll commit something, and hopefully in the process learn and appreciate new and interesting things. So keep pushing those bits to Github and in the process Perl will win a few new young hearts again.


Recent CPAN Module Review - Try::Tiny

Recent CPAN Module Review

As part of a series of blog posts, I'm going to attempt to find a newly released CPAN module every day and review it.

Try::Tiny

Today a new version of Try::Tiny was released that fixed some documentation issues. Most people will remember the old school way or maybe not so old school way of trying to catch exceptions in Perl:

eval { 
    ..some code..
    exception gets thrown
}

if ( $@ ) {
    do some clean up and pray $@ hasn't been wiped.
}

The problem with the above is that the special $@ is a global variable and tends to have problems in older versions of Perl, especially prior to 5.16. One such problem is that $@ can be wiped if another eval is called, this can often happen if an object has a destructor that calls eval. So to mitigate this issue developers would sometimes do things such as the following:

eval { ..some code.. {die} 1; } || do { handle exception }.

Other solutions, probably a better one, would look like this:

my $error = do {
    local $@;
    eval { .. };
    $@;
};

die $error;

So Try::Tiny through the power of prototypes creates a new syntax which does the localizing of $@ for a developer with a cleaner syntax:

try {
    die "for some reason";
} catch {
    say "Oh no, I got this error! $_";
};

This is a much more elegant interface and they even throw in a finally keyword too. Overall this seems nicer but introduces it's own caveats which a developer using this module need to care when using. The primary one is that Try::Tiny is not adding any new keywords but is using prototypes that create the illusion of new syntax. So if someone were to forget to put a semi-colon after the try parenthesis they may be unpleasantly surprised that code inside a catch might be executed prior to a try being executed, for example:

try { } catch { run_this() } 

run_this will be executed before the try block.

Overall I still like Try::Tiny and believe it's a step in the right direction - even if it feels a bit gimmicky. I would encourage most people to use it over eval, but it should be used with care.


Recent CPAN Module Review - Moox::ClassAttribute

Recent CPAN Module Review

As part of a series of blog posts, I'm going to attempt to find a newly released CPAN module every day and review it. Because of the end of the year holidays I eneded up taking a bit of time off from blogging, so I'm restarting this series and will hopefully try to keep up on a daily schedule.

Moox::ClassAttribute

There are times when you may need an attribute on a Moo object to be accessible at the Class level. This could easily be done with Moose using the module MooseX::ClassAttribute, however, not so easy with Moo, until today. To start the new year off Moox::ClassAttribute was released. With the following code you can now have class level attributes:

package MyClass;

class_has class_level => (
    is => 'rw',
    default => 'foobar'
);


print MyClass->class_level;

This module was inspired by MooseX::ClassAttribute, which obviously requires Moose, but now the same power is available for Moo. Outside the obvious issue that class level attributes tend to be another form of global variables. Moo::ClassAttribute, offers some flexibility that can't be achieved with a instance level attribute. However, as stated in the documentation, it currently does not support subclassing which may or may not be a big problem. This module was just released, so it'll be interesting to see how it matures and maybe one day it'll be as feature complete as MooseX::ClassAttribute.

So there you have it, if you need globals at the class level it's now available with Moo.