Perl Love Archives

Ephemeral methods, or what to call 'dispatch to a variable containing a subref'?

In my last post, I use a Perl dispatch pattern where you store a subroutine reference in a variable and then use that as the method to call on an object. Like so:

my $method = sub { ... };

Is there a name for this pattern? If not I propose to call the “method” an “ephemeral method”. Does this work for everyone?

Note that you really can’t call it a lexical method for several reasons.

The perils of & (and prototypes too!)

In a recent post, Chris K asks, why do I recommend using function() rather than &function() or &function. I happened to see it right before heading to bed, but I wanted to respond, so who knows if this is a good example or not. Anyway here goes, look at this code (seen below if you have javascript), it prints 6 lines, do you know what they will be?

A generator object for Perl 5

I have recently started a new job and it has forced me to learn more Python than I have ever had need to learn. I decided that I should take this as an opportunity to learn, and as Miyagawa-san has often done, steal when possible.

One thing that fascinated me is Python’s yield or generator pattern. In this pattern, you can make a function (or my case an object) which implements a lazy iterator returning a value (or possibly values (see below)) without leaving the while loop that generates them.

My Virtual YAPC::NA 2013

Last year I had the joy of experiencing my first YAPC, it was YAPC::NA in Madison, WI, which is just up the road from me in Chicago. Sadly this year YAPC::NA was much further away and I, having recently defended my Ph.D. thesis, could not afford the time nor cost to attend. While people (most notably Peter Rabbitson (aka riba, aka ribasushi)) offered to help me attend (he with the excess of his own funding drive), finding a job was of greater concern.

That said, I ended up having a great YAPC::NA. I have to extend massive thank the conference organizers for again providing streaming video of the conference talks. I was able to watch an incredible number of talks, learning many new things and seeing many Perlers who I have only known by name (several of whom were not at last year’s YAPC::NA). I even got two shout-outs from speakers!! (squee)

A complement to the video streams was the #yapc channel on IRC. We virtual attendees developed quite a rapport. Much as in real life I have a hard time leaving a group of friends, talking long beyond when I intended to leave. Sure enough, as those in the channel may attest, our conversations often lasted long after I said that I was leaving.

If there was a small silver lining to not attending live, being able to converse during a presentation was a new and interesting way to absorb the material (ie. “links here”, or “see my example there”, or “has anyone tried this with X”). I even once got a question passed to a live attendee to be asked of the speaker.

I was very saddened to not be able to attend this year, but the videos and #yapc made it almost feel like I was there. A few comments. I would have been happy to contribute a few dollars to defray some of the costs, perhaps a donation link or “virtual attendee” category might be considered; though I hope that videos continue to be free to watch, more for the newbie’s sake. Also when Barbie made his call to “submit talk reviews” I was sad that virtual attendees are not able to do so; he has heard my plea and has offered to consider this in the future.

As Brent Laabs so eloquently put it, “Truly, Perl’s community is it’s greatest strength.” Of course, I hope to be able to attend future YAPCs (not just NA) in person, but virtual attendance is an experience which helps to boost the community beyond just those who can attend. Congratulations to the YAPC::NA organizers, it was a great event, even for those not present!

Type::Tiny rescues Moo

I have just ranted about removing old bad code from the Perl core. Let me lighten the mood by talking about some good, new code.

I have loved Moose for some time now, but like others, I disliked how heavy it was. Then Moo came along and it was great … until I found myself not availing myself of the type system, because it was harder to get to than in Moose. I was skipping validation more and more.

A recent project came up and I really wanted to do it right, so I tried Toby Inkster’s new Type::Tiny and may I say, “hat’s off to you sir!” The combination of Moo and Type::Tiny brings that Moosey feeling back, while still being light and responsive and even fat-pack-able! Great work to all involved in both projects!

On the removal of some core modules

I’m sure most of the readers of this blog will have seen that both Module::Build and are up for removal from the Perl core. I thought I would toss my $0.03 (inflation) in on the matters.

Mojolicious 4.0 is coming soon!

As a newer member of the Mojolicious Core Development Team, I am more than usually excited for a Mojolicious release. This is because the next major release, version 4.0, is set to ship very soon! For those of you who don’t know, Mojolicious is a modern Perl web framework which is lightweight and easy to get started learning and using, while containing features that are cutting-edge. It’s asynchronous/non-blocking to the core, websockets work out of the box, comes with built-in DOM/JSON/UserAgent, etc etc.

Our fearless leader Sebastian Riedel (aka sri) will no doubt post a message with all the details when it ships. In the meantime, I want to share a little story of how community interaction, even at the StackOverflow level, can lead to innovation and enhancement of major projects like Mojolicious!

A Case for Tie::Array::CSV

What is the favorite module you have released to CPAN? For me, its not some shiny CMS or fancy scientific simulation. In fact, mine is probably horribly inefficient, maybe even a little evil, but I like this one best because it is clever.

Today I used my favorite of my modules in order to accomplish a difficult task, and in doing so I found a little bug, which I have just fixed. Which one is it? Let me introduce you to Tie::Array::CSV.

A new protocol for sending files over websockets

Today I’m happy to make public the work I’ve been doing to make some kind of “standard” for sending files over websockets. I call it GalileoSend because it was created for the Galileo CMS.

The protocol itself is language independent for both the client and server side, assuming that both can open a websocket connection and send JSON (as text) and binary data over it. Since communication by websocket is cheap, 2-way communication is highly encouraged throughout the transfer and positive confirmation of receipt is required.

Further, I have written a javascript client-side implementation (which could be used for any server) and a non-blocking Mojolicious server-side implemenation (which could be used for any client).

Read on (examples!) …

Does Perl (5) have a future?

TL;DR: Not if it can never have a major release. Please read on.

Note: I’m now not talking about soon, or what it would be named/numbered. I’m talking about ever.

Let me tell you my story, some of you may know it. I’m a Ph.D. candidate in Physics. Programming is woefully ignored in science education now. All my professors learned FORTRAN in courses during their Ph.D. (or B.S. in some cases) but now, given the ease of Mathematica, we seem to be expected to pick it up as we go on.

One day I had a nutty idea, I wanted to parse one of the temporary files created during LaTeX compilation. A friend, who knew next to nothing about Perl, suggested I needed Perl and Regexes. I can here you out there, saying “now I had two problems”. Not so. I learned, I improved and finally my first Perl script was out in the world. It doesn’t bear much resemblance to its current form but it worked.

This project had nothing to do with science, but I was awed by the power I now possessed. I went to start using Perl in my work. Perl finally solved a near-intractable programming problem in Mathematica with relative (hmmmm) ease. Physics::UEMColumn now forms the basis of my Ph.D. thesis which I am defending this spring.

To get that simulation working I needed more tools, so I wrote them, and those tools needed tools so I wrote them and suddenly I discovered that I had something I could give back, so I’m writing it too. Further I often need PDL, and amazing numerical package for Perl. It really needs some internal TLC, which David Mertens, project pumpking Chris Marshall and others are planning.

Why am I telling you this? Because in 2009 I became a Perl programmer, and I fell for language hard. I love Perl. I came for regexes, but I stayed because it works well with the way I think. I use it for lots of things now. Unfortunately few others have come with me.

Chromatic implores us to write good software and show it off. For these years I have tried, and it doesn’t work. I have given talks at my university, I have told friends, I have used it to help coworkers, I share with the community. I have recruited one person. I have converted none. Most people who know Python or ROOT (C++) laugh at me. Its not enough.

Until yesterday, I had a steely resolve. Even in the face of Stevan’s recent pronouncement and embarking on replacing the Perl internals with Scala, which would probably kill or at least maim most of my work. Moe wasn’t the future of Perl, just an offshoot, right?

Yesterday, for the first time, I saw a flaw. There are people out there who really think that Perl will never see another major point release. I don’t mean soon, I don’t mean for cheap marketing, I mean ever. I mean for at some point breaking some small amount of backward compatibility. For some the reason is that compatibility is too important (the future is our past), for some its that Perl 6 is the future of Perl 5 (whether spoken/believed or not) and some its just because there is no number available. All that got me to thinking …

Is the work on Perl 5 really just a shim to support CPAN? Is it really going to be an ever-growing feature pragma? Will there always need to be a magic incantation to activate some of the best Unicode support in the programming world? Will new Perlers need to be told to use good practices like strict and warnings forever? Is the herculean work of Nick Clark and Dave Mitchell just going to go for naught after a few years of a usable Perl 6 and Moe?

If Perl can never have a major point release. I think all of the above is fated to be true. I’m not asking about soon; I’m asking about ever.

In my mind I’m planning future work on the Perl we now call 5. I want to help improve the giant XS extension called PDL, possibly using another one called Prima. I intend to keep working on Alien::Base. But is it all just going to vaporize in a few years do to lack of external interest, or after being replaced by something? Why should I?

In the upcoming months, I will be looking for my first real job. It might be a post-doc appointment with Pacific Northwest National Lab (PNNL) doing the hardware/software integration for a brand new ultrafast electron microscope. Should I do it in Perl? I will only be there a year or two, is it fair to saddle them with that? Will they find someone else who can maintain it?

If I don’t do that, I might form a company, one that aids research groups in writing the software that they often cobble together, for analysis, data warehousing and search, for hardware integration. Would I do that in Perl?

If the powers that be don’t see a major point release at some point in Perl’s future, then it has none. The userbase will keep sliding away. Not purely for a number, or marketing, or perception, but because you will need too much knowledge to start using it. You will need to know the incantations to do things right, ones that we already know, but new users can’t find. How many people find a CPAN module that does just what they want, and so set out to write their Perl first script, only to fail and walk away? We can’t ever know.

I ask you p5p (whom I admire greatly) and I ask you Larry, creator, benevolent dictator, does the language we call Perl 5 have a future? At some time, will we see a major release? If not, then I don’t know what I’m working towards. Should I tie my future to this language?

About Joel Berger

user-pic As I delve into the deeper Perl magic I like to share what I can.