Philip Durbin tag:blogs.perl.org,2009-11-03:/users/philip_durbin//831 2013-05-12T22:04:47Z Movable Type Pro 4.38 Perl actually doesn't suck tag:blogs.perl.org,2013:/users/philip_durbin//831.4670 2013-05-12T21:59:23Z 2013-05-12T22:04:47Z 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... Philip Durbin http://greptilian.com 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

]]> Andy Lester, brian d foy, Gisle Aas, and Adrian Howard featured in RSA Animate video - The Power of Networks tag:blogs.perl.org,2012:/users/philip_durbin//831.3301 2012-05-27T03:24:09Z 2012-05-27T14:24:48Z 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... Philip Durbin http://greptilian.com This image is from http://www.thersa.org/events/video/animate/rsa-animate-the-power-of-networks

perl-mslima.jpg

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:

cpan-explorer-authors.png

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.

]]> Ward Cunningham on Perl: fast to develop, fast to run, insightful tag:blogs.perl.org,2012:/users/philip_durbin//831.3251 2012-05-16T12:00:48Z 2012-05-16T12:01:13Z 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... Philip Durbin http://greptilian.com 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.

]]> rjbs advises to avoid given/when tag:blogs.perl.org,2012:/users/philip_durbin//831.2946 2012-03-16T19:58:07Z 2012-03-16T22:38:25Z 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... Philip Durbin http://greptilian.com 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

]]> Perl dropped and Go adopted due to concurrency issues in baconbird tag:blogs.perl.org,2011:/users/philip_durbin//831.2310 2011-10-19T03:44:30Z 2011-10-19T10:23:00Z 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... Philip Durbin http://greptilian.com 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.

]]> John Siracusa discusses Perl on Hypercritical tag:blogs.perl.org,2011:/users/philip_durbin//831.1726 2011-05-03T12:43:05Z 2011-05-03T12:44:53Z In episode #15 of Hypercritical, John Siracusa presented Perl in (largely) a very positive light to what I assume is mostly a non-Perl audience. I'm including my notes on the discussion below, but I recommend listening to the podcast yourself... Philip Durbin http://greptilian.com In episode #15 of Hypercritical, John Siracusa presented Perl in (largely) a very positive light to what I assume is mostly a non-Perl audience.

I'm including my notes on the discussion below, but I recommend listening to the podcast yourself to form your own impression: http://5by5.tv/hypercritical/15

I couldn't find a discussion area linked from the episode page, but I noticed someone posted it to Hacker News as "John Siracusa and Dan Benjamin on high-level programming languages [podcast]."

Notes on Hypercritical #15

Geeks love a meritocracy, but languages often become popular for reasons other than their technical merit. Why do languages become popular? They are the official language of a platform. They promise the ability to write once, run everywhere. They enable a new type of application (i.e. CGI). They allow you to use the hot new thing (Rails). It's your only choice (JavaScript, Flash).

Most languages stink.

What should a high level language have?

  1. Memory management
  2. Native Unicode strings
  3. Native regular expressions
  4. Native object system
  5. Named parameters
  6. Succinct syntax for common operations
  7. Acknowledgement, at least, of concurrency

Languages are slow to change, unless controlled by a single vendor (i.e. C#).

In considering the aesthetics of a language, many people find non-word characters ugly (but it depends on which languages you come from). Sometimes the prettier language (or fighter jet) wins.

The major objection to Perl from non-Perl people is probably that Perl is ugly. They may not like the dollar signs. Perl was their first exposure to regular expressions.

John: "What objections do you have to Perl?"

Dan (playing devil's advocate, somewhat): "Legibility. Where are the frameworks? Where is the next generational thinking? What can Perl do besides text parsing? How is Perl used in the real world?"

People looked a Perl long ago and haven't looked again. They dismiss it.

What's wrong with Perl?

  1. Unexpected default object system (build your own), but this is also a strength
  2. No language specification (only perl can parse Perl)

What's good about Perl?

  1. Perl has been a breeding ground for object system experimentation
  2. Perl has the largest group of developers doing "advanced stuff" in a semi-popular language
  3. Perl has practically every advanced feature found in other languages
  4. Perl can and does incorporate computer science research, such as the 2002 paper "Traits: Composable Units of Behavior". This is possible because Perl is a backwater and doesn't have popular API's or platforms tied to it.

Other languages should go ahead and steal ideas from Perl, as Perl has from other languages.

Dan: In 2011, the popular apps to build are for the web, mobile, and desktop. Why should someone learn Perl?

John: Language choice should depend on the task. Use PHP for its ease of deployment. Use Ruby if you want Rails (an aside: the main insight from Rails is convention over configuration).

What would you use Perl for these days?. . . [pause]

  1. You *could* write web applications in Perl, but it's not recommended. Use whatever is popular (currently Ruby on Rails, something Python, PHP if necessary) in order to get more support, lots of books, etc.
  2. You could rewrite your slow application in Perl because Perl offers great interfaces to fast C libraries.

Reasons you might find yourself writing Perl

  1. You and your team already know Perl
  2. You're working on a (perhaps legacy) application that was originally written in Perl and there is no reason to re-write it.
  3. You're looking for experience in a different language and way of thinking.

Perl people have a hippie/creative slant to them. They are artsy/fartsy in a liberal arts sort of way.

]]>