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.

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

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.

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.

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.