Bring your dirty YAPC::EU 2013 money to YAPC::EU 2014

Nicholas Clark:

It turns out that it’s quite hard to change Ukrainian Hryvnia back into your local currency. Apparently you need to get a special form to do it, which seems to be about as common as a Ryanair refund.

Given that quite a few of us aren’t that likely to return to Ukraine any time soon, it implies that there’s quite a lot of paper money sitting around various Perl monger’s desks, drawers etc, not earning its keep. For each individual it’s not much in value, but I suspect that all together it adds up to a few thousand Pounds/Euros/Dollars etc. Meanwhile, the Ukrainian central bank is very happy about all currency it got in return for selling us [its] bits of paper.

So I thought that it would be a good idea if we put the notes carefully to one side, and then all took them to Sophia next year, where at YAPC::Europe 2014 someone from Kiev can come with a big bucket, collect the money, and take it back to do useful things with it.

I assume that the intervening events have not made changing the currency any easier…

In any case I’ll be bringing my 70 along, and bulk88 has expressed interest to buy, should none of our attendants from the Ukraine want them.

The perversity of traditional Perl 5 dereferencing syntax

I wrote this article almost a year ago as part of an omnibus reply to a bunch of different posts from a perl5-porters thread. I never finished all parts of the reply and thus never sent this part either, but in contrast to the other parts of this stillborn mail, I think this one is worth reading. So asked Johan Vromans:

It still escapes me why @* was chosen instead of the much more logical []:

$h{a}[0]->[]

The reason is that there are a number of problems to solve with any new deref syntax:

To the tune of…

Buddy Burden:

Yes, we had multiple keynotes [at YAPC::NA 2014]. Two or three a day, even. I thought that was a bit weird. My friend David Hand kept joking that we had gone beyond keynotes and were now into keychords.

Installing Term::ReadLine::Gnu on OS X, the easy way

If you try to install Term::ReadLine::Gnu on Mac OS X, you will ordinarily run into this unpleasantry from the Makefile.PL (which will likely end up in such as ~/.cpanm/build.log):

The libreadline you are using is the libedit library. Use the GNU Readline Library.

Here I will assume that you are using Homebrew and have installed GNU Readline:

brew install readline

Even so, you will get this error. This is because of how Homebrew installs Readline. Since OS X ships libedit as libreadline, Homebrew tries to avoid conflicts with system software by installing Readline as “keg-only” software – that is, it’ll install it within its package-managed filesystem hierarchy beneath /usr/local/Cellar, but it won’t link the libraries into /usr/local/lib, so that they won’t be visible to software that isn’t explicitly linked against it.

There is an easy and obvious way around this:

brew link --force readline
cpanm Term::ReadLine::Gnu
brew unlink readline

This makes Homebrew link the shared libraries into /usr/local/lib – which Homebrew ordinarily refuses to do for packages marked keg-only, like Readline is, hence the scary --force. Of course, all said and done, we unlink the package again straight away, so as to not cause conflicts. By doing this, Makefile.PL run from cpanm picks them up to link. We can confirm this:

otool -L ~/perl5/perlbrew/perls/**/Term/ReadLine/Gnu/Gnu.bundle

Its output should include something like the following line:

/usr/local/opt/readline/lib/libreadline.6.2.dylib (compatibility version 6.0.0, current version 6.2.0)

This /usr/local/opt is another Homebrew-ism:

$ ls -l /usr/local/opt/readline
lrwxr-xr-x  1 user  admin  24 14 Jul 04:53 /usr/local/opt/readline@ -> ../Cellar/readline/6.2.4

Note well that I actually have Readline 6.2.4 installed!

$ brew info readline | head -1
readline: stable 6.2.4

That means doing it this way is not only easier than the hard way found elsewhere on the web (here or there), it even allows me to brew upgrade readline without breaking Term::ReadLine::Gnu.

Backcompat is holding us back!

“Let’s free ourselves from the shackles and do something bold!”

I always cringe when I hear this battle cry. Isn’t that sentiment exactly what set the trajectory for the Perl 6 effort? Maybe it’s just been so long that people have forgotten.

But that is precisely how Perl 6 became such an amazingly long trek: once you remove the constraint of staying compatible, everything is suddenly, potentially, up for reconsideration. Then when you start changing things, you discover that changes in one part of the language also affect several other, remote parts of the language. So it starts with the simple desire to fix a handful of obvious problems in obvious ways… and spirals out as you make changes, and further still as you make changes in response to your changes, ever further and further.

At that point, it is exceedingly likely that the project will fizzle out before it ever comes to any fruition. But even if you have the perseverance, you face an uphill battle: unless your project has the community’s implicit blessing as the successor (as Perl 6 does, due to Larry’s presence), it is likely to simply slip into oblivion… the way Kurila did.

So yes: backcompat is holding us back… the same way that gravity is. It keeps us from floating away untethered.

Note that I’m not saying it doesn’t really hold us back. I’d love to travel to space easily, too! I still await Perl 6, as well.

But what I think, every time someone proposes to throw off the shackles of backcompat and go for it, is that we already have one Perl 6 – we don’t need another.