Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Perl Programming

Perl Is Undead 283

Ptolemarch writes At the Yet Another Perl Conference beginning today in Orlando, the first keynote squarely blamed Slashdot for starting the "Perl is Dead" meme in 2005. Let's be clear: if Perl was ever dead, it must now be undead. If you can't be at YAPC, you can still watch it live.
This discussion has been archived. No new comments can be posted.

Perl Is Undead

Comments Filter:
  • by cruff ( 171569 ) on Monday June 23, 2014 @06:31PM (#47301121) Homepage

    Meanwhile, Perl 5 being phased out of system building / admin tools and web frameworks. Even Perl 5 is dying.

    Not for me, I write new Perl 5 code all the time. Get some real useful work done with it too.

  • by Sez Zero ( 586611 ) on Monday June 23, 2014 @06:50PM (#47301263) Journal
    Perl 5.20 was just released [perlnews.org] and "represents approximately 12 months of development since Perl 5.18.0 and contains approximately 470,000 lines of changes across 2,900 files from 124 authors."

    That doesn't seem to bad to me, but I'm not sure how that number of core release authors compares to other languages like Python or Ruby.
  • by rduke15 ( 721841 ) <.moc.liamg. .ta. .51ekudr.> on Monday June 23, 2014 @08:36PM (#47302157)

    Is it dead? Well, some quick scripting can tell us the truth, using Bash and of course Perl.

    On my Ubuntu notebook and main machine:

    sudo find /etc /bin /sbin /usr/bin /usr/sbin -type f -executable -exec file -b "{}" \; \
    | perl -MData::Dumper -nle '
            next unless /script/;
            if ( /(shell|python|ruby|perl|bash)/i ) {
            else {
                warn "Other: $_\n"
            END {
                print Dumper(\%types);


    Other: a /usr/bin/make -f script, ASCII text executable
    Other: a nickle script, UTF-8 Unicode text executable
    Other: awk script, ASCII text executable
    $VAR1 = {
                        'perl' => 283,
                        'python' => 104,
                        'bash' => 1,
                        'Ruby' => 3,
                        'ruby' => 9,
                        'shell' => 602

    On a server:

    Other: a /bin/dash script, ASCII text executable
    $VAR1 = {
                        'Python' => 36,
                        'Perl' => 139,
                        'shell' => 267

    Looks very much alive. Unless of course, Perl realized what it was calculating and cheated and made it's own numbers up on the fly...

  • by cream wobbly ( 1102689 ) on Monday June 23, 2014 @08:39PM (#47302181)

    You've never touched a Red Hat OS recently then.

  • by Anonymous Coward on Monday June 23, 2014 @10:27PM (#47302887)

    Writing a virtual machine in C is dead-simple. It's just a loop over a table of opcodes. You can even get fancy and thread your dispatcher (that is, replace your loop conditionals with direct jumps to the next instruction handler), making it nearly as fast as JIT'd code because the CPU can pipeline all your virtual instructions.

    In fact, writing a virtual machine is arguably easier than writing an AST (abstract syntax tree) interpreter (which is what Perl5 is), because it's an elegant abstraction that cleanly separates areas of concern.

    If you can't write a VM in C than you're definitely not an experienced programmer. And if you think using LLVM to write an interpreter is easier, than you're just... I don't even know what... totally out of touch and have no clue how this stuff works.

    The VM isn't the problem. It's all the bells and whistles. The typing and object system. The FFI system. Garbage collection. Perl6 is a complex language, and they tried to bury too much of that complexity at the virtual machine layer. Or at least, they got tangled up in it.

    They couldn't use existing interpreters because at a minimum they wanted sane string prototype with a proper understanding of Unicode, something Java, C# and other systems lack. Perl 6's NFG (normalization form G) is a thing of beauty, but to make it fast you have to put it at a low-level. As for why they got hung up on all the other stuff, I don't know.

    To see what a fast, practical, feature-rich, and state-of-the-art (non-experimental) virtual machine looks like, I would recommend Lua's VM. It's about as simple as you can get and yet remain widely useful. It's completely written in portable, ANSI C (1989), it's several times faster than Perl, Python, Ruby and most other non-JITd interpreters, and the bytecode dispatcher is basically a giant switch statement inside a loop--very easy to read and work backwards through how the typing system works. (It could be made even faster by threading the dispatcher, but to remain concise and performant--without a mess of function pointers-- would require using a non-portable construct like computed gotos. Although the only C compiler I know of which doesn't actually support computed gotos is Visual Studio.)

  • Re:It should be dead (Score:4, Informative)

    by dargaud ( 518470 ) <slashdot2@gdarga[ ]net ['ud.' in gap]> on Tuesday June 24, 2014 @05:03AM (#47304339) Homepage
    Absolutely. I wrote in Perl for a year. I gave up when I figured out I couldn't understand pieces of code I'd written a month prior.

    And another issue for me was this whole There's More Than One Way To Do It philosophy which I find extremely frustrating. Write a piece of code in 20 lines and show it on usenet. Somebody writes it in 10. Then another one pipes up in 3. Then the true Guru comes up with a one-liner that nobody can grok. And they all run faster. Maybe.

    It also mean that when you read somebody else's code, you have to pattern that you can recognize. In C if I have to go through an array, you can bet there's gonna be a loop. In Perl, mystery, it could be any of multiple and rarely used constructs. The thing that made Perl popular at once was the integration of regular expressions, but we now have this in Bash =~, so why bother ?!?

  • by discord5 ( 798235 ) on Tuesday June 24, 2014 @05:07AM (#47304351)

    I moderated in this article, but this is something that I'd like to talk about for a bit, even if only anecdotal...

    Perl 5 is still charging full steam ahead in every sysadmin group I've been around. I know there are python advocates out there, but I have only encountered ONE major IT shop that is completely (or nearly so) python driven (and it happens to be Guido's employer -- hardly a good example)

    Over the past 8 years my own usage of Perl in writing code has declined to zero. There has been a mentality change over the years in the shop I work in, and where we used to grab for Perl by default as a quick'n'dirty duct-tape & MacGuyver language, we now exclusively rely on Python. I think there are several reasons for this shift.

    The most prominent one to me personally is that other languages have adopted CPAN-like repositories. I don't know about the statistics of numbers of modules, active development, number of commits, etc etc, and put bluntly I really don't care. Although these statistics are interesting into disseminating how active a language is to its developers, to me as a user of the language it only matters if a module is maintained and does what its supposed to do. The thing is, for most of the things I used to use Perl modules for, I now use Python modules, and can say "Well, it's good enough".

    Our development teams composition has also changed. A lot of our older generation of programmers/admins have retired or switched jobs, and a lot of younger people were hired to replace them. The younger generation is definitely more familiar with Python, Ruby and other scripting languages than it is with Perl. The incentive for learning Perl has become a lot smaller. Perl was the de facto language for many when writing a CGI script, but then RoR and AJAX happened. While over time Perl adapted (think Catalyst and Dancer) other languages have adapted as well. Look at all the wsgi applications and frameworks in Python.

    Our investment in Perl itself was more of the kind where we used a set of scripts to change data from format A to B at which point our Java and/or C++ code takes over, or some tools to deal with our logs, etc. The switch to Python for these tools was gradual (but quick) process, and we found ourselves not looking back. I can't really say that we were/are heavily invested in Perl or Python, but for day to day usage Python has completely taken over. Who knows where we end up in another 8 years from now?

    Lastly, if you were to go around our shop, asking people what's new about Python 3 you'll get pretty much right answers. If you go around our shop asking people what's happening with Perl 6, you will get a blank stare. I remember clearly how Perl 6 was going to become the best thing since butter on toast, ... There was general excitement about it all, and then there was a whole load of ... well... nothing. We're 11-12 years further and there's still no sign of Perl 6. What the hell happened there?

    Perl has only been dominant in the sysadmin space for less than 15 years ... I wouldn't be surprised if it lasts at least another 10 more.

    I don't doubt that Perl will be around for a whole lot longer. It has assembled a group of dedicated die-hard users and developers over the years, and in general it has a great community. There are older, more horrible languages that are still alive today, so I doubt Perl will be gone anytime soon.

    However, while my entire post is anecdotal, I do think the Perl community is deluding itself a bit. The talk in the video (I actually listened to it in the background while working on something) mentions a lot of statistics that are interesting to the Perl developers and maintainers, but are hardly and indicator of usage or adoption. The more interesting part of the statistical talk was about the general decline of jobs available for scripting languages in favor of newer technologies, but even those statistics in general don't speak much about usage and adoption.

    FWIW, may Perl be around a long long time. Having more tools at your disposal is never a bad thing.

The intelligence of any discussion diminishes with the square of the number of participants. -- Adam Walinsky