The Perl Renaissance

[nnq]

...don't get mad for the question, but: anybody has any arguments for using Perl instead of, let's say Python, these days? (besides the "I already know it incredibly well" argument)

...cause the lack of an answer to such a question has only one conclusion: the language is dying, even if this is not already happening in a visible way!

(don't get me wrong, I'm not a Perl hater, and fyi, I think the world would be a much better place if Rasmus Lerdorf would have learned Perl and written a nice Perl web framework instead of inventing PHP :) )

[autarch]

...don't get mad for the question, but: anybody has any arguments for using Python instead of, let's say Ruby, these days? (besides the "I already know it incredibly well" argument)

...cause the lack of an answer to such a question has only one conclusion: the language is dying, even if this is not already happening in a visible way!

(don't get me wrong, I'm not a Python hater, and fyi, I think the world would be a much better place if David Heinemeier Hansson would have learned Python and written a nice Python web framework instead of inventing Rails :) )

[eCa]

That question can be turned around: Why should someone use Python (or Ruby) instead of Perl?

For someone who hasn't used any of those, I'd say give each of them a few hours and see which style suits you best. Of course, try to find modern examples to learn from. When it comes to Perl that means:

* Mojolicious [1] (or Dancer [2]) as the web framework

* DBIx::Class [3] as the ORM (maybe with some sugar [4])

* Moose [5] (or Mouse or Moo) as the object system

[1] http://mojolicio.us/

[2] http://www.perldancer.org/

[3] https://metacpan.org/module/DBIx::Class

[4] https://metacpan.org/module/DBIx::Class::Candy

[5] https://metacpan.org/module/Moose

[toddh]

Text processing with interpolation, the dynamic type system, and regular expressions is insanely easy as they are integrated directly into the language. You don't have a lot match, compile, and match group type scaffolding in your code.

[knotz]

It's a very fun language to begin with. Which is not unimportant if you want to keep being motivated after three decades being a programmer. Peter Norvig described 7 features which made Lisp different. Perl shares 6 of them. Important features like first-class functions, dynamic access to the symbol table, and automatic storage management. (source "High Order Perl" by MJ Dominus).

[wiremine]

> anybody has any arguments for using Perl instead of, let's say Python, these days?

The Perl community is software's Maker subculture [1]. They have a "heck yeah, we'll give that a try" perspective lacking from other subcultures. The the larger software ecosystem ever lost this Maker/Perl worldview, it would be a huge lose.

Taking a step back: In some ways, I think languages get larger adopted because of their culture. Their technical implementation is just a manifestation of the culture. (And, I think this explains why LISP has never broken out. It isn't a language problem, it's a cultural problem).

[1] http://en.wikipedia.org/wiki/Maker_subculture

[drucken]

- CPAN

- efficient and compact regex scripts

- one-liners.

Of course, some of these could be considered a reason NOT to use Perl depending on your specific circumstances.

[wazoox]

Python significant white space. Really, that's what preventing me for ever liking Python.

[cpressey]

Mainly for the sake of completeness, I will mention: block scope. I program in Python a lot, and I like it, but it always boggles my mind when I remember that block "locals" are still visible after a block is closed. JS and PHP are (I believe) the same way about this. The Perl (and C) approach of "proper" block scope feels much less icky to me.

[edwinnathaniel]

Universal on NIX systems.

Python has a few 2.x versions depending on the Distros. Some distros may opted to go 3.x only.

Ruby isn't necessarily universal on NIX systems.

Perl is.

[walshemj]

CPAN is probably the main one when i built a front end to authority labs api all of the heavy lifting (apart from the Callback handler) was done using perl modules

[wschroed]

Tail recursion. ;) Bioinformatics.

I am currently looking for a couple software developers (https://news.ycombinator.com/item?id=5203736) for positions where Perl is the dominantly used language.

[mhd]

So it's dying, but not visibly? I can't really parse that, but I bet the answer will contain quite a few Perl 6 references…

[nnq]

disclaimer: I really didn't intend to transform this into a discussion that's 70% about Python (I could have said Ruby or Javascript instead, the question was about Perl and the comparison was just an example). Right now I would downvote my own parent comment if I could, just to get higher the other comments that are actually relevant to Perl programmers.

[jrockway]

CPAN.

[mpdehaan2]

I would recommend starting with MooseX::Declare instead of Moose if you are trying to upgrade your Perl, as Moose is great above standard Perl OO but doesn't go far enough by itself.

Previously I found that MoooseX::Method::Signatures was very slow, so I ended up selecting Method::Signatures::Simple.

Coupled together, you end up code that looks somewhere between Ruby and Java. It's not my first choice for a new project, but it's not a bad way to fixup an old but large codebase.

Possible code example:

https://github.com/mpdehaan/Elevator/

[oneandoneis2]

Wow.. I've been using Perl heavily for the last three years and he still managed to cram some amazingly useful stuff I didn't know into that short talk.

Well worth watching if you still equate "Perl code" with "line noise" :)

[jlikesp]

Anything you can build in Perl, you can also build in Ruby or Python (or hell, even PHP), so it seems rather pointless to argue any of these solutions are superior to another.

At the end of the day the choice is largely personal preference (or company requirement). Also, I know plenty of programmers who still earn a living writing Perl, so it's clearly not a dead language by any stretch of the imagination.

Personally, I would LOVE the chance to work on a Mojolicious project. IMHO that's the best web application framework today (in any language).

[psadri]

Perl unfortunately has a bad image vs its true reality.

I think Perl / Python are interchangeable as a language choice for web scale projects. If your biggest problem is whether to use Python vs Perl vs X, then I say good luck to you -- you should really have more important problems to worry about.

I'd never use ruby for a web scale project (as evidenced by the many services solely dedicated to scaling ruby on rails apps). PHP is not really a language.

Maybe the future belongs to ECMAScript.

[joel_perl_prog]

Great talk! I've never posted before, but I'm inspired to today. Forgive me if my code is formatted terribly this post.

I used Perl back around 2000, like everybody else, to make CGIs. Then went away from it for a long time. But I've used Perl over the last year to create a large DMCA takedown system, the bulk of which is spidering and analyzing web pages for infringements. Torrent trackers, one-click file download sites, etc.

It's been a beautiful experience. The code runs quickly (for a scripting language), and CPAN is AMAZING. I feel Perl was the best choice for this project, and since I enjoy the language--and trust me, it's NOT line noise: these aren't little scripts, this package-based, documented, modular software development, the likes of which people normally associate with Java (for instance.

I have to say I disagree with one point in that talk. I don't think there are "too many" ways to do OO in Perl--and this sort of ties into his gripe about "@_" and slurping in subroutine arguments, which I think is pure joy. I'm not certain, but I think Larry Wall got this from Lisp. Please correct me if I'm wrong on my history there.

Anyway, in one package that I use as an object, I have this code:

    #/ @param object $this    an Offense::Analyzer
    #/ @param string $event    an EVENT_x constant value
    #/ @param int $targetId    a target id
    #/ @param int $obvious    TRUE for obvious offenses, or FALSE
    #/ @param int $same    TRUE for offenses found on the same target, or FALSE
    #/ @return int    the value for the given event, or undef
    sub getEvent($$$$$) {
        my ($this, $event, $targetId) = (shift, getEventFor(shift), shift);
        my $obvious = getObviousKeyFor(shift);
        my $same = getSameTargetKeyFor(shift);

        return undef unless $this->hasTarget($targetId);
        $this->{'data'}{$targetId}[$obvious][$same][$event];
    }

And I supplement that code with the following convenience getters:

    sub getIgnored($$$$) { shift->getEvent(EVENT_IGNORED, @_) }
    sub getNotified($$$$) { shift->getEvent(EVENT_NOTIFIED, @_) }
    sub getQueued($$$$) { shift->getEvent(EVENT_QUEUED, @_) }
    sub getRemoved($$$$) { shift->getEvent(EVENT_REMOVED, @_) }

I love the convenience of being able to use the incoming arguments array in this manner. In fact, because you explicitly pass the object reference as the first argument to methods in Perl, I even have this:

    #/ @param object    an Offense::Analyzer
    #/ @param string    an EVENT_x constant value
    #/ @param int    a target id
    #/ @return int    the value for the given event
    sub getEventTotal($$$) {
        int(getEvent(@_, TRUE, TRUE)) +
        int(getEvent(@_, TRUE, FALSE)) +
        int(getEvent(@_, FALSE, TRUE)) +
        int(getEvent(@_, FALSE, FALSE));
    }

Those are not static method calls (so to speak--package sub calls), but are object method calls. I love that convenience.

Does your fluency need to be very high for this to seem like a good idea? Probably. And in this manner, Perl can never compete with Python. But I guess my argument is similar to the argument a lot of Lisp dialect programmers make: I'm an advanced user, I don't need to be babysat, I can take care of myself, and I'm ok with exploiting the expressiveness of the language.

[rotten]

Well, there is 'Moose' if you want to do OO Perl: http://moose.iinteractive.com/ Some folks I know swear by it. I just find Perl hard to read and not very intuitive. My perl loving friends, on the other hand, claim the opposite. I guess it depends on how your brain works and what you are used to.

[falsedan]

why aren't you using POD for your documentation

why are you mistakenly using prototypes for function signatures

[pfortuny]

The fact that they "like" the language.

Not noticing it does not equal "nonexistent". Your perceptions do not describe the whole reality.

Any turing complete language can do any job. As long as they are not astoundingly unequal, which is not the case, people choose based on... taste.

[ShiningRay]

I'm always looking forward to Perl6, waiting for its stable version, for 10 years.

[Roboprog]

I think perl 5.10 and beyond kind of preempted perl 6.

Alas, perl 6 in some ways isn't even perl. Perl 6 is cool, but Larry should have made a new name for his next hobby :-)

[eCa]

Perl 5 and Perl 6 are two different languages; Perl 6 is a sibling, rather than successor, to Perl 5.

http://dev.perl.org/

[berntb]

As I understand, it has been going on for as long as Python 3 -- which is starting to be used in a few places now. (The difference is that Perl 6 is really, really, really ambitious. Let's see if it ever gets production-ready.)