Live data from Hacker News

Why I Use Perl: Reliability

modernperlbooks.com

101–110 of 196 posts

Re: Why I Use Perl: Reliability

#101

Earlier quoted context omitted.

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 Ru…

It depends on your infrastructure. Some setups just don't have an infrastructure setup to make the transition easy.

Re: Why I Use Perl: Reliability

#102
post #48
post #44

Earlier quoted context omitted.

that also highlights one of my perl peeves - having to scrape function args out of @_ rather than declaring them as part of the function definition.

Yes, that sucks. It's not much extra typing: def function(x, y, z): versus sub function { my ($x, $y, $x) = @_; } The overhead is only really the 'my = @_;' chars, but it is annoying. On the other hand, it does allow you to do things like partially unpack args and pass the rest as a bundle to a super class.

You can partially unpack in Python too:

  def method(self, *args):
    a, b = args[:2]
    super(self).method(*args[:2])
Perl's lack of using the definition for the variables doesn't necessarily make it 'more powerful.'

Re: Why I Use Perl: Reliability

#103

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…

The reasons I would cite: the Ruby development community leaves a lot to be desired from a sysadmin's perspective. We went through similar pains with Perl, but they're mostly a decade or two behind us. With Ruby, there are multiple concurrently maintained trees, it's hard to sort which one should be "primary" on a system, and you have to do a lot of serious grokkage to understand that RVM isn't really intended for maintaining system Ruby installs, but a local per-user developer instance. Which, when what you've got Ruby for is managing chef, is a more than slightly whack.

http://www.lucas-nussbaum.net/blog/?p=617 http://www.lucas-nussbaum.net/blog/?p=681 http://news.ycombinator.com/item?id=2059964

Much of Perl's use is by sysadmins, which means it plays well in their space. By contrast, much of Ruby's use is by web developers, many of them on bastardized MacOS systems (they're born bastards, it's not the developers' fault ;-). Which means that Ruby's packaging is whack.

I don't hack much of either, though work around both. The nice thing about Perl from my perspective is:

1. It's included with the system. I run Debian/Ubuntu boxes if I can possibly help it, Perl is of of the tools used to write a whole slew of system scripts, and as a consequence, it's very well managed within the distro. Red Hat/CentOS aren't far behind.

2. CPAN plays nice. Under Debian, your CPAN bundles are installed to /usr/local/ Debian's just sorting out where to store Ruby gems.

Thanks to chromatic for mentioning perlbrew. I've encountered RVM in the past month or so and have been trying to wrap my head around it. Understanding RVM in terms of perlbrew helps a lot: http://ithaca.arpinum.org/2010/06/13/rvm-and-perlbrew.html

Re: Why I Use Perl: Reliability

#104
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?

Check this site out for a comparison of the various module counts per language. It is really incredible that rubygems surpassed CPAN last year and continues to grow at a very rapid rate. Quality may be another matter, but still, impressive.

http://www.modulecounts.com/

Re: Why I Use Perl: Reliability

#105
Language keywords:

Ruby ~40 Python ~40 Java ~50 Perl ~1800

Perl can have all the community support, packages, and testing that it wants, but I dislike programming in it and find it difficult to code in. This is not because I have only ever done Ruby or Javascript, I would consider my strongest languages to be Objective-C and Java, I have used C quite a lot, I know what I am doing with programming languages. I just dislike Perl.

Did you know there is a Perl package that will catch references to undefined symbols and fuzzy match them to the closest it can find in the current scope. To me, that seems to be the marker for the general quality of the code.

Re: Why I Use Perl: Reliability

#107

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.

DuckDuckGo is Perl.

http://duckduckhack.com

Re: Why I Use Perl: Reliability

#108
post #66

Earlier quoted context omitted.

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…

wrt testing, ruby is getting there with http://travis-ci.org

Also the rspec ecosystem is becoming more and more mix-and-match.

It's nowhere near as integrated as perl yet though.

Re: Why I Use Perl: Reliability

#109

Language keywords: Ruby ~40 Python ~40 Java ~50 Perl ~1800 Perl can have all the community support, packages, and testing that it wants, but I dislike programming in it and find it difficult to code in. This is not because I have only ever done Ruby or Javascript, I would consider my strongest languages to be Objective-C and Java, I have used C quite a lot, I know what I am doing with programming languages. I just di…

Where did you get the ~1800 figure? Is it possible you're thinking of PHP?

To me, that seems to be the marker for the general quality of the code.

There's also a module which allows you to program in Latin. Does that mean that every Perl programmer eventually has to live in Europe?

Post reply on HN