Live data from Hacker News

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

ostatic.com

31–40 of 88 posts

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

#31
post #2

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

"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 c…

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.

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

#33
post #8
post #5

Did you perhaps mean perl 5.8?

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 for a full release history.

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.

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

#34
post #26

Earlier quoted context omitted.

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 y…

That's a rather twisted reasoning, with Perl 6 on the doorstep ;)

Perl 6 is not meant to interoperate directly with Perl 5. It's not an incremental update in any way. IMO, it would be a lot clearer if Perl 6 weren't called Perl.

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

#35
post #29

Earlier quoted context omitted.

"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…

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).

Perhaps it's not as popular because it doesn't have One True Web Framework, which is what the young'uns use these days, right? I know Catalyst and Mason are both very nice frameworks, but they don't come rolled with a base Perl installation.

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

#36
post #32

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.

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.

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

#37
post #12

Earlier quoted context omitted.

Why not just write Python in Python instead ;)?

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 y…

Since 2.x is just as feature stable and was just released in the last incarnation (2.7) before an "extended maintenance period", I do believe the limbo you speak of isn't an issue for anyone actually using Python.

I can imagine it looking worrisome from the outside, though.

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

#38
post #35
post #29

Earlier quoted context omitted.

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).

Perhaps it's not as popular because it doesn't have One True Web Framework, which is what the young'uns use these days, right? I know Catalyst and Mason are both very nice frameworks, but they don't come rolled with a base Perl installation.

Rails is the main driver behind Ruby's success, true. And it really is a nice framework. However, Rails doesn't come rolled with a standard Ruby installation either, and 'gem install rails' is no easier or harder than 'cpan -i Catalyst::Devel'.

Interestingly, I notice many of the new Rails 3.0 features -- most notably composable set algebra and increased modularity -- are features which drew me to Catalyst+DBIx::Class. I haven't worked with Rails 3 in detail yet, but I have some Rails work coming up in the next few months and I am excited to compare and contrast.

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

#39

Earlier quoted context omitted.

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?

"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…

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.

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

#40
post #22

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.

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 yo…

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.

Post reply on HN