Philip Durbin

I listened to http://devhell.info/post/2013-04-24/feline-tooth-extraction/ today and enjoyed hearing Chris Hartjes describe his recent experience with Perl. Quotes include:

"Perl actually doesn't suck"

"all of our services at work because we're moving to Service Oriented Architecture are either being done in Java or Perl"

"productive in Perl with a very short ramp up time"

For just the 5 minute clip: https://soundcloud.com/philipdurbin/perl-actually-doesnt-suck

This image is from http://www.thersa.org/events/video/animate/rsa-animate-the-power-of-networks

See also my tweet and Google+ post about this video.

Update for Sun May 27 10am-ish EDT. . . Whoops, I should have included Stevan Little in the title of this post:

He's unnamed Perl contributor in the first image I posted. I'm listening to the original audio of the lecture from which the RSA Animate video is based and was able to find http://www.visualcomplexity.com/vc/project.cfm?id=685 which links to http://cpan-explorer.org/category/authors/ which is where I found this second image. See also slide 29 from the slides of the talk. The first image is obviously an illustration of the second image. Very cool. I love this stuff. And I had never heard about http://cpan-explorer.org which is just fabulous.

Also a made a second Google+ post that links back to this one.

From an Interview With Ward Cunningham in Dr Dobb's Journal published May 15, 2012:

That's when I picked up Perl. And it shocked me, just how well it worked for finding and plundering files because it had those reg exes built in and stuff like that. And it was so fast. It was fast to compile, it was fast to develop, it was fast to run. I could not believe it was so fast. And I know people like to complain about it, but I also thought it showed a tremendous amount of insight. It was insight, and I looked at it and I said, "Who would have thought of making a language like that?" That's when I realized that open source was here to stay. There is no commercial endeavor that ever would have invented Perl.

But Perl was my escape from object-oriented programming, and I still use it today. Probably a day doesn't go by that I don't just pick up Perl right at the command line just because idiomatically I can write commands. I know there's a command in UNIX but rather than go the command page and try to remember the options, I just write it from scratch in Perl. You know, I go on and finish the line. I know Perl well enough that I can do that. I think if you write big programs you know stuff that I never bothered to learn about Perl.

Having been liberated from Perl 5.8.8 only recently (and not completely, really), I've never used given/when. rjbs explains some gotchas.

From http://irclog.perlgeek.de/crimsonfu/2012-03-16#i_5305433

18:26 ironcamel   so you are at least using the perl 5.10 syntax candy?
18:26 pdurbin     maybe. i don't know :)
18:26 ironcamel   given/when, say, state, and //
18:26 pdurbin     nope
18:27 pdurbin     too fancy for me
18:27 * ironcamel bonks pdurbin on the head
18:27 ironcamel   you should at least look into given/when, it is amazing
18:27 ironcamel   it has "pattern matching"
18:28 ironcamel   only other language i know that has that is scala
18:28 ironcamel   it has nothing to do with regex patterns
18:28 ironcamel   and say "foo" is same thing as print "foo\n"
18:28 pdurbin     "You know, I actually advise people to avoid given/when" --rjbs 2011-04-28
18:28 ironcamel   don't listen to him
18:29 ironcamel   listen to everything else he says, just ignore that bit
18:29 pdurbin     heh
18:29 pdurbin     i should ask him if i can publish this email
18:30 pdurbin     or has he written about it extensively already?
18:30 ironcamel   he wrote you that in an email?
18:30 pdurbin     yeah
18:31 ironcamel   what were you emailing him about?
18:31 pdurbin     plus a long explanation i don't understand
18:32 pdurbin     something for shuff: Bug #64302 for Dist-Zilla: Requiring EU:MM 6.31 excludes RHEL5 - https://rt.cpan.org/Public/Bug/Display.html?id=64302
18:32 ironcamel   i wonder if he wrote that before 5.10.1 was released
18:32 ironcamel   because 5.10.0 had some issues with given/when that were fixed
18:32 pdurbin     he wrote it 2011-04-28

-------- Original Message --------
Subject: Re: Bug #64302 for Dist-Zilla: Requiring EU:MM 6.31 excludes RHEL5
Date: Fri, 16 Mar 2012 15:16:30 -0400
From: Ricardo Signes <rjbs@cpan.org>
To: Philip Durbin <philipdurbin@gmail.com>

* Philip Durbin <philipdurbin@gmail.com> [2012-03-16T15:11:54]
> i brought up your point about given/when today:
> http://irclog.perlgeek.de/crimsonfu/2012-03-16#i_5305433
>
> do you mind if I publish these emails on my perl blog?
Not at all, go ahead.  Thanks for asking first.

-- rjbs 

-------- Original Message --------
Subject: Re: Bug #64302 for Dist-Zilla: Requiring EU:MM 6.31 excludes RHEL5
Date: Thu, 28 Apr 2011 17:06:41 -0400
From: Ricardo Signes <rjbs@cpan.org>
To: Philip Durbin <philipdurbin@gmail.com>

* Philip Durbin <philipdurbin@gmail.com> [2011-04-28T17:02:00]
>> You know, I actually advise people to avoid given/when... but that's a
>> different kettle of fish.
> Hmm, no need to write up anything on my account, but if you're
> already blogged about it, please share a link.
There are two problems.  One is that when() topicalizes $_, like for, but it
topicalizes the *lexical* $_ rather than the *dynamic* $_ like for does.

So:

  my $x = 'foo';

  given ($x) {
    when (/f/) {
      try   { die 'bar' }
      catch { warn "exception: $_" }
    }
  }

This will warn "exception: bar" because the closure passed to catch has closed
over lexical $_ instead of using the global.  You could write $::_, but who
remembers this sort of detail?  It's come up a few times as a bug report to
Try::Tiny.  Of course, there are other ways around the bug as presented above,
but you can imagine how it will manifest as a category of bugs.

The other is that ~~, the smart match used to test the given against when
cases, is ridiculously complex.  It has something like 27 possible behaviors,
several of which can recurse to re-dispatch to the 27-way choice again.

I don't think Perl needed ~~.  It needed an "in" operator.  A "switch"
statement might have been nice, but the one we got is too complex.

-- rjbs

Update: I'm sorry for the formatting of this post. I'm not sure where to edit the css. For now there's a more readable version at http://paste.perldancer.org/1uYeL1Fi6M5sL

Also, there is more discussion here: http://irclog.perlgeek.de/crimsonfu/2012-03-16#i_5306245

A little part of my Perl soul died the other day when I read a tweet by Mark Jason Dominus:

Perl didn't work for this guy, here's why. It was a really good article, should be required reading for #perl folks: synflood.at/blog/index.php...

When Andreas Krennmair announced a new Twitter client called baconbird in late 2010 he sounded very enthusiastic about Perl, saying

The code itself is about 850 SLOCs of Perl code, the user interface is based on STFL, the Twitter backend uses Net::Twitter, and all the OO glue code in between uses the Moose object system. All in all it took me less than 2 weeks of my free time to develop the first version of it.

I was excited to read this post because I really like his newsbeuter feed reader (I've chatted once or twice with Andreas over IRC about it and helped package it), and it was interesting to see him choose Perl over C++ for this new project. I pulled in the baconbird dependencies and started using it right away.

Some months later Andreas wrote a blog post entitled "I don't want my programming languages to be hip" in which he praised the Perl community, saying

I just want a quiet, hype-free, pragmatic, down-to-earth knowledgable community. . . Exactly the things that I learned to despise about the culture revolving around Ruby and Rails are something that I haven't experienced in the Perl community at all so far. Libraries, framework, documentation and people had more time to mature, probably, while still being down-to-earth. I can expect good documentation, functioning software, friendly people and most importantly accurate words in announcements and discussions.

Everything seemed peachy. We had a happy Perl programmer on our hands.

Last week, however, within a year of baconbird's release, Andreas blogged about the problems he has been having with Perl:

But first things first: my first poor choice was using Perl. Sure, Perl provided me with all the tools to come to meaningful results really quickly, through the vast amount of ready-to-use modules in the CPAN archive. And that's what's really great about it. What's not so great about Perl are the ideas of concurrency. You basically have to resort to event-based, async-I/O programming, which is not only painful by itself, but also extremely painful to integrate with my widget set of choice, STFL. And threads in Perl... don't do it, that's what everyone says. That meant that I couldn't do any of the Twitter communication asynchronously in the background, but had to do it in my primary thread of execution, essentially make it part of the subsequent calls of the input loop, if I wanted to retain sanity and a certain level of productivity. And that made baconbird really slow to use, and when Twitter's API was offline, baconbird practically hung. That made baconbird just a PITA to use, and I had to change something about it.

That post is entitled "Rebooting the baconbird project" but his new Twitter client is a complete rewrite and has a new name: gockel. It's written in Go, which has a particular focus on concurrency, as I understand it.

So far I've been disappointed by the comments on Andreas's post. I'm not skilled enough in Perl or concurrency to say anything about how to solve his problems, but maybe someone else will be inspired to post an nice comment with some suggestions. As I quoted above, he isn't using an event-based model (so I take it AnyEvent is a non-starter) and he's really into STFL (newsbeuter uses this well), which seems to complicate matters. Maybe Go is simply a better tool in his situation. Maybe threads::tbb could help. I don't know.