7 ms·

Why Perl isn't Going Away Soon (Or Ever)

34 points by fogus 17y ago

eli 17y ago
...because it's holding the entire internet together?
- plinkplonk 17y ago
  "because it's holding the entire internet together?" Could someone explain what this means in some detail? I hear this all the time but I could never make any sense out of it. Sure once upon a time perl was the best way to get cgi scripts running and do some web programming. Other than this piece of history, any specific examples of the "holding the internet together" property perl is supposed to have? What part of critical internet infrastructure depends on perl? I am no networking expert but it seems to me that a lot of the infrastructure (apache, tcp/ip stacks etc) is written in C. How (specifically) does perl hold the internet together any more than any other scripting language? Or is this jusr something perl aficionados tell each other ?
  - huherto 17y ago
    Good question. I don't have a good answer, but my guess is that it refers to the cgi scripts that use to prevail before and also to all the scripts that every sys admins have written to make their job easier. At one point Perl was called "The duct tape of the internet", I guess referring to all the small scripts tying things together.
  - DrSprout 17y ago
    I think you just answered your own question. I'd say just about every Unix box on the planet has Perl holding it together somewhere in there. What you've asked is essentially like asking "How does mortar hold buildings together any more than bricks, steel I-beams, or roofing?" These things are equally important, and yes you could probably find a substitute, but why?
    - plinkplonk 17y ago
      "What you've asked is essentially like asking "How does mortar hold buildings together any more than bricks, steel I-beams, or roofing?" Argument by metaphor is a lazy device. I don't see any specific "mortar like" virtues that perl has but other common scripting languages don't. In this metaphor I guess C Code would be the "bricks and steel beams". Why can't I put a unix box together without perl on it? Is there any specific piece of perl code that has to be on a unix box to enable it to work as an internet server or router? Is there a piece of code that has to be present on a Unix box for me to deploy say Apache or for dns to work? Honest question. Looking for concrete answers. What specifically does perl do to "hold the internet together" today? As an aside, I remember some COBOL programmers saying COBOL (running on mainframes) underlies all business on the internet and so COBOL was the real "internet commerce " language. Sure, you can say it and it can be justified by a lot of convolutions and narrowing of vision, but the truth seems to be that if it ever was so critical it is (a) an accident of history and (b) getting less true with every passing day. I suspect (but am willing to be corrected) that perl is not indispensable to the internet any more (if it ever was).
      - mfr 17y ago
        To answer your specific question, it isn't necessary. It's just another Turing-Complete language, right? Perl was one of the first popular scripting languages out there to have well-integrated regex handling and was useful for programming purposes. Most old-school systems and network people not only know how to code their way out of a paper bag, but typically grew up with C and Perl as their two go-to languages. C when you needed speed above all else, and Perl when you needed the regex functionality. While specific functions vary for any given environment, I can safely say that I've written all of these in Perl at one point or another: - Crunching netflow data to make life easier for those who do capacity planning. - Running glue scripts against a device database to generate the configs that go to open-source monitoring systems. - Lexing SNMP data in order to generate a device-independent network configuration, and then turning around and "compiling" it to another target network device. All of these could be re-written in python. I've done it. Yet, they're all written in Perl because that's what the people who "Run The Internet" historically have used. In another generation, maybe Python will be the regex-heavy scripting language of choice. For right now though, I suppose the best answer is that that Perl holds the Internet together for historical reasons, because that's what got the job done.
nailer 17y ago
No technology ever goes away. Nobody is saying Perl won't be developed, just that people are less likely to use other languages for new projects in favor of newer technologies.
- DrSprout 17y ago
  The article still makes an excellent point, which is that the difference between most of the 'newer technologies' and Perl is basically marketing, not any actual superiority of language design. You can write line noise in Perl, but you can also write Python in Perl. It may not be quite as pretty as Python, but as far as use in a production environment it will be equally useful.
  - jergosh 17y ago
    Why not just write Python in Python instead ;)?
    - gamache 17y ago
      Or write Perl in Perl. Some languages allow code not only "as pretty as Python", but even prettier.
      - jergosh 17y ago
        Some do ;)
    - DrSprout 17y ago
      I like my braces ;}. Also, Perl 5 is feature-stable, and probably always will be. Python is in this 2.x-3.x limbo right now where it's difficult to find libraries that are going to work as-is for much longer. If you write a Perl application well, maintenance will as easy as reasonably possible, which I think is the only real measure of a good language. Most of the 'ease of use' problems disappear once you know what you're doing, and the language learning curve is a relatively small part of a programmer's life-cycle.
silentium 17y ago
...because it is my duct tape
- pstevensza 17y ago
  +1 ...and it is my glue. So many things in my environment wouldn't happen to be able to talk to each other if it weren't for Perl.
T_S_ 17y ago
Did you perhaps mean perl 5.8?
- btilly 17y ago
  No. It said Perl 5.12 because Perl 5.12 was released April 12 this year. However that said, Perl cuts releases of old branches from time to time. So 5.8.9 was released a year after 5.10. See http://search.cpan.org/~jesse/perl-5.12.0/pod/perlhist.pod http://search.cpan.org/~jesse/perl-5.12.0/pod/perlhist.pod for a full release history.
  - T_S_ 17y ago
    Thanks for the update. I stopped using perl around the same time 5.8 was slated to be the last version of perl 5, since perl 6 was coming Real Soon Now. I learned perl in 1996 in order to cobble together a system that collected reports from all sorts of weird text files and formats (anyone remember Framemaker?) and merge them into one nice big postscript file with custom watermarks and page numbers. This program ran for at least 8 years after that. I had to learn perl in the dead of night because I had been instructed to find a "technology solution" and perl was "unsupportable". Another totally different program was developed to prototype a large orchestration of securities valuation and hedging. It even had numerical optimization in it. It was taken wholesale into production. Many other programs, some fairly long, were written in order to run successfully only once, and then they were retired. I loved perl. Then I learned python and could read the code that I wrote a few months ago and more importantly, read other peoples' code more easily. Consistent white space helps a lot. It had many of the same advantages of perl, with slightly clunkier regexes, plus a nice system for introspection. It could almost replace matlab--almost. I built a complicated optimization system that orchestrated multiple processors and called C++ library code so I didn't have to learn C++. I forgot about perl. I loved python now. Then I learned haskell and forgot about python but that's enough for today.
    - sigzero 17y ago
      Did somebody really say "Perl 6 is coming real soon now?" I have only ever seen "by christmas" and they don't mention what year.
davidw 17y ago
Hah, what's funny is that Jeff Hobbs, the author of the article, is one of the main Tcl developers.
- jgrahamc 17y ago
  Except, that Jeff (who used to work for me at Scriptics) is a pragmatic kind of guy and is likely to not allow his allegiance to Tcl prevent him from seeing what else is going on out there.
  - davidw 17y ago
    I meant it in a "huh, that's funny" way, not that he's not perfectly capable of expressing intelligent opinions about Perl, Python or whatever else.
jergosh 17y ago
The whole article fails to mention any advantage of Perl over the languages it's compared to (wonder why). The sooner Perl falls into obscurity, the better.
- flogic 17y ago
  That's because Perl Python and Ruby offer essentially the same feature set. The only significant differences are syntax and CPAN.
  - berntb 17y ago
    Well, Perl arguably has a nicer OO system with Moose... :-)
- DrSprout 17y ago
  I currently code for my day job in a proprietary extension to a proprietary dialect of BASIC from the mid-80's. This language is legitimately broken, and has significant disadvantages at every turn. It has no real functions, no block-level scoping, lists are stored as delimited strings, there are no hashes, and nothing even resembling objects. Perl has all of these things. If you're coding in Perl and you write bad code, it's your fault. If Perl has a fault, it's that it's easy to write code that you think is done, when you have more work to do if you want to develop a full-scale application. However, you can write incomplete but good-enough code in any language. (And I will always use Perl to write once-off scripts. It's perfect for that task.)
  - jergosh 17y ago
    It's all fine until you have to work with bad legacy code ;) My last project at work was rewriting a 4k line monstrosity in Perl into 500 lines of Python which do exactly the same. I can't even blame the original authors (it was likely their first larger program), it's just that Perl makes it so easy to write horrible code.
    - patrickas 17y ago
jbellis 17y ago
Bet you didn't know there was a [relatively] new COBOL-2002, either. (If I were snarky, I would note that the next COBOL spec after that -- yes, there is one -- might well be released before perl 6.)
geoffc 17y ago
CPAN is the killer app for Perl. Every time I flip across to another language I usually love the syntax and structures but the lack of a CPAN equivalent is always grating and I usually end up right back at Perl to get stuff done fast.
- garyrichardson 17y ago
  I used to think this way. After living without CPAN for 3 years using different languages, I appreciate the lack of dependency additions my projects get. The problem with CPAN is the same things as RPM hell or DLL hell, only worse and more fragile. On a large project, you really don't want to randomly upgrade your DBI module, or some other small perl package that may bring your whole project down. But then one day you need to use Net::SSH and it wants to upgrade DBI::Search for some bizarre reason, which requires you to compile a beta version of the GZIP library because it's using some new interface that's not included with your CentOS 5 install. Then you find out DBI::Search requires DBI 1.41 and you're only using 1.40. There's a backwards incompatible behavior that affects your code in 1.41, which is why you haven't upgraded yet. You go through all 100k lines of your project and make sure all the DBI code handles this new case. Then you have to try and install the changes on all 75 of your servers. You may have some sort of capistrano script to make this simpler, or you may have used RPM versions of your CPAN packages. Neither solution is less painful than the other. CPAN wasn't really designed to work with your sysadmin's workflow, so neither solution is particularly useful. At the end of the day, you would have spent less time just writing the damn code yourself to call out to the ssh binary.
  - geoffc 17y ago
    Agreed with the pain of admin with CPAN. I ended up creating a custom build and distribution tool to manage this as the existing solutions are weak.
  - staunch 17y ago
    I blame your sysadmin for not making it easy. Even so, you probably don't rely on CPAN all that much if you lose more time to dependency problems than you save by re-using other people's code. That's not my experience at all. I save days and sometimes weeks at a time. If you're running through 100K lines of code to test a DBI upgrade you're clearly not testing properly. Not that most CPAN modules break compatibility. It's very rare that something like a DBI upgrade will break anything. All the good module authors are very careful.
gamache 17y ago
Article's conclusion: After a short lapse, Perl development is picking up and enthusiasm for Perl 5 is as strong as ever. I would agree. A little over a decade ago, Perl suffered from the same problems which plagued JavaScript in its early days: ease of writing shitty code, mountains of shitty sample code, and a community which did not vehemently encourage the writing of unshitty code. This caused a backlash which lasted several years, during which the programming public panned the languages almost universally. But a funny thing happened; rather than shriveling up and going away, the languages and their practitioners matured. Community focus became less centered on glue code and scrolling effects, and attention was shifted to writing clean, maintainable code which uses the language's best features (metaprogramming, easy hash/object manipulation, etc) in manageable, modular ways. Now both ecosystems are flourishing, and though Perl doesn't have quite the install base of JavaScript, it's still a viable contender to Ruby and Python in their areas of expertise, and it can be called the best tool for some of those jobs.
- plinkplonk 17y ago
  "Perl development is picking up and enthusiasm for Perl 5 is as strong as ever." I will take your word for it, but I do have to say (speaking as someone with a lot of grey in his hair) that I haven't seen a young developer choose to work primarily in perl (over ruby or Python or Java or C#) in ages. Most new projects/startups don't seem to choose perl as their primary language. I readily concede that this is probably an artifact of my limited experience with perl. Just noting what I see, not looking for a flame war. How many of YC companies use perl do you think?
  - gamache 17y ago
    You have a good point that Perl doesn't have great adoption with young'uns. I think we'd see more Perl usage if Ruby didn't exist; Ruby borrowed some of Perl's most attractive features and is rightly popular for it. By the numbers, though, I still agree with the quoted statement. Perl development is picking up compared to the past few years, and enthusiasm for Perl 5 is the strongest it's been (at least since 5.0).
huherto 17y ago
Does any body remember when Larry Wall and others were rewriting all the Unix commands in Perl? I thought that was cool but I never heard of it again, and haven't been able to find references to it.
- avar 17y ago
  You're probably talking about the long dead one-man project to rewrite all the /bin/* utilities in Perl. That had nothing to do with Larry Wall.
- kree10 17y ago
  It was Tom Christiansen, originally. Looks like no updates since 2004: http://search.cpan.org/dist/ppt/ http://search.cpan.org/dist/ppt/

34 points by fogus 17y ago

eli 17y ago

...because it's holding the entire internet together?

plinkplonk 17y ago
"because it's holding the entire internet together?" Could someone explain what this means in some detail? I hear this all the time but I could never make any sense out of it. Sure once upon a time perl was the best way to get cgi scripts running and do some web programming. Other than this piece of history, any specific examples of the "holding the internet together" property perl is supposed to have? What part of critical internet infrastructure depends on perl? I am no networking expert but it seems to me that a lot of the infrastructure (apache, tcp/ip stacks etc) is written in C. How (specifically) does perl hold the internet together any more than any other scripting language? Or is this jusr something perl aficionados tell each other ?
- huherto 17y ago
  Good question. I don't have a good answer, but my guess is that it refers to the cgi scripts that use to prevail before and also to all the scripts that every sys admins have written to make their job easier. At one point Perl was called "The duct tape of the internet", I guess referring to all the small scripts tying things together.
- DrSprout 17y ago
  I think you just answered your own question. I'd say just about every Unix box on the planet has Perl holding it together somewhere in there. What you've asked is essentially like asking "How does mortar hold buildings together any more than bricks, steel I-beams, or roofing?" These things are equally important, and yes you could probably find a substitute, but why?
  - plinkplonk 17y ago
    "What you've asked is essentially like asking "How does mortar hold buildings together any more than bricks, steel I-beams, or roofing?" Argument by metaphor is a lazy device. I don't see any specific "mortar like" virtues that perl has but other common scripting languages don't. In this metaphor I guess C Code would be the "bricks and steel beams". Why can't I put a unix box together without perl on it? Is there any specific piece of perl code that has to be on a unix box to enable it to work as an internet server or router? Is there a piece of code that has to be present on a Unix box for me to deploy say Apache or for dns to work? Honest question. Looking for concrete answers. What specifically does perl do to "hold the internet together" today? As an aside, I remember some COBOL programmers saying COBOL (running on mainframes) underlies all business on the internet and so COBOL was the real "internet commerce " language. Sure, you can say it and it can be justified by a lot of convolutions and narrowing of vision, but the truth seems to be that if it ever was so critical it is (a) an accident of history and (b) getting less true with every passing day. I suspect (but am willing to be corrected) that perl is not indispensable to the internet any more (if it ever was).
    - mfr 17y ago
      To answer your specific question, it isn't necessary. It's just another Turing-Complete language, right? Perl was one of the first popular scripting languages out there to have well-integrated regex handling and was useful for programming purposes. Most old-school systems and network people not only know how to code their way out of a paper bag, but typically grew up with C and Perl as their two go-to languages. C when you needed speed above all else, and Perl when you needed the regex functionality. While specific functions vary for any given environment, I can safely say that I've written all of these in Perl at one point or another: - Crunching netflow data to make life easier for those who do capacity planning. - Running glue scripts against a device database to generate the configs that go to open-source monitoring systems. - Lexing SNMP data in order to generate a device-independent network configuration, and then turning around and "compiling" it to another target network device. All of these could be re-written in python. I've done it. Yet, they're all written in Perl because that's what the people who "Run The Internet" historically have used. In another generation, maybe Python will be the regex-heavy scripting language of choice. For right now though, I suppose the best answer is that that Perl holds the Internet together for historical reasons, because that's what got the job done.

nailer 17y ago

No technology ever goes away. Nobody is saying Perl won't be developed, just that people are less likely to use other languages for new projects in favor of newer technologies.

DrSprout 17y ago
The article still makes an excellent point, which is that the difference between most of the 'newer technologies' and Perl is basically marketing, not any actual superiority of language design. You can write line noise in Perl, but you can also write Python in Perl. It may not be quite as pretty as Python, but as far as use in a production environment it will be equally useful.
- jergosh 17y ago
  Why not just write Python in Python instead ;)?
  - gamache 17y ago
    Or write Perl in Perl. Some languages allow code not only "as pretty as Python", but even prettier.
    - jergosh 17y ago
      Some do ;)
  - DrSprout 17y ago
    I like my braces ;}. Also, Perl 5 is feature-stable, and probably always will be. Python is in this 2.x-3.x limbo right now where it's difficult to find libraries that are going to work as-is for much longer. If you write a Perl application well, maintenance will as easy as reasonably possible, which I think is the only real measure of a good language. Most of the 'ease of use' problems disappear once you know what you're doing, and the language learning curve is a relatively small part of a programmer's life-cycle.

silentium 17y ago

...because it is my duct tape

pstevensza 17y ago
+1 ...and it is my glue. So many things in my environment wouldn't happen to be able to talk to each other if it weren't for Perl.

T_S_ 17y ago

Did you perhaps mean perl 5.8?

btilly 17y ago
No. It said Perl 5.12 because Perl 5.12 was released April 12 this year. However that said, Perl cuts releases of old branches from time to time. So 5.8.9 was released a year after 5.10. See http://search.cpan.org/~jesse/perl-5.12.0/pod/perlhist.pod http://search.cpan.org/~jesse/perl-5.12.0/pod/perlhist.pod for a full release history.
- T_S_ 17y ago
  Thanks for the update. I stopped using perl around the same time 5.8 was slated to be the last version of perl 5, since perl 6 was coming Real Soon Now. I learned perl in 1996 in order to cobble together a system that collected reports from all sorts of weird text files and formats (anyone remember Framemaker?) and merge them into one nice big postscript file with custom watermarks and page numbers. This program ran for at least 8 years after that. I had to learn perl in the dead of night because I had been instructed to find a "technology solution" and perl was "unsupportable". Another totally different program was developed to prototype a large orchestration of securities valuation and hedging. It even had numerical optimization in it. It was taken wholesale into production. Many other programs, some fairly long, were written in order to run successfully only once, and then they were retired. I loved perl. Then I learned python and could read the code that I wrote a few months ago and more importantly, read other peoples' code more easily. Consistent white space helps a lot. It had many of the same advantages of perl, with slightly clunkier regexes, plus a nice system for introspection. It could almost replace matlab--almost. I built a complicated optimization system that orchestrated multiple processors and called C++ library code so I didn't have to learn C++. I forgot about perl. I loved python now. Then I learned haskell and forgot about python but that's enough for today.
  - sigzero 17y ago
    Did somebody really say "Perl 6 is coming real soon now?" I have only ever seen "by christmas" and they don't mention what year.

davidw 17y ago

Hah, what's funny is that Jeff Hobbs, the author of the article, is one of the main Tcl developers.

jgrahamc 17y ago
Except, that Jeff (who used to work for me at Scriptics) is a pragmatic kind of guy and is likely to not allow his allegiance to Tcl prevent him from seeing what else is going on out there.
- davidw 17y ago
  I meant it in a "huh, that's funny" way, not that he's not perfectly capable of expressing intelligent opinions about Perl, Python or whatever else.

jergosh 17y ago

The whole article fails to mention any advantage of Perl over the languages it's compared to (wonder why). The sooner Perl falls into obscurity, the better.

flogic 17y ago
That's because Perl Python and Ruby offer essentially the same feature set. The only significant differences are syntax and CPAN.
- berntb 17y ago
  Well, Perl arguably has a nicer OO system with Moose... :-)
DrSprout 17y ago
I currently code for my day job in a proprietary extension to a proprietary dialect of BASIC from the mid-80's. This language is legitimately broken, and has significant disadvantages at every turn. It has no real functions, no block-level scoping, lists are stored as delimited strings, there are no hashes, and nothing even resembling objects. Perl has all of these things. If you're coding in Perl and you write bad code, it's your fault. If Perl has a fault, it's that it's easy to write code that you think is done, when you have more work to do if you want to develop a full-scale application. However, you can write incomplete but good-enough code in any language. (And I will always use Perl to write once-off scripts. It's perfect for that task.)
- jergosh 17y ago
  It's all fine until you have to work with bad legacy code ;) My last project at work was rewriting a 4k line monstrosity in Perl into 500 lines of Python which do exactly the same. I can't even blame the original authors (it was likely their first larger program), it's just that Perl makes it so easy to write horrible code.
  - patrickas 17y ago

jbellis 17y ago

Bet you didn't know there was a [relatively] new COBOL-2002, either. (If I were snarky, I would note that the next COBOL spec after that -- yes, there is one -- might well be released before perl 6.)

geoffc 17y ago

CPAN is the killer app for Perl. Every time I flip across to another language I usually love the syntax and structures but the lack of a CPAN equivalent is always grating and I usually end up right back at Perl to get stuff done fast.

garyrichardson 17y ago
I used to think this way. After living without CPAN for 3 years using different languages, I appreciate the lack of dependency additions my projects get. The problem with CPAN is the same things as RPM hell or DLL hell, only worse and more fragile. On a large project, you really don't want to randomly upgrade your DBI module, or some other small perl package that may bring your whole project down. But then one day you need to use Net::SSH and it wants to upgrade DBI::Search for some bizarre reason, which requires you to compile a beta version of the GZIP library because it's using some new interface that's not included with your CentOS 5 install. Then you find out DBI::Search requires DBI 1.41 and you're only using 1.40. There's a backwards incompatible behavior that affects your code in 1.41, which is why you haven't upgraded yet. You go through all 100k lines of your project and make sure all the DBI code handles this new case. Then you have to try and install the changes on all 75 of your servers. You may have some sort of capistrano script to make this simpler, or you may have used RPM versions of your CPAN packages. Neither solution is less painful than the other. CPAN wasn't really designed to work with your sysadmin's workflow, so neither solution is particularly useful. At the end of the day, you would have spent less time just writing the damn code yourself to call out to the ssh binary.
- geoffc 17y ago
  Agreed with the pain of admin with CPAN. I ended up creating a custom build and distribution tool to manage this as the existing solutions are weak.
- staunch 17y ago
  I blame your sysadmin for not making it easy. Even so, you probably don't rely on CPAN all that much if you lose more time to dependency problems than you save by re-using other people's code. That's not my experience at all. I save days and sometimes weeks at a time. If you're running through 100K lines of code to test a DBI upgrade you're clearly not testing properly. Not that most CPAN modules break compatibility. It's very rare that something like a DBI upgrade will break anything. All the good module authors are very careful.

gamache 17y ago

Article's conclusion: After a short lapse, Perl development is picking up and enthusiasm for Perl 5 is as strong as ever. I would agree. A little over a decade ago, Perl suffered from the same problems which plagued JavaScript in its early days: ease of writing shitty code, mountains of shitty sample code, and a community which did not vehemently encourage the writing of unshitty code. This caused a backlash which lasted several years, during which the programming public panned the languages almost universally. But a funny thing happened; rather than shriveling up and going away, the languages and their practitioners matured. Community focus became less centered on glue code and scrolling effects, and attention was shifted to writing clean, maintainable code which uses the language's best features (metaprogramming, easy hash/object manipulation, etc) in manageable, modular ways. Now both ecosystems are flourishing, and though Perl doesn't have quite the install base of JavaScript, it's still a viable contender to Ruby and Python in their areas of expertise, and it can be called the best tool for some of those jobs.

plinkplonk 17y ago
"Perl development is picking up and enthusiasm for Perl 5 is as strong as ever." I will take your word for it, but I do have to say (speaking as someone with a lot of grey in his hair) that I haven't seen a young developer choose to work primarily in perl (over ruby or Python or Java or C#) in ages. Most new projects/startups don't seem to choose perl as their primary language. I readily concede that this is probably an artifact of my limited experience with perl. Just noting what I see, not looking for a flame war. How many of YC companies use perl do you think?
- gamache 17y ago
  You have a good point that Perl doesn't have great adoption with young'uns. I think we'd see more Perl usage if Ruby didn't exist; Ruby borrowed some of Perl's most attractive features and is rightly popular for it. By the numbers, though, I still agree with the quoted statement. Perl development is picking up compared to the past few years, and enthusiasm for Perl 5 is the strongest it's been (at least since 5.0).

huherto 17y ago

Does any body remember when Larry Wall and others were rewriting all the Unix commands in Perl? I thought that was cool but I never heard of it again, and haven't been able to find references to it.

avar 17y ago
You're probably talking about the long dead one-man project to rewrite all the /bin/* utilities in Perl. That had nothing to do with Larry Wall.
kree10 17y ago
It was Tom Christiansen, originally. Looks like no updates since 2004: http://search.cpan.org/dist/ppt/ http://search.cpan.org/dist/ppt/