In my spare week before YAPC::EU, I am making a return visit to one of my favourite cities in Europe: to Lisbon.
José Castro is a good friend. As soon as he heard I had a some extra time this year, he wrote and invited me to come and visit Lisbon.pm. And who could resist the beautiful weather and city and people of the Portuguese capital? So I am delighted to have the opportunity to catch up with many friends and acquaintances in Lisbon this summer.
I'll be giving a free public talk to the local Mongers (and, we hope, to the wider Open Source community) on the evening of Monday 8 August. We are still working out exactly which talk that will be, but the details will be announced soon on the Lisbon.pm blog as well as in other local news channels.
Besides the fact that "Erez Schatz" is a cool name by itself, I think he's on to something.
Since it's clear that the Perl6 moniker is going to remain, and most folks are too curmudgeonly to change the name of Perl5, this seems like a good compromise. It allows for a clear marketing difference for each release - one that obviously works elsewhere in the tech industry.
(You know Sebastian's going to jump at the chance to design a nifty logo for each one)
Peter Shangov's idea is also worth pursuing - a Perl distribution with all the modern toolkits included. Given the recent logoactivity, it should be called Raptor. It would be easy enough to start referring to "Raptor", just as "Rails" is a rallying cry for the Ruby folk. It could be downloadable from http://raptor.perl.org, of course - possibly even installable via perlbrew:
This would've been glazed over as yet another evidence that corporate IT is brain-dead, if it wasn't for the idea that the Perl community need to win over corporate IT to become the key player it once was.
Sadly, catering to one's insanity can only cause even more insanity.
And so, trying to find logic in the madness has brought forth the irrational thinking that "all we need to do is drop the 5 and 6 from Perl 5 and 6".
Now, this might be the silver bullet, it's so crazy it might work. But you don't have to actually do anything.
My profound thanks to everyone who invited me to visit them during my spare week in Europe. After much discussion and contemplation I have accepted two invitations for the week. The first of them is to visit Oslo.pm
Salve Nilsen wrote to me as soon as I announced I was available, and reminded me that Oslo.pm has already invited me several times to visit them. They have waited patiently for several years now, so the week before YAPC::EU seems like the perfect time to accept their long-standing invitation.
So I'm going to be in Oslo on August 11 and 12. We'll be offering a free
public talk on the evening of Thursday August 11, the details of which will be announced soon on the Oslo.pm website.
We'll also be running two 1-day classes on August 11 and 12 at Redpil Linpro, with some of the proceeds going directly to help fund the activities of Oslo.pm.
I'm very much looking forward to my first visit to Norway. Jeg håper å treffe deg der!
How do you decide to move to another version of Perl? Some people use the latest version right away, some people make big jumps once a decade. Some never upgrade. What's your style?
Pass it around, tweet it, facebook it, buzz it, bump it, do whatever you crazy social kids do. Retweet it.
You don't have to justify anything. I don't really mind if you are using an older perl and I'm not going to tell you that you are wrong. There's room to explain yourself if you feel the need. Or, if you have a good restaurant recommendation, let me know about that too.
So, I got an invite to Google+ so I logged in and had a look around. I do like the rotary phone style addition of people to a “Circle”. Overall, it has the normal Googlely look and feel, which I like. However, there are problems, mostly due to lack of integration with the rest of Google. It is as if the team had no clue about any of the other piecemeal attempts at social networking that Google has tried.
Yesterday I announced the release of my Perl-accessible bindings for CUDA. CUDA is marketed as a massively parallel, high-performance computing architecture. When you think about Perl and high-performance computing, I would hope that PDL, the Perl Data Language, comes to mind. :-)
PDL is a CPAN distribution that gives Perl the ability to compactly store and speedily manipulate the large N-dimensional data arrays which are the bread and butter of scientific computing. Today I will discuss how CUDA::Minimal and PDL talk with each other. (In case you're curious, tomorrow I discuss error handling in CUDA::Minimal.)
The Perl 5 Core Maintenance Fund aims to raise $25.000 to to pay for Nicholas Clark and Dave Mitchell to work for 3 months on the Perl 5 core, fixing bugs and making other improvements.
Vienna.pm decided to set aside $10.000 as "match funding" - ie for every $1 that someone else donates, Vienna.pm donate $1, until $10,000 + $10,000 is raised, and only 20% remains to reach the target. The hope is that "match funding" will encourage people to donate a bit more themselves than a simple unconditional donation.
I like DTrace and wanted to have at least part of its power for Perl progams, beyond the DTrace probes already provided by perl. So I used Aspects to create dip.pm. Allow me to quote from the manpage:
Since my first blog post back in December I've written and made thorough use of a simple Perl interface for CUDA. Today, I've posted it on github, and in this post I'll give a relatively simple example of how to use CUDA with Perl via Inline::C. (In case you're wondering, CUDA is a technology provided by nVidia that lets you compile and execute highly parallel code on your CUDA-capable video card.)
First, of course, you'll need to install ExtUtils::nvcc. At the moment this only works with Linux (maybe with Mac OSX, definitely not yet with Windows). It has only been confirmed with Ubuntu. See directions on the ExtUtils::nvcc wiki. (If you manage to install it on other systems, please let me know and edit the wiki or send me your notes!) If you have that installed, installing CUDA::Minimal is just a simple CPAN install.
First Script
So, at this point I will assume you've installed CUDA::Minimal. What can you do with it? Here's a simple example:
(For those people who don't know about it yet - ubic is a flexible, powerful, extensible perl-based service manager. Something like upstart or daemontools, but better.)
So.
Lots of cool stuff happened in last few months.
First, ubic is now cross-platform and runs on *bsd, Mac OS X and pretty much any posix-compatible OS out there (no Windows yet, sorry).
Second, installation is now as easy as possible. Just do "cpanm Ubic && ubic-admin setup", and you are done. (Pass "--batch-mode" to setup command if questions annoy you). It's even possible to install ubic in home folder without root access and use it with perlbrew or whatever you like. Even on shared hosting, if you have the ability to edit crontab there.
Third, 1.30 release finally got somenewmanuals. They are far from perfect, but I believe they are much better than old PODs with which it was pretty obscure for new user to figure out where to start.
There has recently recently been an increase people asking, seriously or in jest, for Perl 5 and/or Perl 6 to be renamed and others offering rebuffals of various types. You could say a heated debate seems to be going on.
However, one thing stands out here: It does not seem to be clear to either party exactly why the party is saying what it is saying. And when the realization arrives, some realize that it should be fairly obvious and stop arguing, but do not make their realization public, leaving others to make the same mistake.
As such, i'll try to put it into the most simple words i can here:
The existence of Perl 6 means that for the decision makers in IT, the managers and CEOs who are not even programmers, Perl 5 appears to be obsolete.
I write this with some hesitation, because I know it’s a touchy subject that has been going the rounds recently and that people have some very strong opinions about it. Mostly I’ve been lurking: nodding here, shaking my head in disdain there. There are good points all around, but I can’t help wanting to say something, and so, I’ve decided to try to gather my thoughts and lay them out.
I was writing some very simple unit tests last night and was baffled when one didn't work.
The code was very simple, something I thought I had done hundreds of times:
It's not the same thing, but it seems similar to me.
Unfortunately the commit that fixed Brian's bug 93548 does not fix this one.
I refactored the problem down to a pretty small sub,
and am further baffled by the minor variations that cause the problem to go away.
Here is the script and the output from various perls...
Interestingly this test appears to include another bug that was fixed somewhere between 5.10 and 5.12...
Calling it Perl 6 was sensible at the time of its inception, for all the reasons chromatic outlined there in caricature. But the premise and direction of The Language has evolved dramatically since the time its name was chosen. In premise it’s a similar idea now, and at the same time one with naught in common with the original. And still, the name persists.
As programmers we (yes, us, us all, not editorial we) should know of the importance of naming: any good programmer spends a lot of time in agony over variable names and function names.
What we (the editorial, this time) have done here is refactor the entire codebase rug from underneath the variable, yet insistently kept its now-misleading name the same. Become, became: we left the frame.
On the other hand – of course! –, names create. There are no things until there are words to name them. And also: names identify. You don’t rename your son or daughter because they’ve grown and changed.