Why I Use Perl: Reliability

The whole point of automating tests is so you can run them unattended: at install time, or under a continuous integration system after code check-ins, or for git pickaxe to find which change caused a bug, or whenever else you want to confirm that a whole lot of code still works as intended.

That makes it easy to use a cpan module with confidence, which imo is not valued highly enough in other language communities cpan-like structures.

1. http://rubygems.org/stats

2. http://rubygems.org/gems?letter=A

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

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

I find it interesting that PHP doesn't have anything in the same league as Perl/Ruby/Python even after all these years.

Any PHP folk out there?

[1] http://www.quicklisp.org/beta/

This being said, this is not a snipe at how PHP or Python do it. It's a choice of the maintainers/developers.

So demands of a software project in the real world are very different than the academia. Although you can argue that Lisp is far more a better language than Perl, based on some parameters you wish to evaluate. Others might have totally different parameters, for example in terms of mere usability and pace of getting things done, Perl will fare better than Lisp.

While evaluating two technologies it is really important to define the parameters you wish to evaluate them upon. Without that we are just comparing Apples and Oranges and then arguing that nutrition on one isn't better than the other. Unless we define who needs an Apple and who needs an Orange for what reasons, we won't be able to say which is better than what for what purposes.

There fore comfort is really a subjective term. For a professor sitting in a university with endless time at his disposal Lisp will make the perfect and most comfortable language. But me sitting on P1 ticket assigned to me, and given 45 minutes to provide with solution has no other option but to use Perl. In other news I just have a weekend to hack up a automation or produce a quick prototype. You know what language I'm going to use, Its Perl.

Not because I hate Lisp or I'm uncomfortable. Its just there is no other option.

You did read the very next sentence when I talked about my abandoning one Clojure solution for exactly this reason?

I love Clojure to death. It's excellent. But there are lots of folk like me who are just gasping to go play with production Lisp when other solutions would probably be better.

Not saying there aren't many great real-world uses for Clojure. Look at the stuff Datomic are doing for example... but I see lots of folk (myself included) spending two weeks tweaking Clojure stuff, dealing with warm-up timing issues for the JVM, etc. when we should probably just chuck something together with Sinatra and get the job done :-)

I assert that lots of folk are using perl because it's comfortable to them rather than it being the best solution.

Agreed. Sorry if I seemed to imply otherwise.

Nothing beats a mainframe for throughput & reliability and lots of the code is still COBOL.

IIRC SocGen has a vast amount of code written in some awful monstrosity of an internal language that nobody else has used for decades, but the cost of changing everything over to something more modern is so prohibitive that they just keep on accreting over the existing codebase.

Short answer: Yes :-)

Still the backbone of many banks, building societies, credit card companies, etc. See http://www.careerjet.co.uk/cobol-jobs.html for some of job adverts. This old 2009 article http://www.guardian.co.uk/technology/2009/apr/09/cobol-inter... is still pretty much true AFAIK.

All of the other languages I mentioned are roughly as OO as Perl. (You sometimes have to go looking for it, and Perl's probably ultimately the weakest at the core, but it's still there and mostly strong enough it doesn't matter.)

I have nothing against IDEs. But anybody who claims to know a language must at least able to work with the source code and semantics.

If a person absolutely can't code at all. I mean slowly is still acceptable. But if he absolutely just can't write code without an IDE, I would doubt his claims of knowing the language.

Knowledge of tools != Knowledge of a programming language.

When not using perl5i or playing with MooseX::Declare I will usually default to Params::Validate so your example would look like this:

  sub function1 {
    my ($code, $arr) = validate_pos( @_, {type => CODEREF}, {type => ARRAYREF} );
    ...
  }

Also, sometimes you just want to work on an arbitrary list of items. If you process one item and then shift it, that's a reasonable thing to do.

2. If you adopted the convention in 1, this shouldn't bite you. (I've never actually encountered this issue myself...)

3. You are misinformed. You can easily do something along the lines of:

    f({a => 'foo', b => 'bar'});
    
    sub f{ my ($args) = @_; say $args->{a}; }

do_stuff(Foo => 1, Bar => $baz);

sub do_stuff {

    my %args = @_;

    my $foo = $args{Foo};
    # etc...
}

By contrast, I assume you can say something like "Object-oriented software engineer (Python)" or "Object-oriented software engineer (Ruby)" (or Frontend Engineer / Backend Engineer / etc) and not have this particular set of problems. I don't know what problems you would have, but... not those.

Now, to be fair, it worked marginally better when the company-recruiters weren't all jerks about letting us post a programming challenge with the posting (because it didn't fit in with a preexisting workflow)... which makes it easier to find the random Spanish major with decent programming instincts and a little Perl. But still.

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

* 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 :-)

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.

DBIx::Class, Moose, Catalyst, Template Toolkit - these are a joy to work with. People seem to be just ok that they have Rails, bitch about Active Record, and honestly, just don't seem to love their tools.

TAP-based testing is awesome sauce. Ruby gets this so wrong with all tools checking return values of scripts + the occasional hacked together jUnit outputter. Even the testing tools stolen from Ruby (like Test::BDD::Cucumber (which I may have written)) use TAP and Perl's testing tools all the way down.

Finally: there's CPAN. It Just Works. I started off a Perl dev, and use of any other language's package system has just made me sad face.

http://www.net-a-porter.com/ http://www.lovefilm.com/ http://www.photobox.co.uk/ http://www.booking.com/

Send me a CV and I can make sure it gets to the right people.

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

http://duckduckhack.com

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

[1] http://blogs.msdn.com/b/oldnewthing/archive/2007/08/16/44070...

First one (not 100% sure it's constant memory, I think perl optimises the for to avoid instantiating the (1..$n) list:

    #!/usr/bin/perl
    use Modern::Perl;
    use bigint;

    say fact(5000);

    sub fact {
        my ($n) = @_;

        my $output = 1;
        for my $i (1..$n) {
            $output *= $i;
        }
        return $output;
    }

The reduce version (again, I'm unsure of const mem req). Comes in at ~1.4s:

    #!/usr/bin/perl
    use Modern::Perl;
    use List::Util qw(reduce);
    use bigint;

    say fact(5000);

    sub fact {
        my ($n) = @_;

        return reduce(sub { $a * $b; }, 1, (1..$n));
    }

    

    sub { my ($x) = @_; $x + 7; }

Edit: I think the languages are comparable in terms of features and also readability. People may dislike leading sigils and that's fair, but I dislike python's "no need to declare your vars, just hope you don't typo an assignment" approach to lexicals.

    use bignum;
    use v5.10;

    =cut
    def Factorial(x):
      output = 1
      for i in xrange(x):
        output *= (i + 1)
      return output
    =cut


    # Direct translation
    sub factorial {
      my $x = shift;
      my $output = 1;
      for my $i (1 .. $x) {
        $output *= $i;
      }
      return $output;
    }

    say factorial(200);

    =cut
    def Factorial2(x):
      return reduce(operator.mul, xrange(1, x + 1), 1)
    =cut

    use List::Util "reduce";

    sub factorial2 {
      my $x = shift;
      reduce { $a * $b } (1 .. $x);
    }

    say factorial(200);

    =cut
    def Power(a, b):
      if not b:
        return 1
      if b % 2:
        return Power(a, b - 1) * a
      x = Power(a, b/2)
      return x * x
    =cut

    sub power {
      my $a = shift;
      my $b = shift // return 1;
      
      if ($b % 2) {
        return power($a, $b - 1) * $a
      }

      my $x = power($a, $b/2);
      return $x * $x;
    }

    # lambda x: x + 7
    my $plus7 = sub { $_[0] + 7 };
    # Or:
    my $plus7 = sub { my $x = shift; $x + 7 };

    say $plus7->(14);

    =cut
    def TweakValue(x):
      return x + 7
    =cut

    sub plus7 { $_[0] + 7 }
    say plus7(14);

Umm, did you mean:

    def factorial(x):
        output = 1
        for i in xrange(2, x):
            output *= i
        return output

    use List::Util qw(reduce);

    # This is how I would write it.
    sub fact1 {
        my $num = shift;
        my $output = 1;
        $output *= $_ for (2 .. $num);
        return $output;
    }

    # Most people don't prefer inline loops and $_ variable, though
    # I don't see why not.
    sub fact2 {
        my $num = shift;
        my $output = 1;
        for my $i (2 .. $num) {
            $output *= $i;
        }
        return $output;
    }

    sub fact3 {
        my $num = shift;
        return reduce { $a * $b } 2..$num
    }

Although I'm not sure whether describing Perl as the Vietnamese of programming languages would be a good selling point, so I'll stick with French ;)

Perl is a power tool. The reason it can be unreadable is because of it's terse syntax, wherein resides its power. If you value readability above power then you choose Java, and I would agree that for a large enterprise app developed by an army of mediocre developers then Java is surely the better choice. However to judge the absolute merits of a language like Perl on reputed readability, without taking into consideration what its terseness allows, and how it works for large scale development given a sane coding standard is just burying your head in the sand.

You will be shocked how few tools are there for the other kind of data.