
The Fall Of Perl, The Web's Most Promising Language - MattRogish
http://www.fastcolabs.com/3026446/the-fall-of-perl-the-webs-most-promising-language
======
smacktoward
_> I first heard of Perl when I was in middle school in the early 2000s._

Welp, now I officially feel old. Thanks!

In seriousness, though, this is not a very informative article. It essentially
boils down to "I learned a little Perl after college, but didn't like the
syntax. Then I went to grad school and found that everyone there was using
Python, so I switched to that instead. Also, where's Perl 6 amirite lol."

Which is fine, as far as it goes, but it tells you more about the author's
career path than it does about either language. And by doing so, it leaves out
important elements of the story. Writing an article about "the fall of Perl"
that only incidentally mentions PHP, for instance, is a _big_ omission.
Insofar as Perl has fallen, what it fell from is the position of leading
language for building Web applications. PHP is what pushed it out of that
position, not Python or Ruby. If you want to write an article about the fall
of Perl you have to explain how that happened and why, but this article
attempts neither.

I think the root of the problem is that the author is incorrectly generalizing
from his own experiences. He mentions working in scientific computing these
days; if you work in that field, and entered the workforce within the last
decade, I can totally understand how it might look like The Story Of
Programming Languages goes "once there was Perl, now there is Python, The
End." But step outside that niche or that time window, and things look very
different.

~~~
joe_the_user
I disagree. A long list of the things that replaced Perl in various
applications obscures things rather than revealing the basic trend.

The overall trend is Perl died everywhere.

I personally think Perl's death was proper.

During Perl's upswing, it's various absurdities were all touted as virtues.
The weird symbols and the ability to do amazing things with a single line were
both proof that Perl was the language for the people who knew more than us. At
the certain point, the emperor's cloth just faded and people wanted languages
to accomplish things rather than to prove they were smart.

Perl has positives, Perl's weirdnesses have positives. But once it lost it's
cachet, none of the _tradeoffs_ between obscurity and power look good. And
yeah, other powerful interpreted languages arose. But which still doesn't
matter which one won because once the "magic", the reality distortion field,
was gone, every other good interpreted language looked better.

~~~
lazyloop
> The overall trend is Perl died everywhere.

Far from the truth, Perl is everywhere, what died is the hype.

~~~
derefr
If the life of a language can be measured in how many people are learning it
for any reason other than to maintain an existing code base written in it (an
arbitrary definition, but I think a common one), then Perl is roughly dead-as-
a-doornail, in precisely the same sense as, say, COBOL is dead.

(Note that under this definition, FORTRAN _isn 't_ dead—people still write new
code in it, every once in a while, due to its mathematics libraries. Perl is
"more dead than FORTRAN.")

~~~
kbenson
Are you talking about new people learning language, as you state, or people
writing new code in a language, as your example implies?

Without revision to clarify your point, it looks somewhat like you had a
statement you wanted to make (Perl is "more dead than FORTRAN.") and had to
reach for some assertions to support it.

~~~
derefr
The intersection of the two sets: new people learning the language, who are
learning the language _in order to_ write new code in the language.

New people learn COBOL still, but they only do that if-and-when someone with
an existing COBOL codebase has a problem with it, for which they're willing to
hire and train up new programmers in COBOL.

For example, banks who needed their batch-processing code updated for
Y2K-compliance trained a good few people in COBOL. But they weren't learning
COBOL wIth the intent of writing _new_ code in the language—just with the
intent of maintaining _old_ code. Effectively, they were treating the COBOL
codebase as a Ball of Mud
([http://laputan.org/mud/](http://laputan.org/mud/)), where old components
could be patched, but any new component should be written for a _living_
platform, communicating with the Ball of Mud over an API instead of being
sucked into it.

I'm asserting, here, that Perl is such a language—that the only reason new
people learn Perl is to maintain a Ball of Mud written in Perl. From there,
they may go on to become productive Perl programmers—but because they were
only "born" into the Perl community because some company who _had_ Perl-ers
lost them and needed new ones, the language's adoption rate is effectively
"below replacement," like a birth rate below 2.0.

In _living_ languages, at least some people will learn the language on their
own, because they think it will be useful for some task they'd like to
accomplish. Perl is not one of these languages.

Under this definition, other dead languages include sh-derivative shell
scripting (people only _learn_ it because shell scripts that already exist
must be modified), and anything to do with SOAP (it was stillborn; people only
_ever_ learned about it to deal with codebases that used it. Then,
horrifyingly, they ended up creating more of those codebases.)

------
ChuckMcM
When I came out of Google I could see the Python features that endeared it to
Googlers (although I expect Go to replace Python pretty much everywhere there
eventually). Blekko is a perl shop and it certainly felt a bit strange, but
having gotten acclimated I can see the appeal. Every now and then I come
across some really idiomatic perl and find it mind bendingly opaque, but for
the most part I can code up a quick script in it faster than I ever could in
Python.

Of course when you write code in a dozen languages you stop seeing the
language after a while and just see the code. And at that point it really is
all the same.

~~~
pjmlp
> Of course when you write code in a dozen languages you stop seeing the
> language after a while and just see the code. And at that point it really is
> all the same.

Fully agree. You start to look how language X exposes the CS concept Y,
instead of just looking at language X feature list. A kind of meta level, if
you will.

------
erichsu
In my opinion, they buried the key point... the dead end of Perl 6.

Up until last year, I did a lot of web development in Perl. Its strengths were
CPAN & community, ubiquity and top-notch text processing. Its acquired taste
was very elegant expressiveness once you grokked the grammar.

Then all the Perl leadership focussed on the black hole of Perl 6 which was
solving a problem no one had but CS linguists. So Perl users like me felt
there was no future in Perl. Perl 6 would have to be relearned for no tangible
benefit so why not learn something new with a growing rather than
stagnant/declining ecosystem? No one was forced to leave, but like a trap
door, as soon as a Perl programmer learned something new, they were only going
to continue to decrease their use of Perl.

The rise of Python and Ruby (and Ruby on Rails especially) and even PHP, were
grave wounds to the health of Perl, but Perl 6 was the self-cutting that bled
the community beyond the point of self-repair.

~~~
kamaal
I don't think Perl 6 is a dead end. Far from it. From what I know is that its
nearly feature complete. A small set of features remain, but those are only
like what should be added for completeness sake.

Bulk of the effort is in developing MoarVM, which is likely to become a
suitable replacement for Parrot. Documentation, Speed and standard libraries
remain as open issues. Of which last I heard was Larry Wall was writing a
Camel book equivalent for Perl 6. So its mainly speed and standard libraries.

I would give end of next year, by the time its ready for prime time.

~~~
chromatic
_I would give end of next year, by the time its ready for prime time._

I wish this claim wouldn't come up in every Perl article because that's a big
part of Perl's perception problem. P6 is entering its 15th year of advocates
claiming that it'll be ready in "about a year and a half".

If that claim is true this time, then it puts off people doing interesting
things with Perl now as they figure they'll wait for a successor to look at
it.

If that claim isn't true, then it puts off people doing interesting things
with Perl now as the claim will change to be "about a year and a half from
now" in another 18 months.

~~~
kbenson
I agree with this as well, but from the other side. Giving out timeframes
based on volunteer schedules in an industry that is already famously known for
not hitting release times is not really useful. I think it's more useful to
say "Perl 6 is already useful for many tasks, feel free to download one of the
implementations and take a look. If you find it lacking in some area, let us
know and maybe we can fast-track a solution for that." IMO that's not only
more accurate and truthful, it's also much better way to draw in potential
users.

~~~
chromatic
Yes, predicting schedules based on volunteer effort is much more difficult
than predicting schedules based on paid developer effort. Your proposed
wording is a lot friendlier, but it doesn't match my experience with the
project. (However, I've already written far too much on _that_ subject, so I
won't bore everyone again.)

~~~
kbenson
Well, I know it's in use in a few places now (I personally know someone using
it at Google's engineering as a tool to retrieve and collate information,
utilizing the newer async features), but of course there are still many rough
spots. Whether it fits the bill for that person will be highly dependent on
what they need.

I'm of the opinion the only way to solve the chicken and egg usage problem is
to convince a few people to be chickens. That's not going to happen without
them trying it out. (I'm aware you've thought quite a bit on this issue).

------
lelf
This article is full of rubbish. Like this:

    
    
      2000 Python 2.0 released    1994 Perl 5 released
      2008 Python 3.0 released    2000 – present[/b] Perl 6 "in development"
    

It's more like

    
    
      2013 — Perl 5.18 released
    

Perl 6 is entirely different language (with unfortunate name). And honestly,
as a language it's light years ahead of python.

~~~
abraham_s
I liked writing Perl instead of bash but I couldn't shake the "whole thing is
a hack" feeling. That why I found myself using more and more Python.

Is Perl 6 is more consistent(for lack of a better word) language ?

~~~
kamaal
>>Is Perl 6 is more consistent(for lack of a better word) language ?

Not the right way of looking at it.

Perl 6 doesn't continue from Perl 5. Its more like a total redesign. Some even
say, they are so different Perl 6 isn't even Perl(5) anymore- only common
things being sigils, core philosophy and the author.

I can't obviously write a complete synopsis of Perl 6 in a comment. But its
like what Perl 5 would look after 20-30 years in development + Lisp powers in
C syntax.

------
greggman
I'm by no means a perl expert having only written maybe 10k lines of Perl but
...

Perl seemed to me just hack upon hack. You can see the progression. First
there were no local variables. Then "local" was added which effectively pushes
the current value on the some stack and retrieves that value on the way back,
then later "my" was added to actually give local variables.

Similarly all the crazy special variables @_,$_, $a, $b, $&, $', $+, @+, @-
%-, $^R, $., $/, $|, $\, $", $; etc etc etc. I'm sure someone out there really
loves that stuff but to many it's one giant hack, disliked for similar reasons
to PHP's disorganization.

On top of that it died at version 5 because version 6 never came out.

For web stuff, PHP at least provided a huge speed boost (over CGI, the typical
way Perl was used) PHP also supported the whole shared host model much better
than Perl/CGI. I'm not saying I like PHP. PHP's templating roots also made it
more approachable by beginners. I'm only pointing out why for some use cases
PHP killed Perl.

On the other side Python also killed Perl. Python seems like far less of a
hack upon hack design. Python also has a comparable number of libraries, many
builtin making it usually as easy to bang something out as Perl was.

~~~
einhverfr
I have written maybe 100-200k lines in Perl.

> Similarly all the crazy special variables @_,$_, $a, $b, $&, $', $+, @+, @-
> %-, $^R, $., $/, $|, $\, $", $;

Of these the only four most Perl programmers should ever use are @_, $_, $a,
and $b. The rest are great for advanced manipulations (probably along with the
local keyword) but are best thought of as configuration tweaks to the runtime.

> On top of that it died at version 5 because version 6 never came out.

Perl 6 did come out. It just doesn't have that much of a community and has
about the same relationship to C++ does to C. Perl 6 won't kill perl 5. Ever.

Perl is dead in some environments (and good riddance), but it is a very
powerful development environment for others and I doubt it will ever die per
se.

------
guelo
In terms of expressiveness I think Python falls closer to Java than Perl.
People make fun of Perl's sigils but I think Python's magic underscores and
'self' everywhere are much uglier in a verbose way. And no one will ever
convince me that significant-white-space and not having block enders are good
ideas, it makes refactoring and copy-pasting code hazardous. And I don't
understand why every language hasn't added Perl's native regex syntactical
sugar, it's a huge win for many problems.

But yea, Python won.

~~~
thirsteh
To your last point about regexes: I think the general idea is to discourage
their use, at least as a default. It is so easy to use them in Perl that they
are used _way_ too much, e.g. when you could do a regular (and faster) string
search.

~~~
Renaud
But isn't that a crime of premature optimisation? Perl's integration of Regex
makes them easy to use and they fit naturally in the language, a lot more than
in most implementations.

Being able to use Regex easily is a plus in my book. Yes they are lower than
some dedicated string search or some state machine ad-hoc implementation, but
you can document Regexes and they pack a lot of punch.

If a Regex is causing a concern in term of performance, then it may be time to
review that code and optimise it, otherwise why even bother?

When people talk about Regex being bad and they say you can often use string
manipulation instead they only talk about the most trivial uses of Regex.

As soon as you go beyond that, using a Regex is almost always going to be
cleaner than spewing lines of codes and building state machines to achieve the
same functionality.

~~~
maxerickson
It's more a matter of different design taste than it is an optimization.

(I don't think it is controversial that Python has a relatively simple
language definition/grammar/etc; regex as language syntax would expand all of
that quite a bit)

------
einhverfr
Hmmm... This article strikes me as relatively missing a few things.

Perl 5 is a mature language. There is a lot of effort at building Perl 6, but
at this point it doesn't really look like Perl 6 will be a successor to Perl 5
(the metaphor now is "little sister"). It's so different, it is like learning
a new language.

Now, I do a lot of programming in Perl. I have done some scripting in Ruby,
Python, PHP, and more, but I always come back to Perl because the language is
remarkably flexible. (Rebol is probably the second I frequently come back to,
and Red looks promising.)

Predicting the demise of Perl is relatively premature. I don't think we will
ever see Perl 6 supplant Perl 5. Rather these will become different languages
(with a relationship similar to that of C vs C++).

Now you can write crap code in any language, and I just love how Python gives
invisible characters semantic meaning (not), a problem that is likely to get
worse as the number of whitespace characters continues to proliferate (not
just plain spaces and tabs, but non-breaking spaces vs regular spaces....).

What perl has lost is the "let's quickly throw together an app" crowd. That
crowd has gone sometimes to Python, sometimes to Ruby, and sometimes to Lua.
From where I stand, good riddance. This is what gave Perl a bad reputation in
the past.

To plug my own projects, right now I am working on a framework for delegating
Perl object methods to PostgreSQL stored procedures.[1] At some point I may
port the work to PHP and Python, but currently Perl is where this is really
going for me. The thing is that such work is not applicable to the "throw
together an app using an ORM or NoSQL fast" crowd, but it allows for some very
sophisticated, powerful, and robust business tool development.

Additionally I have to plug [http://cpantesters.org](http://cpantesters.org).
This is a really really useful piece of the Perl community. I got a test
failure report today for PGObject::Util::DBMethod failing to load in Perl
5.6.4. My first thought was "who the heck uses Perl 5.6 anymore" and my next
thought was "I guess I had better start adding minimum Perl versions to my
Makefile.PL."

[1] The two most important pieces are [https://github.com/ledgersmb/PGObject-
Simple-Role](https://github.com/ledgersmb/PGObject-Simple-Role) and
[https://github.com/ledgersmb/PGObject-Util-
DBMethod](https://github.com/ledgersmb/PGObject-Util-DBMethod)

~~~
pyre
> a problem that is likely to get worse as the number of whitespace characters
> continues to proliferate (not just plain spaces and tabs, but non-breaking
> spaces vs regular spaces....).

I know that people love to hate on Python's semantic whitespace, but this is
the first time that I've seen someone argue that Python's lifespan is limited
because we are about to enter a period of exponential growth in the number of
whitespace characters.

Where do you feel that this growth in the number of whitespace characters is
going to come from? Do we not already have a plethora of whitespace characters
in the current Unicode standard, in addition to things like the vertical tab
of yesteryear that languishes in the ASCII standard? How come we don't see any
of these issues now, even with the number of whitespace characters that we
already have at our disposal?

> The thing is that such work is not applicable to the "throw together an app
> using an ORM or NoSQL fast" crowd

Are you trying to imply that using an ORM is the sign of someone trying to
"whip something together fast?" What are your feelings on DBIx::Class? Should
those people who use it jump ship to some other language so that you can bid
then "good riddance?"

~~~
einhverfr
> I know that people love to hate on Python's semantic whitespace, but this is
> the first time that I've seen someone argue that Python's lifespan is
> limited because we are about to enter a period of exponential growth in the
> number of whitespace characters.

I think the various Unicode whitespace characters are likely to gain more use
generally. The big problem though is that whitespace characters all look alike
and so you can't read and parse the way a computer does.

> Are you trying to imply that using an ORM is the sign of someone trying to
> "whip something together fast?" What are your feelings on DBIx::Class?
> Should those people who use it jump ship to some other language so that you
> can bid then "good riddance?"

Not really. ORMs can be used in significant applications and in fact a lot of
people use DBIx::Class that way in Catalyst etc. I am referring specifically
to the quick and dirty app crowd. You have PHP, Python, Javascript (via
Node.js) and Ruby largely taking that role over. And that's fine. Perl is a
wonderful language, but to write good quality, maintainable, robust code in it
takes some work. But that work is well rewarded.

~~~
fearface
> I think the various Unicode whitespace characters are likely to gain more
> use generally. The big problem though is that whitespace characters all look
> alike and so you can't read and parse the way a computer does.

I think the big problem is, that there are people out there, that think Python
programmers have a huge urge to use non-standard whitespace characters in
their source code.

> Perl is a wonderful language, but to write good quality, maintainable,
> robust code in it takes some work. But that work is well rewarded.

The reward for that kind of code is the same in all languages, but your
statement implies, it's maybe better to choose a language, where it's not as
hard as with Perl to write good quality, maintainable, robust code. Point
taken.

~~~
einhverfr
Writing good code in any language is remarkably time-intensive to learn. There
are any number of ways to mess up code and the coding patterns and
antipatterns are different in any language.

It takes struggling with the ways of doing things in the language and seeing
what works and what does not. Perl is no exception, except that there is no
One True Perl way. Every Perl programmer finds his or her won way.

------
kamaal
I'm not sure why every Python lover has to be Perl troll. No seriously. The
author is clearly a Python fan boy, and he can very well write a good
technical article to illustrate Python's goodness. I'm sure we all can
appreciate that. But you don't have to troll Perl endlessly to do that.
Besides all that, I've been hearing this Perl is dead thing since what, 10
years? If that was really the case Perl should not only have died, but should
have even been forgotten from our very memories.

Something tells me most Python lovers take Perl as a very serious competitor.
Else they wouldn't be writing articles like these.

Python's big rise came after hipster crowds got web frameworks written in
Python. If you use hibernate or spring in Java, you can only come to love
Python's web frameworks. But that time is long gone now. The crowd went to
newer languages like Scala and Go. For all practical popularity purposes. Perl
and Python are the very same these days.

If you are really worried about popularity. Lets talk of Python's falling
popularity compared to languages like Go and Scala.

>>By the late 2000s Python was not only the dominant alternative to Perl for
many text parsing tasks typically associated with Perl

When it comes to serious text parsing work, Perl is still the only practical
alternative you have. Ever checked upon Perl's Unicode capabilities?

>>2000 – present[/b] Perl 6 "in development"

The development of Perl 6 didn't start in 2000. And Perl 6 and Python aren't
even in the same league for comparison.

However the author completely misses the point. I can sit on top of a high
priority production issue, just have a big log file. If all I have is that-
Perl has the tools to help me get my job done in a couple of hours. Call me
back, when Python can help me do that.

>>Perl 6 has been an ongoing development since 2000. Yet after 14 years it is
not officially done, making it the equivalent of Chinese Democracy for Guns N’
Roses

Comparing Perl 6 and Python's progress is a bit ridiculous. Merely the
ambition and audacity of what Perl 6 is aiming to achieve is what Python would
like to in the next 20-30 years of iterative development.

Perl 6 is not your usual language which aims a different syntactical style for
decision and iterative statements and then calls it progress. A simple tour of
the Perl 6 spec can help you on that.

------
nathancahill
This could have been titled "The Rise Of Python".

Both languages have their uses. I write almost all of my code in Python these
days, but fall back to Perl for complicated bash scripting. Shell scripts in
Python feel clumsy, while Perl is very well suited for that environment.

~~~
crdoconnor
>Shell scripts in Python feel clumsy

Not once you've seen this:
[http://amoffat.github.io/sh/](http://amoffat.github.io/sh/)

~~~
nathancahill
Oh wow, that's pretty sweet. I'll have to play around with that.

------
mempko
Still coding perl. I got something against a programming language telling me
what to think the way Python does. Python is latin, perl is english.

~~~
gilgoomesh
U understand English? Dude, shit is cray.

~~~
ChuckMcM
I believe you meant to say 'shit is wack'

------
meddlepal
Perl missed out on the hype-bubble of the web 2.0 craze which shot Python and
Ruby to the top of the charts in the early/mid 2000's. But it wouldn't
surprise me if Perl was "rediscovered" at some point sort of like how
JavaScript has experienced a renaissance since Node and the much-improved
runtime engines showed up.

Personally, I have done a little work in Perl, but I never really considered
it as tool I would want to build a large app using. I have always argued
however that Perl is an ideal replacement for shell scripts and I have
wondered for awhile what an interpreter shell would feel like if it used Perl
as the language rather than say Bash.

~~~
tudorconstantin
given the relatively small number of new programmers is an actual advantage
for us: increased salaries. i don't know the actual reason why, but we have
students who, after 3-4 weeks of perl training are thrown in production
environment where they fix bugs and implement features on par with our senior
devs. It might be because they are very smart, or because the language is
actually simpler to learn than it looks at first sight. And the production
environment that I'm talking about is a very complex web app from an
architectural point of view: it has mysql, memcached, the authorization of
documents is done through sphinx search engine, we're using dbix class as an
orm and catalyst as a web framework, etc

~~~
jzawodn
Authorization via sphinx? Interesting!

In any case, we use Perl heavily at Craigslist and are helping to sponsor the
continued work on Perl6. I don't think it's nearly as bad as people seem to
think. But time will tell, of course.

~~~
tudorconstantin
Yeah, basically there are 100k+ users in DB and 800k+ documents. Each document
is filed under one or more geographies and one or more industries. Each user
is entitled to access one or more geographies with one or more services. The
SQL queries, besides that they have very complex where clauses, are very slow.

We use sphinx by indexing those documents, and attaching the geographies and
industries as tags to each document. Whenever a user logs in, it takes only a
few hundreds of miliseconds to get the latest documents he needs to see

------
tasty_freeze
A few days ago I was at a Half Price Books store. Something which struck me at
the moment was that while there were probably 20 Perl books (some of them
duplicates), there wasn't a single Python book. I took it as in indication
that Perl is in decline and people are unloading their personal perl library
and nobody is buying the used ones; meanwhile, people are holding on to their
Python books and ones which show up get snapped up.

The alternate interpretation is that Perl needs a LOT of books to explain
things due to its quirky syntax and myriad coding idioms, so there are simply
more Perl books in circulation.

------
raldi
In what possible universe could Perl be considered "straight-jacketed"?

~~~
EdwardDiego
Also, pedant nitpicking: it's straitjacket.

~~~
zimpenfish
"straightjacket" is also acceptable.

------
natch
>dubbed the Swiss army knife of the Internet

"Swiss Army chainsaw" is the correct quote (as can be verified by following
the source link provided in the article).

------
macleodan
It seems the perception of Perl 6 as a long delayed update to Perl 5 is a
serious problem for the languages. Perl 6 is not really the next version of
Perl 5, it is more like another language.

Perl 5 is still under active development. The latest stable release was
version 18.2, made in January. Perl 5 will continue to exist even when more
people start using Perl 6. Also, Perl 6 is available and usable already.

------
lazyloop
Contrary to popular belief Perl is still very much alive and healthy. Sure, it
has baggage, but so does any language that kept evolving for decades. If you
want to know what Perl really looks like these days take a look at the Modern
Perl book
([http://modernperlbooks.com/books/modern_perl/](http://modernperlbooks.com/books/modern_perl/))
and Mojolicious web framework. ([http://mojolicio.us](http://mojolicio.us))

------
pirateking
Perl was the first scripting language I really learned when I was an intern at
Sun. I read the whole Camel Book my first couple weeks there. I had an awesome
sysadmin mentor that was a Perl guru, and when I asked for help he would give
me mysterious one-liners that did powerful things, simply saying "use this". I
had little idea what I was doing at the time, but it was awesome.

I use Ruby now for most scripting, and it is also awesome, but a lot less
mysterious.

------
gregjor
I understand that this is written from an academic point of view and focuses
on scientific computing, but writing "upstart PHP grew in size to the point
where it is now arguably the most common language for web development" is a
serious understatement.

PHP dates back to 1994, and (arguably) became a serious contender with the
release of PHP 3 in 1998. PHP pushed out the then-dominant web programming
languages ASP (a Visual Basic variant) and ColdFusion, along with Perl. At
that time Python and Ruby were not on the web development radar.

PHP is not "arguably the most common language for web development": it's by
far the most common. Much of that is due to WordPress, Drupal, and other PHP-
based CMSs, but unlike Ruby and Rails, PHP had a large developer base before
WordPress and Drupal.

The article also completely ignores JavaScript, which thanks to node.js is
gaining web developer mindshare faster than either Python or Ruby, and may
push PHP's share down.

[PHP also uses the hated $ to prefix variable names, but that hasn't slowed it
down. PHP is not as pretty as Python or Ruby but it's a lot easier to read
than Perl.]

~~~
cafard
"PHP is not as pretty as Python or Ruby but it's a lot easier to read than
Perl."

Good Perl is quite readable, and bad PHP, well, you are a fortunate man if you
have never encountered any, and a top-notch reader if you have and have found
it easy to follow.

------
pixl97
Languages that target and reach large numbers of beginners tend to do well.
PHP tends to be the primary example, but BASIC and all forms of it continued
by Microsoft are another. When any newb can sit for a few minutes with your
language and a HOWTO and make a functioning (web)app it has a chance to be
successful.

It's hard to target people with a 'harder' syntax even if it may be better for
some particular reason. Once a person has learned one language it is more
worthwhile to gain a more broad knowledge base in that one rather then invest
time learning in another.

It's likely most people that learned perl didn't start with perl as their
first language. At the time it what came with whatever form of unix they had
and extended the scripting they did, but was not friendly. There was just a
lack of alternatives at the time. Now, in an interconnected world with no
shortage of better alternatives, there is simply little reason to invest any
time in learning Perl.

------
signal9
My me-too post.

I was a web developer working nearly exclusively in Perl during the time
period the author describes. I understand the author's lack of a handle on the
period as he was, as he describes, in middle school at the time. Me, I had a
job and a family and I was an actual Perl programmer. Come at me bro.

That aside, the description of a transition of developers from Perl to Python
just didn't happen the way it is described in the article. Or, to be fair, it
didn't happen that way for me.

I worked on a team extracting data from a number of disparate data sources and
presenting reports on the web - basically the idiomatic Perl task. We tried to
bring in PHP for a bit but found it wanting. As our jobs evolved out from
under us, each of us moved on from Perl. Reporting jobs were becoming largely
obsolete and there was market demand for working in other languages elsewhere.
Being the early oughts, most of the engineers I knew had at least a few
languages in their repertoire.

Of the developers I worked with, I was the only one to pick up Python. I
remember feeling like I wanted to work with a dynamic language where OO was
more core to the language feature set. Ruby and Python were both viable,
though less known, options. I don't remember why I chose Python over Ruby, but
I did.

My colleagues went on to work in Java or C#. Over time, I did a bit of both as
well, especially C#. One buddy of mine still does his personal and peripheral
scripting in Perl. I've largely forgotten the language.

Back on topic, I simply did not see an exodus of developers from Perl to
Python. It just didn't happen that way within my community. Jobs got phased
out, new ones began, often with new tools.

Off topic, what I did see at the time was a large movement of COBOL developers
to JAVA. I saw that as a genuine migration, in earnest, of developers who were
facing obsolescence.

------
agumonkey
I only had a shallow knowledge of perl, then I read this
[http://matt.might.net/articles/perl-by-
example/](http://matt.might.net/articles/perl-by-example/) . As much as I like
linguistics, perl sometimes feels a little too creative :)

~~~
qohen
FYI, that article got criticized on HN pretty heavily not ago for not doing
things in the 'modern Perl' style:

[https://news.ycombinator.com/item?id=7220167](https://news.ycombinator.com/item?id=7220167)

~~~
agumonkey
Thanks, I assumed good authority from the author since he's into Programming
Languages research. Heading to your link now.

------
GFK_of_xmaspast
I used perl as my go-to general purpose language for years and years until I
joined a python team in 2004, now the only thing I use perl for is as a sed
replacement. The perl6 stuff just killed all its momentum dead, and then it
seemed to drop off the face of the earth.

I don't see it coming back anywhere near what it was fifteen years ago. Too
little too late.

The only thing I miss about perl is the regexes right there at the heart of
things, but I'll trade those for scipy/numpy/cython/etc and come out the
better for it.

------
metsgrets
I'm going to take a moment to vent about Perl. My company was experimenting
with it as an alternative to Ruby based on the enormity of available CPAN
modules.

1\. CPAN is awful. The website itself is so bad that the "correct" way to
browse it is to use the big brother "Metacpan". Metacpan is also very bad,
they strayed too close to CPAN design. Navigating it is a pain, and most of
the documentation is done very poorly because no one puts time into formatting
their readmes. None of the modules are in github, the issue tracker is a
nightmare, the links make no sense ( "Source (raw) Browse (raw)" ) - the
website itself is poorly done.

2\. CPAN has many modules, which sounds like a selling point. The truth is
that many of the modules we have worked with have bugs and poor documentation,
and almost all of them are unmaintained. The owners either gave up or actually
died (this is an old language after all). There is absolutely no support for
trying to do common tasks with CPAN modules. You can't Google for your error,
you won't get a response on StackOverflow. Bug reports don't get answered
because the ecosystem is a ghost town. This makes trying to do common tasks
painful.

3\. CPAN is just messy all around. There's not even a command line flag to
find out what version of a module you have installed. You have to hack into
its internals to figure out what versions you're running. Some modules are
hosted in foreign countries that intermittently decide not to download. Builds
have broken due to inability to download from a mirror. A "benefit" of CPAN is
that modules are tested against multiple architectures for you. The reality is
that these tests don't matter. The Perl developers I've worked with bypass the
tests with CPAN by installing with --notest because it's faster, and more than
once a module has failed to install because the tests failed. But the failure
was either a false positive or had no noticeable impact on implementation, and
there's no alternative and no one to respond to bug reports. The only known
benefit of CPAN - automated test running, has never once proved helpful.

4\. One point I like in this article is that Python makes the right thing
obvious. Perl's "multiple ways to do things" is one of its bigger design
flaws. It seems like Larry Wall (creator of Perl) has a no-one-likes-this-
langauge-so-try-to-please-everyone-by-offering-every-way-to-do-it complex.
It's all to the detriment of the language. I have to Google for how to iterate
over a hash every time, because there's multiple ways to do it, and they all
suck. I never know if iterating over a $hash is the same as iterating over a
%hash or a \%hash. Or if I should be searching for "hash" or "hashref" or if I
should be using a "list" or an "array" or a scalar or who cares. The multiple
ways to do things only amounts to one asshole on the team will exploit some
unknown feature of map to write shorter code, not document it, and no one can
read it. Any efficiency gained from shorter code is lost to unmaintainability.
Also, Perl is not efficient, so it doesn't matter.

5\. The language itself is gross. Beauty is subjective, readable code is not.
The prefixing of variable names with @, % et all makes dissecting code hard
and Googling impossible. The tacking-on of modern functionality will slap you
in the face repeatedly. See: references. References are one of, if not the,
biggest design flaw in Perl. They were introduced as a tack-on to hack over
it's shitty default data structures. They make reading and writing code
confusing, overly complicated, and haven not once offered us any benefit.
Perl's leaky abstraction over poorly implemented data structures is easily
seen in references.

6\. No really, the language is gross. It has magic built in, and the syntax is
a nightmare. Everything is done with sigils (characters like ~!=@#$ etc). You
get function arguments as @_ . You do a regex match with $string =~
/(capture)/. This will magically populate $1 through $n with capture groups.
This is bad. To substitute a string, you do $string =~ s/a/b. This modifies
the string in place. Try to Google for how to not modify the string in place.
Seriously, try and Google for it. If you forget to include an even number of
values in a list it becomes another data structure entirely. If you don't put
a '1;' at the end of your module code it will fail to work (no, really).

7\. Larry's personal beliefs stray into Perl too much. Larry is a well known
Christian, and you must "bless" a reference, a keyword baked into the
language. This creeps me out. It doesn't really matter, and I 100% acknowledge
how judgmental I'm being, but it still is out of place in a programming
language.

8\. All of these reasons culminate to one point I just realized: Perl is a bad
language for a team. It might be fine for one person to write code that will
never have to be maintained or read to accomplish some dirty task. The
"features" of Perl ruin it for a team environment. Feautres like its
"flexibility", wheel reinventing to avoid buggy CPAN modules, unreadable
features hidden in sigils, magic, poor documentation, and hacker culture make
it a very poor choice for multiple people to work on the same thing.

This is the perspective of a relative newcomer (~3 months of Perl
exploration). I'm not a Python advocate and I don't have a strong opinion of
what other language you should use, but Perl has caused us many problems and
we switched to Ruby early on because of them. Maybe if / when I learn more
about it I'll have a different opinion of it. Right now though I agree with
this article and seeing Perl go out the door is fine with me.

~~~
slashdotaccount
Troll harder, greenhorn. (account "metsgrets" created 7 hours ago)

> CPAN is awful […] Navigating it is a pain […] the issue tracker is a
> nightmare

These are opinions. I cannot see any facts to substantiate the claims.

> most of the documentation is done very poorly because no one puts time into
> formatting their readmes

No, most of the documentation is the best among libraries in any programming
language because everyone uses documentation templates and then fills in the
details in copious amount. These templates have been honed over years, and the
docs are regularly quality checked by automated services. It also helps that
the documentation format POD is so so stupidly simple that it never gets in
the way of work: a programmer spends all the time writing content, none on
formatting.

> None of the modules are in github

All of the modules are in Github.

> the links make no sense ( "Source (raw) Browse (raw)" )

"Source" shows the module's source (HTML, syntax highlighted). "Browse"
browses the directory structure of the unpacked distribution. The raw links
are the plain text equivalents served by the API primarily for programmatic
access. All of this is readily obvious by just following a link.

> many of the modules we have worked with have bugs and poor documentation

Unsubstantiated, no details.

> and almost all of them are unmaintained

CPAN freshness tells a different story.

> owners either gave up or actually died

There's a process in place for taking over maintenance. It is used a couple of
times a month.

> There is absolutely no support for trying to do common tasks with CPAN
> modules

Wrong. Any common task has several modules.

> You can't Google for your error

Unsubstantiated, no details.

> you won't get a response on StackOverflow

Wrong. Unanswered quota is only 10%.

> CPAN is just messy all around

Same is true for any file archive. Show me a programming language where this
is not the case. At least it's centralised, not strewn across the Web! On top
of the archive, curated indexes such as
[http://p3rl.org/Task::Kensho](http://p3rl.org/Task::Kensho) exist.

> There's not even a command line flag to find out what version of a module
> you have installed. You have to hack into its internals to figure out what
> versions you're running.

Wrong.

    
    
        $ pmvers Catalyst
        5.90060
    
        $ perl -MCatalyst -E'say Catalyst->VERSION'
        5.90060
    

> Some modules are hosted in foreign countries that intermittently decide not
> to download. Builds have broken due to inability to download from a mirror.

Then pick a mirror near you.
[http://mirrors.cpan.org/](http://mirrors.cpan.org/) The standard CPAN client
does this automatically during first run.

> The only known benefit of CPAN - automated test running, has never once
> proved helpful.

Unsubstantiated, no details.

> It seems like Larry Wall (creator of Perl) has a no-one-likes-this-langauge-
> so-try-to-please-everyone-by-offering-every-way-to-do-it complex.

Wrong, this is because humans have different ways to think and preferences how
to express themselves. The programming language works _with_ the grain of the
human mindset, not against it.
[http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt](http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt)

> I have to Google for how to iterate over a hash every time, because there's
> multiple ways to do it, and they all suck. I never know if iterating over a
> $hash is the same as iterating over a %hash or a \%hash.

Then you know less than a beginner in his third lesson.

    
    
        ⎆ my %hash = qw(a b c d); my $hash = \%hash
        ⎆ while (my ($key, $value) = each $hash) { say "$key => $value" }
        a => b
        c => d
        ⎆ while (my ($key, $value) = each %hash) { say "$key => $value" }
        a => b
        c => d
        ⎆ while (my ($key, $value) = each \%hash) { say "$key => $value" }
        a => b
        c => d
    

> if I should be searching for "hash" or "hashref" or if I should be using a
> "list" or an "array" or a scalar or who cares

Only bash and Tcl free you from thinking about and selecting the appropriate
data type.

> The multiple ways to do things only amounts to one asshole on the team will
> exploit some unknown feature of map to write shorter code, not document it,
> and no one can read it.

This is a social problem, and not the responsibility of the programming
language or its designer. Anyone can write crap code in any language. Enforce
code style and policy locally. Static analysis tools like
[http://p3rl.org/perlcritic](http://p3rl.org/perlcritic) exist. Apply them.

> Perl is not efficient

Perl remains the fastest of the scripting languages.

> Beauty is subjective, readable code is not.

Unreadable code is a social problem across all programming languages. This has
nothing to do with Perl per se.

> The prefixing of variable names with @, % et all makes dissecting code hard

Wrong, sigils make the nouns stand out, just like capitalisation in written
German. Both empirically make reading faster and comprehension easier.

> Googling impossible

Wrong. It is true that search engines drop sigil characters from the query,
but the context words still find the result in the index.

> References are one of, if not the, biggest design flaw in Perl […] make
> reading and writing code confusing, overly complicated

Unsubstantiated, no details.

> haven not once offered us any benefit

Wrong, as references are the basis for objects (OOP).

> the language is gross. It has magic built in, and the syntax is a nightmare

Unsubstantiated, no details.

> You get function arguments as @_

Concept stolen from Shell, already remedied in version 20. Signatures have
been available for years with modules.

> You do a regex match with $string =~ /(capture)/. This will magically
> populate $1 through $n with capture groups. This is bad.

Agreed, side effects are evil. That's the legacy interface and impossible to
deprecate/remove. The expression will also return a list of the captures which
you can then assign or mangle as you wish.

    
    
        my @results = $string =~ /(capture)/
    

Good style dictates to prefer this interface.

> $string =~ s/a/b. This modifies the string in place. Try to Google for how
> to not modify the string in place. Seriously, try and Google for it.

Yes, and?

    
    
        g perl substitute return modification
    

(Type it out to see Google suggestion/autocompletion.) First five results all
teach:

    
    
        my $new = $string =~ s/a/b/r
    

> If you forget to include an even number of values in a list it becomes
> another data structure entirely.

Wrong, a list is a list no matter how many elements.

> If you don't put a '1;' at the end of your module code it will fail to work
> (no, really).

Valid complaint. Again, it's too late to fix it because existing code needs to
keep working, back-compat is serious business for perl5-porters. New projects
with modern Perl just avoid the need for that last line:
[http://p3rl.org/true](http://p3rl.org/true)

> bless […] but it still is out of place in a programming language.

The word is religion neutral. Your biases show.

> The "features" of Perl ruin it for a team environment.

Unsubstantiated, no details.

~~~
singingfish
Yeah, I don't understand why people want to hate on perl for no reason. Perl
people don't generally hate on other languages much (maybe aside from Java and
PHP).

~~~
collyw
sounds like he didn't really understand many features of the language.

------
rasz_pl
Perl - the ultimate job security tool.

When I come upon a Perl program that does 80% of what I need, and would do
100% when modified, I simply turn around and look again. I consider reading
other peoples Perl code on the same level as firing up Hexrays to debug closed
source Mips programs.

