Live data from Hacker News

Why I Use Perl: Reliability

modernperlbooks.com

91–100 of 196 posts

Re: Why I Use Perl: Reliability

#91
post #83

Earlier quoted context omitted.

Short answer - no. CPAN has had many more years than Ruby's Gems to mature and develop. There are 2560 [edit: I was wrong. 39411 is the right number] gems on http://rubygems.org/ . There are 24,920 distributions on CPAN. Well over 100k modules. The automated testing infrastructure, documentation, etc. also makes it much easier to figure out what modules work on what systems and what versions of perl than in ruby land…

According to rubygems.org stats page[1], there are 39411 gems available. I think the number 2560 on "all gems" page[2] is the number of gems starting with letter "a". 1. http://rubygems.org/stats 2. http://rubygems.org/gems?letter=A

You're quite correct. My apologies.

I misunderstood the 39411 number to be the total number of gems submitted over all time, rather than the total number of extant versions. My bad.

Re: Why I Use Perl: Reliability

#92
post #89

Earlier quoted context omitted.

Ah yes, SBCL, the runtime that manages memory with a signal handler on SEGV. Stable!

That's a feature, not a bug. Write-protecting memory areas using mprotect() and the like, and handling the resulting SIGSEGV, is a popular technique for implementing a write barrier needed for generational garbage collection.

I've seen it used before to good effect, but one concern is that it's really easy to write flaky and unsafe signal handlers. Getting that right has never seemed easy to me.

Re: Why I Use Perl: Reliability

#93
post #87

Earlier quoted context omitted.

I do Perl on a daily basis, and I can't remember when I last blessed a ref. use Moose;

Do you use Moose, or MooseX::Declare? Moose has a startup penalty, but when I am willing to accept that, I would rather use declare extensions as well.

If the startup penalty is such a concern, There is Moo. And Mo. And M. Or failing that tools like Class::Accessor.

Re: Why I Use Perl: Reliability

#95

Earlier quoted context omitted.

The worst problem with Perl as a language is hiring for a good Perl programmer. It's easy to hire a mediocre Perl programmer, mind you, sometimes even a mediocre programmer who's really good at Perl specifically and knows all the packaging tricks and whatnot so he can get through the interview before falling apart on the job, but really hard to find the good ones. It just doesn't have much mindshare at the moment (ug…

I'm interested. I love Perl, and would love to work for a company that requires me to program in Perl. Care to share which companies are these? Thanks.

Best Practical in Somerville, MA is looking for perl hackers: http://bestpractical.com/about/jobs.html#hacker

(I've been using their perl/mason based ticketing system, RT, for 5 years)

Re: Why I Use Perl: Reliability

#96
post #23

The article makes a good point. But, the title (and comments here) infer that there are a mountain of reasons why people don't use it. Is there a compelling argument against that mountain, or is this just a reminder that Ruby/Python/Closure/Scala communities would be well-served to try and improve in this area?

The worst problem with Perl as a language is hiring for a good Perl programmer. It's easy to hire a mediocre Perl programmer, mind you, sometimes even a mediocre programmer who's really good at Perl specifically and knows all the packaging tricks and whatnot so he can get through the interview before falling apart on the job, but really hard to find the good ones. It just doesn't have much mindshare at the moment (ug…

I also know of two places looking for Perl hackers (I'm sure there are more):

  http://www.grantstreet.com/
  http://www.rentrak.com/
The first one is full remote, and I hear they have awesome benefits packages. I had two co-workers go there. I'm not sure if they hire outside of the US though.

Re: Why I Use Perl: Reliability

#97
post #49

The readability arguments need to include such modules as Method::Signatures::Simple, which replaces the old manual method (no pun intended) with: method foo ($a, $b) { $self->blargh($a + $b); }

I personally prefer the internal source filter that we use at work (though at the end of the day, it is a source filter). A friend of mine got permission to open source it, but that died on the vine (I think that he got into MooseX::Declare, then Ruby and lost interest), and now he's not at the company anymore.

Re: Why I Use Perl: Reliability

#98
post #83

Earlier quoted context omitted.

According to rubygems.org stats page[1], there are 39411 gems available. I think the number 2560 on "all gems" page[2] is the number of gems starting with letter "a". 1. http://rubygems.org/stats 2. http://rubygems.org/gems?letter=A

You're quite correct. My apologies. I misunderstood the 39411 number to be the total number of gems submitted over all time, rather than the total number of extant versions. My bad.

Don't worry, it happens all the time [1].

http://news.ycombinator.com/item?id=3238544

Re: Why I Use Perl: Reliability

#99
post #35
post #3

Reliability? Sure. Readability? Not so much.

Beyond the "You can write Fortran in any language" argument about properly structuring your code, there is a certain amount of truth in this. But in my opinion, this is mostly about familiarity. It's like a human language that uses another alphabet. Sure, if your native language is English, Polish looks more readable than Russian, as the latter is using a different alphabet. But that's a literally superficial point o…

The 'ghoti can be pronounced as fish' thing is a bit unfair to English orthography, where you must take the surroundings of the letter cluster into account.

Re: Why I Use Perl: Reliability

#100
post #49

The readability arguments need to include such modules as Method::Signatures::Simple, which replaces the old manual method (no pun intended) with: method foo ($a, $b) { $self->blargh($a + $b); }

Is "my ($self, $a, $b) = @_" really that hard to read? It's slightly more characters but I've never found it particularly annoying.

What's more readable?

Example 1 (my work's internal source filter format):

  sub function1( CODE $code, ARRAY $arr )
  {
    # body
  }
Example 2 (standard Perl):

  sub function1 {
    my ($code, $arr) = @_;
    die "Bad params." unless ref($code) eq "CODE"
                         and ref($arr)  eq "ARRAY";
    # body
  }
Example 3 (Method::Signature):

  func function1 (Code $code, Array $arr)
  {
    # body
  }
Post reply on HN