
Why Perl isn't Going Away Soon (Or Ever) - fogus
http://ostatic.com/blog/guest-post-why-perl-isnt-going-away-soon-or-ever
======
gamache
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
"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?

~~~
sreque
Older people use it is because they don't want to change or learn something
new. Especially in a company already entrenched in Perl development, their is
little benefit to switching to a better language compared to the cost of
forcing people to learn a whole new technology stack when they are more than
content with Perl. However, new companies are much more free to build on
whatever technology stack is most appropriate.

I've also noticed over time that lots of non-CS majors can and do program in
scripting languages because they are relatively easy to pick up and get things
done with. These people are usually more aligned with an IT career in that
scripting constitutes only a fraction of their job. If they happen to learn
Perl and PHP first, then that is what they stick with.

These people may like to program, but it is not the favorite part of their job
and they have other work activities they enjoy more. More importantly, they
know little to nothing about software design principles and are not interested
in improving their software development skills. They would rather spend their
time learning about something else that interests them more. Therefore, they
don't even know how to appreciate the advantages more modern scripting
languages offer. To these people, languages like Perl are more than sufficient
to get their job done, and they are probably right.

However, as people who know better, I believe we should be encouraging better
languages in a friendly way whenever possible. When my IT friends ask me about
any questions related to programming, I usually try to point them to Python or
Ruby for a solution. If they are asking questions they are probably interested
in learning something new!

edit: changed wording based on reply from gamache.

~~~
gamache
I disagree with your implication that Perl is suitable for newbs but should be
discarded for "better languages" by people who are interested in learning.

In fact I would invert your statement: I think Perl is not a good choice for
people without good programming habits, but for those who know how to use it,
it offers more power of expression than most of its peers.

(Also, datum: count me in as an "older person" preferring Perl for most tasks
despite knowing Ruby, Python, JS and half a dozen other languages.)

~~~
sreque
I never meant to imply that Perl is suitable for newbs, but rather most
scripting languages are. I would much rather newbs learn another language, in
fact. I changed my wording in my original post to reflect that.

Also, for my background, I learned Perl as my first scripting language and
after writing a ~1k line code project in it, decided that for anything over
200 lines I would rather use Java. Later when I learned Python I was
vindicated in that almost everything I instinctively disliked about Perl was
absent in Python. Since then I have learned many other languages as well, and
I also know Perl the language better than most of my co-workers

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

------
nailer
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
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
Why not just write Python in Python instead ;)?

~~~
DrSprout
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.

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

~~~
gamache
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.

~~~
sigzero
I agree totally. Perl6 is to Perl5 what VB.NET was to VB6. They aren't the
same.

~~~
nailer
So all the Perl programmers are going to find other jobs like the VB guys did?

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

~~~
staunch
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.

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

~~~
jgrahamc
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
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.

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

~~~
plinkplonk
"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 ?

~~~
DrSprout
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
"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).

~~~
avar
The phrase "Perl holds the internet together" was coined by analogy with
Perl's widespread use as a glue language. You've interpreted it too literally.
It doesn't mean that you can't set up a router or another piece of Internet
infrastructure without using Perl.

It means that Perl is used in a lot of unexpected places, and that a lot of
critical things are "held together" by Perl. Even if you think your website is
running on Java, some systems administrator probably has a cronjob written in
Perl critical to its operation.

~~~
plinkplonk
"It means that Perl is used in a lot of unexpected places, and that a lot of
critical things are "held together" by Perl. Even if you think your website is
running on Java, some systems administrator probably has a cronjob written in
Perl critical to its operation."

In the above sentence replace Perl with C/C++/awk/lua/Python/Ruby/almost-any-
language and it makes as much sense. Which is probably another indicator that
there is nothing particularly perl specific about "holding together the
internet". If anything "holds together the internet" it is the (language
independent) protocols that do it.

~~~
avar
This whole thread is a joke that's gone over your head. "Perl is the glue that
binds the web together" (or variants thereof) is an old pun on how Perl often
gets used. Not so much to write large systems (as is the case with C/C++/..)
but as a glue layer to stitch them together.

------
silentium
...because it is my duct tape

~~~
pstevensza
+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.

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

~~~
kree10
It was Tom Christiansen, originally. Looks like no updates since 2004:
<http://search.cpan.org/dist/ppt/>

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

~~~
DrSprout
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
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
Why can't you blame the original author since you know it was likely his first
larger program?

I know that Perl's defaults (mainly lack of strict and warnings) can make it
easy to write code that _easily breaks_ or _has bugs_ or is _harder to
maintain_ , but it is the first time I hear the argument that it make it any
easier or encourage someone to write 4k lines when he could have written 500
lines.

I would guess that guy would have created a 4k monstrosity in Python if that's
what he had to use without having enough experience.

Or maybe I am not being imaginative enough? Can you give examples from the
program you rewrote where Perl encourage beginners to write "huge
monstrosities" while Python would have encouraged them to write succinct code
?

------
T_S_
Did you perhaps mean perl 5.8?

~~~
btilly
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.

~~~
T_S_
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
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.

~~~
btilly
According to <http://use.perl.org/~pmichaud/journal/39411> (written last
summer) this Spring (likely April) is targeted for a production release of a
usable subset of Perl 6. The same information is posted to
<http://www.perlfoundation.org/perl6/index.cgi?Rakudo_Star>.

They obviously didn't make that. I don't know what the current state is or
what the exact thinking is now.

~~~
berntb
<http://www.perlfoundation.org/perl6/index.cgi?rakudo_star>

[..] original release plan was for late April 2010 [family crisis for lead
developer]. The release date [..] sometime in the second quarter of 2010.

