Live data from Hacker News

Why I Use Perl: Reliability

modernperlbooks.com

71–80 of 196 posts

Re: Why I Use Perl: Reliability

#71
post #66
post #9

Any language would be improved if it had Perl's testing and library culture. Two things it's absolute unsurpassed at so far.

Does ruby not have the same level of both?

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. Things like meta.cpan.org and cpantesters.org are a god send that I wish I had when I'm using other languages.

And the testing infrastructure rocks.

It's evolved so everything produces and consumes TAP (http://testanything.org/) a simple human-readable protocol for expressing pass/fail results (with standard modules that help people output and consume TAP).

This means I can write tests procedurally, or in an xUnit style, or a BDD style, or a specification-based testing style, or use various DSLs for things like exception testing or for testing web apps... and so on.

I just use the style that seems most appropriate for the thing being tested. They all output TAP. All the standard test runners consume TAP. Everything "just works" and plays nice together.

I can even easily integrate tests running in other languages or environments as long as they output TAP.

In addition - since almost all of the Perl testing modules use a common TAP output module - you can usually integrate different styles in the same test code. So, if appropriate, I can pop some specification-based tests and some friendly web-testing DSL as assertions inside my xUnit tests.

Fun :-)

Wish other languages test environments were setup this way.

Re: Why I Use Perl: Reliability

#73
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.

I actually like the explicit "I'm reading from a special list" syntax because that's what it's doing. A lot of Perl's "ugliness" comes from the language being pretty honest about what it's doing.

Re: Why I Use Perl: Reliability

#74

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…

Are there really any compelling reasons to use Perl over Ruby for greenfield projects (i.e. not legacy maintenance)? I've written maybe a dozen medium-length Perl scripts (but nothing very large) before I got into Ruby, and I can't seem to think of anything that Perl does that can't be done at least as well in Ruby. Honestly not trying to start a religious war here - just curious - and I think it's fair to compare th…

Are there really any compelling reasons to use Perl over Ruby for greenfield projects....

That's exactly what I'm doing. Reliability is only one reason I chose Perl over Ruby, but upgrading three real-world applications my business relies with their dependencies on to a new major release of Perl 5 in an afternoon while doing other things and only having to intervene three times is a tremendous boon.

Upgrading from Ruby 1.9.2 to 1.9.3 wasn't that easy.

Re: Why I Use Perl: Reliability

#75
post #73

Earlier quoted context omitted.

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

I actually like the explicit "I'm reading from a special list" syntax because that's what it's doing. A lot of Perl's "ugliness" comes from the language being pretty honest about what it's doing.

Actually, though I tried C++ starting in 1993, Java from 1996, I didn't really grok OO until I tried it in Perl a few years later. Because it shows its guts out, without any sugar coating, I understood what it was about.

Re: Why I Use Perl: Reliability

#77
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…

Guess it is because perl is mostly used by sysadmins, you know shell on steroids to do the job -> scripting. Other reason can be because perl is changing in details all the time, well mostly adding useful stuff. I remember, in one moment it didn't have switch statement, after one not so big update it had :-)

Re: Why I Use Perl: Reliability

#78

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.

I know of ShutterStock (NYC) and Aruba Networks (Sunnyvale) (AirWave team only). AirWave was interesting, but I don't know what they're doing over there anymore since I left and there's been some management shakeups (some of which may have been positive). Shutterstock is where a former coworker went; he says it's snazzy and they just filed for IPO.

I also hear Blekko is all Perl (it's the dmoz directory-people making a search engine. it's got social-search-related features, too, or something like that.) Apparently they have some fancy sophisticated technology for their backend systems (store big bitfield indexes on SSDs with a disk-backed store for the rest, spread across dozens of nodes, etc.) But I don't know anyone actually working there.

If you have the initiative you can look up their job applications yourself :P

Re: Why I Use Perl: Reliability

#79
For any value of $LANGUAGE, imagine this situation: your boss comes to you and say "Hey, they just released a new major version of $LANGUAGE today. Can you go upgrade it on all our production servers?" What is your emotional response to that request? For many values of $LANGUAGE, there would probably at least some element of terror (for many languages, probably much more than just "some"). But Perl is one where, depending on the circumstances, the response could plausibly be as article says: boredom. "Yeah, sure, whatever. I'll go upgrade them." (Certainly there are others, but Perl is definitely one of the best in this regard.)

Re: Why I Use Perl: Reliability

#80

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…

Are there really any compelling reasons to use Perl over Ruby for greenfield projects (i.e. not legacy maintenance)? I've written maybe a dozen medium-length Perl scripts (but nothing very large) before I got into Ruby, and I can't seem to think of anything that Perl does that can't be done at least as well in Ruby. Honestly not trying to start a religious war here - just curious - and I think it's fair to compare th…

For me, personally, these are some of the reasons:

* I've had more years of Perl than I have of Ruby. While there's not a massive difference it comes a bit easier to my fingers and brain.

* The testing framework is better - it's much easier to integrate different styles of testing and integrate tests running in other languages

* I can usually get more people to do my work for me with CPAN than I can with rubygems

* Moose has some interestingly different ways of breaking up abstractions (Moose is the de facto way of doing OO in Perl now. Moose is to Perl as CLOS is to Lisp)

You're probably not going to be suddenly more productive if you switched to Perl - but there are some plus points. As does Ruby of course.

Swings or roundabouts. Your choice :-)

Post reply on HN