Perl is 26 Today

That's cool. :) But I'm sure the correct statement would be untangling messy code written in "your non-favorite language" and rewriting it in "your favorite language or management's choice based on buzzwords". :)

Are there any new Perl jobs in 2014?

Is there growth in the actual number of Perl full-time positions or is it declining?

Companies obviously need Perl programmers to maintain and enhance existing systems, but we don't see or hear about any new start-ups using Perl as part of their stack.

Fwiw: I don't use Perl anymore but was a fan and love Moose and CPAN.

Ha ha, your nickname says it all. Back when I started programming in 2000 all my yahoo, MSN and skype (when it was released) accounts either had the word linux or perl in it.

Then unfortunately I had to become more professional and started using my real name. :)

The wrong turn was "Perl 6", and despite what you may think, the problem was more in the "6" than the "Perl". There's nothing wrong with Perl 6, except that it should have been called something else so it didn't convince people it was the next Perl version. The Perl community has now recovered from that, Perl 5 and Perl 6 are officially understood to be distinct languages that merely love each other very much, and Perl 5 development has resumed at full speed, but it lost a lot of time and mindshare before finally getting there. (Probably not a heck of a lot of use share, though. It's still there in a lot of places, working away, quietly.)

I'm not the OP, but I've had a similar experience and agree with him about Perl.

For me...

* perl is a bit more intuitive, even though I've done about as much python as perl at this point.

* It's the best language for dealing with regular expressions in my view. You don't have to create a regex object and muck about with all of that.

* You can create lambdas/closures with fewer restrictions than Python (this is a big one)

* CPAN is pretty good. Python comes with a lot of libraries, so this isn't as much of an edge as it used to be.

* It is more widely available on other servers, even older ones, which is important for me because I'll sometimes have to do work on a machine without Python already installed. I can work with older perl and I've never been on a machine without it installed.

* The whitespace issue really is annoying to me. With braces you can move stuff in and out of conditionals, etc, easier than with Python, even with editor support.

As for readability, I try to write reasonably well, even if in a hurry. I know the language and its syntax. I understand the purpose and meaning of the sigils, so it doesn't look like noise to me anymore than reasonably written python. In Python, for instance, I've seen list comprehensions that are pretty frustrating to puzzle through. Perl with strict and warnings and written without a specific aim to be clever isn't hard to read.

perl is more connected to things flowing through it. In python I was often fighting with the subprocess module to get things plumbed but in perl it was trivial to open a process to a pipe and then put a process on the output of that pipe. Much of the code I've written here does analysis for bad actors (robots and such) and perls regular expressions have been easier to get right sooner. (although the naming of results in Python is quite useful).

When I was at Google I started using Python to create a CMS of sorts for my toy website (robotics.mcmanis.com) which got to the point of being able to push some stuff but more complex stuff was a pain. So it sat there. Then rebuilding that with perl and the template toolkit it was a bit easier and I was much happier with the result. I still don't have a lot of time for it (like none for the last few months) but I got the framework for putting up a new "article" down to a pretty smooth process and managing all the internal links worked well.

Perhaps it is that I programmed in C for so long that my synapses are more attuned to reading code with braces. But I find I can look at perl and intuit its function much more quickly than I can do the same for Python.

Here's more information on the linguistic development of starting sentences with 'So':

http://chronicle.com/blogs/linguafranca/2011/12/02/so-it-tur...

It is a reasonable question. I tend to write like I talk, which the Chicago manual of style frowns upon. It isn't a particularly 'creeping' pattern, it is quite common amongst people with whom I have regular informal conversations.

That said[1], I probably feel the same way about the use of 'because' in informal speech. Which was recently upgraded to include the form "because <noun>." I don't find that a particularly compelling upgrade.

[1] Another habitual favorite of mine.

Python has a standard library called multiprocessing [1] that uses multiple processes (surprise!) to get around the GIL.

[1]: http://docs.python.org/2/library/multiprocessing.html

> My understanding was that Python interpreter has a GIL, which limits the concurrency and performance.

Python is in that respect essentially the same as Perl with Coro built-in. ( https://metacpan.org/pod/Coro )

I'd rather have a language where i can look at the code and decide with a glance whether it's batshit insane or not, than a language where the best code possible looks just like the most horrible and insecure garbage. :)

So you can't stand any and all programming languages? Because you can do anything in more than one way in all languages. And that's the whole point in 'programmability'.

And secondly its extremely rare that you will run into some obscure feature which indulges in the whole parsing thing you mentioned.

I chuckled aloud at that one, and (funnily enough) it rings true!

Very similar to my line of thinking this morning.

Sadly, Programming Perl is a bad book for a newbie to read nowadays. http://perl-tutorial.org explains why and suggests newer alternatives. :)

And which is available online at: http://hop.perl.plover.com/book/

I spend less time “working around language deficiencies, inadequate tooling and all the rest of it” in Perl than in, for example, Python.

I run into many Scala fans amongst Java developers. It's the current shiny thing in that technology area. Good old Java (of a similar age to Perl) is usually what they're making their living doing...

The Perl culture is very much "Wild West" meets the race to space.

It's a language for people who are comfortable enough around theory that they don't need syntax to force them to use it.

At the same time, it's highly evolutionary -- it supports the fastest, dirtiest, hackinest method of getting to the goal -- and thus has prototyping built in to production.

I often write Perl scripts twice. The first is a tape-up job to "git 'er done" and the second is a more elegant and architected approached.

This method matches the configuration of most jobs. The client doesn't (fully) know what they want. Last-minute, world-bending exceptions arise. Well-intentioned schemes gang aft agley.

With this prototyping-production, I'm able to get something up and working, and can fix it later if the client has foresight.

Theory is great. I am the first to defend theory. But if it doesn't correspond to application, there's another word for it: arbitrary.

(You may note the difference between two predominant value systems illustrated in that sentence.)

I guess I would need to know who "the rest of us" and the "interesting things" are.

wow. You're an unbelievable ass and, obviously, immature/inexperienced to boot.

> Language design isn't done, and languages are getting better all the time.

That is actually what Perl is doing. With its loose original design it can evolve amazingly, and in ways that couldn't be foreseen.

I would say "pretty fantastic" is an understatement...CPAN is the gold standard of library support

max and min are part of List::Util, a library that comes with Perl

>> max, min [etc]

Perl has a minimal std library, to teach people to use CPAN I guess. But even Perl has util modules for trivial help functions in the std install (at least those which aren't one line of code to define).

The strongest argument for Perl today is CPAN and CPAN Testers, still the gold standard.

But all the scripting languages are really similar, there is no reason to learn another if you already know one.

Edit: You might want to check out the Modern Perl book, free online. Perl evolves quite fast.

> I moved from Perl to Python 3 years ago

But Perl-like ambiguity still seeps into your English. Was that Python 3, or 3 years ago?

I used to use Perl. Then I followed Yegge's advice of "I will only use Perl if there's no other option, and there's always another option." https://sites.google.com/site/steveyegge2/ancient-languages-...

I'm not trying to dump on perl. I love C and C++ and those get dumped on all the time and I hate it. But anything I could do in Perl I instead do in Ruby. It's not as fast, but if fast matters I'm not supposed to use a scripting language.

Let me point out http://perl-tutorial.org because most books you'll find by simply googling are terribly outdated and teach, plainly put, how to write shitty perl. Modern Perl and Ovid's Beginning Perl (not the older Beginning Perl) are excellent books to learn from.

Also a note about the sigil: Get a decent syntax highlighting set up for your editor and you'll quickly realize how nice it is to have functions, variables and different variable types colored differently.

Unfortunately -- and this is one of the many "banana peels" in Perl 5 -- even a simple statement like

    print x if x > 5

is problematic in p5 for a whole bunch of reasons:

(1) At a bare minimum, what you really need to say is:

    print "$x\n" if $x > 5;

That extra "\n" is a definite turn-off to a lot of people when the get their very first look at Perl. Really, the default these days should be more "say"-like. Of course, "say" is there as of 5.10 if you know where to look for it, and you go out of your way to enable it:

    use feature 'say';
    say $x if $x > 5;

(2) In "modern", better practice, production-quality Perl you pretty much have to either hedge every comparison op with a check for defined-ness:

    use feature 'say';
    say $x if defined $x && $x > 5;

in order to head off an unsightly warning about $x not being initialized:

    Use of uninitialized value $x in numeric gt (>) at print-if.pl line 5.

or add even more boilerplate to suppress the warning:

    use feature 'say';
    {
        no warnings 'uninitialized';
        print $x if $x > 5;
    }

or be very attentive about how $x can mutate once it's gotten passed whatever validations you're imposing on it before it enters your scope -- via e.g. Params::Validate, Method::Signatures, provided you know these tools exist and are up to speed and hip as to how to use them effectively.

(Yes, I know that in some contexts, the warning on 'uninitialized' can be very useful. But my point is, most of the time, and especially for novices, it's more of a misfeature).

(3) We shouldn't gloss over the fact that the magical pseudo-grammatical construction the "infix" if syntax provides is itself problematic in many ways.

In the current example, it simply isn't clear -- until you've become very comfortable with the language! -- if the original statement

    say $x if $x > 5;

is or is not equivalent to the very similar construction

    $foo = $x if $x > 5;
    say $foo

This is because it is by no means obvious as to which of the more "active" parts of the original expression -- either the "verb" (print) or the conditional (if) -- takes precedence.

And unfortunately, it's not only possible, but terribly easy to "whip up" fare more volatile constructions like this in Perl 5. Various on this theme -- gotchas about print, conditionals, and complex "if/unless" constructions -- were of course given ample treatment in Perl Better Practices, to the point where (I believe) that Damian pretty much eschews "trailing" if/unless constructions altogether.

(4) Lastly, it's sad to say that for all the complains of Python having too many safety belts and what not, it completely nails the hidden complexity management issues embedded in such a simple construct like Perl's "print-if" idiom.

In Python, basically the only sensible way to achieve the original desired result is to do this:

    if x > 5:
        print x

Perfectly clear, completely unambiguous, and basically impossible to screw up.

One of Perl's strengths, actually, was (is?) how well it was supported on many different types of systems. Today's world is largely Linux/Windows/Mac, but that was far less true in the 90s.

I started using Perl on VMS, where there was no sed, (g)awk was new, no grep ("search" did not handle regular expressions, "find" did but arrived very late); and the command language, while sane, was very slow. Perl's system integration on VMS was excellent.

It prints the greater variable between $x and $y.

[$x => $y] creates an array reference. => is just a fancy syntax for a comma. So its actually [$x, $y].

[$x => $y]-> dereferences the array ref.

$x <= $y is a boolean expression which return 0 or 1. Accordingly the array index is chosen.

Sorry if I'm unable to explain properly! Here's a script.

    #!/usr/bin/perl
    use strict; 
    use warnings;

    my $x = 8;
    my $y = 9;

    print [ $x => $y ]->[ $x <= $y ];

It’s a highly cryptic way to find the maximum of the two. The first part creates an array (=> is just a syntactic sugar for a comma here) and the second part takes the 0th or 1st item from this array, <= being just regular numeric comparison.

The same thing as ($x, $y)[$x <= $y] but it looks cooler.

Might I ask, in a nutshell.. why not CGI?

There is a learning curve, but I am fond of mod_perl because you can do almost anything with it. It's also very fast.

http://perl.apache.org/docs/index.html

You can wrap your existing CGI scripts in it using

http://perl.apache.org/docs/2.0/api/ModPerl/Registry.html

so the transition can be rather smooth

Depends on what you are doing and how much traffic you have and what web server you're sitting behind.

For example: emacsformacosx.com was straight Perl CGI until about 2 weeks ago.

whats so bad about CGI, even after FCGI?

The link seems to be a dead end.

I would also venture that much of the transitions are feedback loops. So person A makes a new shiny in python for no reasons relating to superiority of language for job x, but because person A is good with it. Well, if what he makes is good, people start using it. Then it breaks, and they have to fix it, or maybe get an idea to fork it. Suddenly, person A's software just encouraged 20 people to hop into python for no real concrete reason. On the bio side, bio-python is just much more intuitive imho, vs bio-perl.

Maybe that explains why some (all actually) of the really bad code have seen has been from Bioinfomaticians. I have seen terrible code in both Perl and Python though.

Why not? PDL exists for numerical computation. Works fine.

You can probably do those with PDL.pm :)

http://pdl.perl.org/?page=screenshots/index