
Why Perl Didn't Win - nkurz
http://outspeaking.com/words-of-technology/why-perl-didnt-win.html
======
ghshephard
I was a Perl scripter (I never rose to the level of JAPH) from around 1998 to
2002, with my final accomplishment being a two-way HRIS synchronization system
between our installation of peoplesoft and our LDAP server (Netscape LDAP
server, awesome product).

And then I met Python, and I never wrote another line of Perl, and have
written some python code almost every week since then.

There were two _personal_ reasons why I left Perl.

First - I would write some code, it would do what I wanted, but then I would
come back in a week (or even a few days) and have no idea _how_ it worked.
This is code that _I_ wrote. Yes, I know this is a personal failing (I said
these were _personal_ reasons) - but, on the flipside, I've never had anything
I've written in Python that I didn't completely understand how it worked any
time in the future. Perl just let me write code that was too complex for my
brain to comprehend. I blame implicit variables. [edit - and perhaps an over
reliance on regex.]

Second, If I hadn't used them for a month or so, I used to struggle with
Arrays of Hashes and Hashes of Arrays. Once I eyeballed my template, it all
came back, but the syntax imposed enough cognitive overhead that I struggled
with that data structure (which is one that you use a lot).

On the flip side - the very _first_ day I was learning Python, I thought to
myself, "What if I just drop an array (list) as an object in this hash (dict),
or a dict in this list? Will this work?

And it did. Close to zero cognitive overhead.

So, that's why I left Perl - Readability and complexity of what should be bog
simple data structures.

~~~
Mithaldu
A consideration to you:

You spent 4 years of learning Perl, 4 years in which you likely also massively
improved your skills as a programmer, regardless of the Perl angle. Then you
went to Python, bringing in your programmer experience, probably started off
with a good book and had a much happier time.

So, do challenge yourself and ponder how much of that come from having spent 4
years programming, and how much from actual differences in the languages?

~~~
ghshephard
It's an interesting perspective, but, seriously - for the life of me, I
struggled every time I wanted to declare/parse/initialize an AoH or HoA on
perl. And I'm not engaging in hyperbole when I said that my code was basically
completely foreign to me a week after writing it.

Obviously developers (which I am not), and people with more discipline and
structure, and write eminently readable and maintainable perl code - but as my
day job was network engineering, I was just looking for the lowest cost path
to get the job done.

I really did love CPAN though.

~~~
kbenson
That's interesting, because defining an AoH or HoA in Perl is almost identical
to how you would do it in Javascript, which is to say it looks a lot like
JSON.

If it was the access and assignment semantics, the normal case is also fairly
straightforward; use curly braces for hash/dict keys, square brackets for
array indices.

E.g.

    
    
        my %data =  (
            foo => [
                { bar => 10, baz => 12 },
                { bar => 20, baz => 13 },
                { bar => 30, baz => 14 },
            ],
        );
        print $data{foo}[2]{bar}; # 30
        push $data{foo}, { bar => 40, baz => 15 };
    

Given, using array and hash references with the built-in
push,pop,shift,unshift,keys,values and each used to require some annoying
dereferencing that could be confusing.

Do you still find that confusing?

~~~
ghshephard
I'll admit to not having looked at it for about 12 years, and, of course, I'm
not saying I couldn't figure out after 2-3 minutes over looking over the
pattern, but it just never flowed the way it did with Python for me.

    
    
       data ={}
       data['foo']= [
          {'bar':10,'baz':12},
          {'bar':20,'baz':13},
          {'bar':30,'baz':14}
       ]
       print data['foo'][2]['bar']
       data['foo'].append({'bar':40,'baz':15})
    
       for x in data['foo']:
          print x['bar']
    

Maybe it had something to do with indices always being [] brackets and {} only
being used to define the dict structure. Or maybe it got easier sometime in
the last 12 years? Or, maybe you could onto something, and having come pre-
primed with knowledge hashes/arrays, I just picked up python more quickly.

Anyways, it was just a personal story told as well as I could remember it.

------
bane
Maintenance. I say this as somebody who loves Perl, quirks and all (actually
because of the quirks). It's actually a beautiful language to work in in the
same way English is a beautiful language -- it's a beauty because it's a
goddamn mess. But it's a rotten language to maintain.

Sure, it's perfectly possible to write highly maintainable code (I have a few
30-40k line Perl projects that I can open up and get right to work on without
too much fuss) and you can create some coding standards and stick to them, and
write perfectly maintainable code. But Perl is a bit like C++ in the sense
that everybody has different standards and those standards change and "non-
standard" bits of the language start leaking into your code and you spend as
much time unmessing things as you do writing code.

I don't think Perl will ever really die, it's too convenient, but it's
definitely never going to enjoy the dominance it once had. It'll fall back to
a very good one-off system admin and log processing language with some extra
bits, but it's simply a language that the rest of the world has surpassed and
Perl 6 just isn't a realistic offering, after a _very_ loooong wait (nor does
it fix the issues non-Perlers have with the language -- it's basically fan
service).

~~~
mst
I don't want the popularity we once had.

The same people who wrote unreadable, unmaintainable perl went on to do the
same sort of damage in PHP, then python, then ruby/rails, and now node.js/go.
They were never a net positive to the community, and I'm not sorry to see them
causing problems for somebody else.

(and before somebody says "but that doesn't happen in X" ... yes, it does,
even python lets you write code that looks superficially comprehensible but
turns out to be so horribly illogical structurally that it's impossible to
maintain - I quite like python but I've been there and I was kinda scared
because at least wrong perl looks wrong to start with, whereas wrong python
looks fine until you realise just how much of a crawling horror it is)

~~~
mamcx
With python is not the same. Even if the developers is truly bad and do a
mess, is a _decipherable_ mess. Requiere truly talent to do a hard-to-
understand mess in python, and in that case, is very likely the code was made
by a good developer ;)

~~~
yellowapple
> Requiere truly talent to do a hard-to-understand mess in python, and in that
> case, is very likely the code was made by a good developer ;)

Last I checked, the whole "if it was hard for me to write, it should be hard
for others to understand" was still a mockery, not a seriously-interpreted
excuse. It ignores the fact that the programmer's future self will eventually
need to maintain that code. The developer might have skill, but one who writes
unmaintainable messes as anything other than a Perl-golf-style mental exercise
probably lacks wisdom. :)

------
jmacdotorg
Articles which critique Perl as a whole by focusing on Perl 6 always strike me
as a bit strange. As someone who works professionally with Perl every day, and
starts several new projects using Moose-centric modern Perl techniques every
year, the amount of time I or any of my colleagues spend thinking about Perl 6
is negligible.

The modern Perl movement, as far as I can tell, arose in part from Perl
hackers who started to treat the wandering Perl 6 project — rife with neat
ideas, if not with release engineering — as a skunkworks for Perl 5
extensions. In the gap between the middle-aughts and 2014 that this writer
waves away with “is anyone still paying attention?” due to no Perl 6 release,
the active Perl world adopted Moose, and many Perl-based Moose-driven
technologies — Catalyst, DBIC, and so on.

These technologies, and the communities around them, have thrived on their own
ever since. Nowadays when I think about Perl 6, it is often because I am at a
Perl conference and Larry Wall is literally at the podium talking about it and
I am like “Well. You go, Larry Wall.”

Perl really has reinvented itself in the last handful of years, at least in
the eyes of those who make a living inventing new things with it. I can’t call
this writer wrong — their perspective is their own. I suppose I can only learn
to appreciate the notion that, to hackerly folks who aren’t as ensconced
within the modern Perl community as I, the language is this thing from the
1990s that kicked the bucket through one bad decision in the summer of 2000,
leaving behind acres of legacy code that’s still being scraped away.

To be fair: this indeed describes a lot of what I am hired to do. It’s just
that I replace it all with newer and better Perl…

------
overgard
Perl is sort of like trying to read someone else's brain (in this case Larry
Wall's). You get themes and kind of the gist of where it's going, but it never
quite adds up to some sort of coherent whole.

The defense has always been that Perl is designed more like natural language
than programming language, ok, but: natural languages are a LOT harder to
learn than programming languages. Put me in a room with Haskell and I'll learn
it in a month. Give me a month of training in french and I'll maybe be able to
not make an entire ass of myself if I try to get from point A to point B.
Human languages are hard. Design wise -- I'm not sure that's what you want to
aim for.

Almost everything you learn is... surprising. Like flattening lists. Useful in
a context, maybe, but is that the kind of thing anyone would ever expect? And
why is "list" (@) part of the variable name in the first place? It's like
"dynamically typed, kind of, except your variable name has to say if it's one
thing or many things or many things referenced with keys". What the fuck? I'd
rather the python way of "it's a name that points to a thing, whatever that
thing is". GOT IT. Simple.

I program in C++ for a living, probably the biggest clusterF of a language
ever devised (outside of perl), and the thought of reading Perl still
terrifies me.

~~~
stormbrew
> Put me in a room with Haskell and I'll learn it in a month. Give me a month
> of training in french and I'll maybe be able to not make an entire ass of
> myself if I try to get from point A to point B. Human languages are hard.

To be fair, I don't think this is actually because human languages are all
that hard to become competent (note: not fluent) in. It's just that with
computer languages you have an endlessly patient practice partner to work
with. In particular, I think the complexity of competent Haskell is definitely
higher than most spoken languages.

------
rustyconover
The same things could be argued as for why, why C didn't win, or C++ didn't
win, or even really PASCAL/Smalltalk/Lisp didn't win. "Winning" is temporary
and not the end goal of any language and is best left to be declared by
Charlie Sheen like pundits trying to demonstrate their language bigotry.

Is Perl the first tool that some of us think of when solving a problem? It
might not be for you but it is frequently for me. Ruby might be your first
choice, and really that's fine.

You're not a lesser or better programmer than anyone else if you choose
something besides Perl either. Honestly, if you can solve the problems that
you need to solve and you can work with your team, that's the only thing that
matters. Not that you're using some language that isn't "winning".

As for Perl not having support for recent things like Stripe, that's just
silly to argue (the author really should have searched the CPAN). Perl has
many new modules, Dancer, Catalyst, Moose, Plack, Starman, Net::Stripe
(maintained by me), and full support of AWS's offerings. And, yes modules
written in 1999 do get used today, just look at all of LWP.

"Winning" isn't everything. Admittedly, Perl 6 isn't out or even moving
forward visibly but doesn't mean that the language is irrelevant. Just watch
[https://metacpan.org/recent](https://metacpan.org/recent) to see the pulse of
the community and the new modules released and updated daily.

~~~
oalders
If this article had been written about natural languages, it might be called
"Why French didn't win". It may not be the world's most popular language, but
it's extremely useful to a lot of people.

Winning isn't everything. :)

------
kephra
> You need large absolute numbers of users to grow a library. That's why
> library ecosystems like that of Python, Ruby, and Node.js have grown large
> in recent years.

Thats where the author missed an important point. None of those library
archives have the culture of PAUSE+CPAN to constrain a minimal code quality
when it comes to configuration, documentation, regression test and
installation. This minimal code quality is constrained by CPAN testers, when a
module hits PAUSE, before the module is seen by the unwashed masses who access
CPAN.

I've seen many library archives of other languages, but they are all full of
junk, undocumented junk, untested junk, and junk that does not configure or
install everywhere. The worst example was the LuaRocks system. The quality of
the libraries in the Rocks archive had been so bad, that the church decided to
remove the module keyword from Lua language, to get rid of this junk. But the
code I see for Ruby/Rails, NPM/Node, or PyPy/Python is junk compared to even
those Perl modules, that barely managed to convince CPAN testers.

You not only need the absolute numbers, but important you need a core group
starting the ecosystem who constrain a coding culture. Raw numbers are not
enough. A million apes wont write a Shakespeare novel.

~~~
spacemanmatt
I have been so very burned by CPAN module quality in the past. Claims to CPAN
'minimal code quality' ring hollow with me. Apache's collection of Java code
is MUCH higher quality on average.

------
autarch
I suspect that all the languages that are "winning" right now will have "lost"
10-20 years from now too.

What's the longest lived language out there right now that's actually still in
heavy use? I'd say C. But C has clearly fallen from its position of complete
dominance when _every_ new project was written in C (because it was much
easier than writing assembly).

C++ had its day as well and lives on in many places, but again, it's no longer
the go to language for projects where C isn't the right choice.

How about Java? It was hot stuff in the 90s and it's still huge today, but it
clearly didn't "win".

PHP? We'll be living with legacy PHP code bases for at least 10-20 years but
does anyone honestly think this will be the language that the startups of 2025
use?

Programming is both incredibly faddish and incredibly fast paced. Today's new
hotness is tomorrow's "dead" language.

Give it 5-10 years and I expect to read "Why Python Didn't Win". I expect
we'll see a "Why Ruby Didn't Win" in 10-15 years too.

~~~
rdtsc
So maybe winning is more like winning for a time period. PERL did win. It won
up until early 2000s, then lost. I am guessing it is not getting picked much
for new, greenfield projects. I think that is a cut-off metric. One way get
there is to find a niche. Maybe it isn't the new use-for-everything language.
But at least can become the "ok, use for this one area" language.

C -- still winning in that respect. It is used in many places just because of
hardware or time constraints -- drivers, micro-controllers, optimized fast
parses, low level socket handling code. It just got specialized. Not used
probably for business or back-end systems.

I don't think PERL can claim that same. It seems to me its role has been
replaced by Python, maybe Ruby, Java (for web server back-ends).

C++ still winning. None of the current languages including the new contenders
like Rust and Go can eat its lunch (as they say) when it comes to performance.
Things like games or signal processing. Anything requiring low latency
responses will still see C++ being picked. And with C++11 and C++14 it is
getting a new breath of fresh air. Whoever is going to contend with, will have
a steep hill to climb.

Java? Java still winning. Now if you think of Java as JVM it is winning even
more. Java itself if just a very average language that is also fairly
performant, explicit, IDE friendly. If you had a lot of money and could hire
potentially lots of average or below average programmers to throw at a problem
(which I think often is the wrong approach, but if you did), Java is your
language. And Android. Don't forget Android. If anything it is winning just
because of that.

> Give it 5-10 years and I expect to read "Why Python Didn't Win". I expect
> we'll see a "Why Ruby Didn't Win" in 10-15 years too.

I think it replaced PERL by in large and but now it is feeling the heat in a
lot of areas where it was being used. Scientific community has Julia as a new
kid. Server back-ends have Go and Javascript. Not one big threat but little
paper cuts here and there.

Ruby, I am not familiar with it much, from my outside perspective it looks
like a one-trick-pony = Rails. If something replaces or obsoletes Rails, I
don't see Ruby rising and finding a niche. I could be wrong, so anyone please
correct me here.

~~~
kamaal
I think the definition of 'winning' people use around here is, if start ups
think its a trendy technology to use. So you will see all these new companies
stop using a particular language, and then when some conference happens you
will see talks around the older technologies have dried out, while people are
giving talks on the newer set of technologies.

Its then when you see articles/rants/blog posts on the lines 'Whatever
happened to X which was famous $current_years - 5 years back?'

Please note all the focus is around the new technology. Some one is writing a
new library around this new DB technology some one is using and is writing
about it. Some one just gave a talk on how some scalability problem was solved
by a specific feature in the language. Some one just talked about how testing
got easier, some one writes about how maintenance efforts got reduced because
of a new way in which language deals with type declarations, Or some
programming forum is full of questions and the Google auto suggests can tell
you your question as you are typing it.

Meanwhile some where in a MegaCorp, your maven can't see beyond the company in
house repo. And using a different library takes 3 months of permission cycles.
People sitting in there don't get interview calls and hear about people saying
that the old technology isn't hip any more.

Only thing that is buying Java some time is the large quantities of enterprise
code, which no one has the money to replace.

~~~
oneeyedpigeon
Can you fix the bug in "$current_years - 5 years back", please - it's
bothering me. If you're going to talk in code, at least get it right ;-)

~~~
oneeyedpigeon
Oh, come on downvoter - I put a ";-)" at the end of that. There's literally
zero tolerance for anything lighthearted here, isn't there?

------
steven2012
I gave up on perl when I saw the following code:

$x = $src[$src];

I was confused as hell until I realized that arrays and scalars had different
namespaces. That, along with the fact that "or" and || had different
precedences were what ended Perl for me. I'm not saying that wonderful code
can't be written by Perl, it just wasn't the right language for me in that I
hate memorizing one-off rules, which Perl seemed to have plenty of, instead of
a language that was more internally consistent.

~~~
mst
If you only want a single namespace for everything, I recommend sticking to
only scheme (note: I really love scheme for that property, I'm not being
sarcastic).

Once you learn -enough- perl, there's a sort of overall consistency that's
actually really nice, but there's a gap ... simple perl is very simple, but
mid-level perl is generally a mess until you get to the expert level, and then
its awesome again.

There's probably an analogy to text editors here.

~~~
anko
I couldn't agree more, and that's why I hate perl.

That gap in the middle makes it really hard to hire perl developers unless
they are experts. It's hard to find experts because they think perl code is a
mess before they get there.

It's probably the main failing of perl.

------
ww520
Perl lost because PHP took its place on the web development front.

Perl lost because Python/Ruby took its place on admin front.

Perl lost because the new version took forever to get ready and broke
compatibility with the old code.

~~~
unexistance
1\. True

2\. Linux Admin? maybe. UNIX admin? I'd say Perl still on, as it's installed
by default (yeah not popular anymore, but a LOT of legacy system still run)

3\. cannot comment, as never used new Perl, since UNIX still shipped with old-
ish Perl

maybe, just maybe it's not just winning & losing :D every language will find
it's place eventually.

~~~
nly
On 2: Still 193 unique files in /usr/bin on my system containing the string
'/usr/bin/perl'. Only 51 containing '/usr/bin/python'.

~~~
anko
are you saying python is more efficient? :P

------
steveklabnik
I have two programming tattoos: a Perl camel and a Ruby ruby. That basically
tells the story of why Perl didn't win for me: As soon as I started learning
Ruby, I thought, "Oh, a cleaned-up Perl" and never really wrote any Perl code
again.

I love Perl's personality, its quirkiness, and its massive amount of
libraries. Perl was _massively_ influential on me as a young programmer. But
I'm pretty sure that I won't be writing any Perl ever again.

~~~
Roboprog
Exactly. Perl 6 was forever delayed, and along came Ruby. Or rather, out from
the shadows came Ruby, which was already there before the Perl 6 debacle, and
just needed promotion. The Pragmatic Programmer books were pretty good at
pointing to this cool replacement for Perl that you never knew was already
there (as well as all the buzz from the RoR folks for those of us who weren't
in on the beginning)

I don't really think that the people who left perl all went to PHP.

Now if only there was a "Ruby lite" that ran more like Perl 5 (skipping the GC
for reference counting and a few other performance shortcuts)

~~~
Poiesis
I'm wondering if Swift will fill that role, eventually.

~~~
Roboprog
I hope so. That is, I hope there is a version of Swift outside of Apple-land
(Clang compiler for LLVM extension???). What little bit I have seen so far
looks promising, and it has a significant sponsor to get the language going.

------
kamaal
I got introduced to Perl in 2006, at a time when trolls were screaming 'Perl
is dead' from top of the buildings. Perl was revolutionary to some one like me
who had only done C and assembly language programming. And it turned to be a
great tool for the job back then(Processing massive unstructured text files).
Its still unbeatable in that area.

Back then I saw that people who worked around enterprise projects that used
some kind of a relational database used a lot of Java. People who were jumping
to the Web 2.0 Bandwagon, used stuff like Python and Ruby largely because of
the frameworks. Thereby what's really apparent is tools that are best suited
for the job get traction.

Perl is still unmatched for many things. Unixy things like dealing with large
quantities of text. Gluing things together, getting stuff done quickly etc
etc.

Perl's every day use cases were going way, as database and web heavy things
ruled the business scenarios. Perl largely occupied a niche and ruled it. So
is Python today(Web frameworks), and ruby. Also Perl reached a very high peak
in the 90's. And reaching that kind of level again isn't possible unless Perl
does some very new and paradigm changing.

Perl 6 is kind off believed will do that eventually some day. But from what I
last heard a few day back in this very forum, there are not close to anything
serious even in another 2 years from now.

------
esaym
Articles like this make me sad. Perl is a mature, well supported language with
a thriving community. It is not in maintenance mode, a new version has come
out every year for the last 4 or five years, all with new features, many more
planned. Plus the perl conference attendance has been up every year for the
last few years. [http://www.yapcna.org](http://www.yapcna.org)

You say I should use something more modern? Are not all languages based off of
methodologies from 1950?

And which one of these modern languages do I choose? Rust, Go, Python, Ruby,
Java, JavaScript, node.js, coffee, dart, swift, C#, F#, Scala...

Probably many more that I missed but my head already spins. If anyone says
they know more than 2 of those languages, then they only know them poorly.

I get tired of some new language coming out every year, along with a new
community of trolls to bash everything and tell me I need to drop everything I
already know to learn their new mess.

I must say, none of these languages that are in the news impress me. Yet there
are many perl modules that do impress me.

I enjoy perl and its community. I like that it is not coupled with any huge
corporate sponsorship. It is the bazaar in "The Cathedral and the Bazaar" and
that I like.

------
jacques_chester
The final section, which I was anticipating for the whole article, was
essentially this:

[http://en.wikipedia.org/wiki/Osborne_effect](http://en.wikipedia.org/wiki/Osborne_effect)

What killed Perl? An imaginary Perl did.

~~~
oalders
>> What Killed Perl?

The article is entitled "Why Perl Didn't Win", not "Why Perl is Dead". Perl
hasn't been killed.

~~~
spacemanmatt
It's dead to me.

------
mattzito
I think there's some good points in this article - and I relate to it, 'cause
this is _exactly_ how I learned Perl.

The one other item that I'll add is that some of the characteristics that make
Perl awesome for sysadmins, like extremely flexible syntax and the ability to
freely access data sturctures in a variety of contexts, can make it more
difficult to build proper software development projects.

Maybe it's just my limited experience, but it seems like Perl organizations
spend a lot more time on mandating coding styles and debating best practices
compared with more structured languages like Ruby or Python.

~~~
gsteinb88
But as was mentioned in another comment, what you mention as a key appeal for
sysadmins is _exactly_ why I can't stand perl. In particular "extremely
flexible syntax" makes taking over the sysadmin job from another person, or
joining a team, a ridiculous amount of effort. I can't begin to tally the
number of hours I've spent with perl code open in one window, and a web
browser open to various different perl guides, the documentation, etc. trying
to figure out what tricks some script is using that makes it completely
incomprehensible to me.

Is it fun? Sometimes, except never when a key service is down and you have
users breathing down your neck. Or your website is down. Or really, trying to
do any kind of maintenance work. And guess what happens? More crazy patches,
probably written in an entirely different style! So now there are $n+1$
different styles in that script, and my successor is going to be even more
frustrated with me than I am with my predecessors.

On the flip side, it's been a great education on the difference between
maintaining code for your own use and code in an organization...

------
stcredzero
_How does a language win? By being compelling enough to be used for new
things. It 's not solely a technical concern; it's a concern of the language
community and ecosystem._

One of the most valuable 4 sentence paragraphs I've read from an HN post in
awhile. (Perhaps 3, but the semicolon really separates 2 sentences.)

~~~
twic
The semicolon separates two independent clauses, but they constitute a single
sentence.

When we're thinking about language, clauses are probably a better atomic unit
than sentences; clauses are a semantic unit, and sentences are really just a
syntactic packaging format for some number of clauses. Just like we should be
counting expressions (or something) rather than lines of code.

~~~
stcredzero
I'll take that comment as a parody?

~~~
twic
Sure, whatever you like.

~~~
stcredzero
Well played!

------
dmckeon
As a Perl and Modern/PBP fan, I have to suggest that CPAN has become a poorer
resource over time:

> _In the olden days, you could expect to find a Perl module for most anything
> you wanted to do_

but also:

 _Having 57 modules all called Sort will not make life easy for anyone (though
having 23 called Sort::Quick is only marginally better_

and it seems that every time I look for a useful module on CPAN I find myself
in a _twisty little maze of packages, all different._

TIMTOWTDI, yes, but which one (or several) of the available modules will have
a usable combination of convenient utility and mutual compatibility? Over
time, CPAN has started to feel like the house of someone who rescues animals,
but cannot let go of any of them.

~~~
davewood
There are a few things to consider when trying to pick a good/the best module
for a problem.

\- ask in irc.perl.org. it is very likely to get pointers from very
experienced people.

\- use metacpan.org and pay attention to the votes/likes it got. and read the
reviews.

\- each and every CPAN module is automatically tested. look at the stats to
weed out problematic modules.

\- check out the release frequency and when the last release occurred.

\- read the Changes file

\- take a look at the tests for the module, is it well tested? are there alot
of tests?

If you are past a certain point in your life as a Perl programmer this comes
very natural and does not take alot of time.

~~~
liotier
I agree, but naive new Perl users might benefit from some prominent showcasing
of well-known good modules or maybe comparison charts between modules in the
same functional niche... Maybe that is a subject better left to Perl bloggers
rather than to the neutral CPAN, but first contact with Perl is sometimes an
embarrassment of riches.

Anyway, I love the CPAN - whatever I imagine myself wanting to do, five people
have done it already !

~~~
phaylon
Well, MetaCPAN has a leaderboard of modules, but it could be a bit more
prominent:
[https://metacpan.org/favorite/leaderboard](https://metacpan.org/favorite/leaderboard)

------
schmonz
I recently spent 4.5 years at a big bank developing identity-management tools.
They were written in Perl. The first thing I did was screw up in production:
[http://www.schmonz.com/2014/06/01/tdd-in-
context-1-keeping-m...](http://www.schmonz.com/2014/06/01/tdd-in-
context-1-keeping-my-job)

So I started carefully making the code testable, then gradually adding tests
and refactoring under them, and gradually adopting and taking advantage of
Moose, shipping every month all the while. There was never a second screwup.

(Will big banks keep choosing Perl for new projects? Yes, for a long time.
It's firmly entrenched. It didn't win, but it'll probably never lose either.)

Would I choose Perl for a new project? That depends. For programmers with
taste, discernment, and discipline, Perl-the-language + Perl-the-CPAN can be
incredibly and sustainably productive. For other programmers, it's enough rope
to quickly cut off bloodflow to your foot, which you can then use Perl to
amputate.

In other words, Perl is at the high end of the risk/reward curve. If I could
mitigate the risk -- say, by convincing myself that I'll always be in a
position to hire great programmers or nobody -- then I'd absolutely want the
reward of developing a new system in Perl.

------
atmosx
I think the article is a little bit harsh on Perl. Ruby (1995) and Python
(1993) wouldn't probably exist without Perl (1987). Hence IMHO it's just a
sort of evolution, nothing more. The other two languages _learned_ from Perl's
mistakes and were _better designed_.

------
winter_blue
At the end of the article, he/she says "the Swift programming language has
been public for less than a week and already has more users than Perl 6, and
_Swift is entirely built on technologies which have been invented since the
Perl 6 announcement_ ".

That's simply false; anyone who's been in the programming languages field for
a while knows that...

~~~
aaronbrethorst
I interpreted that as 'Perl 6 dates back to 2000, while LLVM (upon which Swift
is built) dates back to slightly later in the year in 2000.' (although, to be
fair, the LLVM website first appeared in 2002.)

------
narrator
I always check on indeed.com to confirm the popularity of things. It looks
like Python just broke past Perl on absolute job posting numbers.

[http://www.indeed.com/jobtrends?q=+perl+developer%2Cpython+d...](http://www.indeed.com/jobtrends?q=+perl+developer%2Cpython+developer&l=)

------
raiph
The domain outspeaking.com is owned by chromatic's company.

Afaict chromatic was the first to promote the article with a tweet shortly
after it was published and shortly before it appeared here on HN and reddit.

When someone noted this connection on reddit and said they thought chromatic
wrote it his response was "I'm not the only person with access to the server.
Anonymous wrote that article."

[http://www.reddit.com/r/perl/comments/27o6h5/why_perl_didnt_...](http://www.reddit.com/r/perl/comments/27o6h5/why_perl_didnt_win/ci32gof)

Even if it's not chromatic (I think it is), is it not obvious that the OP
article is designed to garner inbound links/views (and sell books) rather than
provide a balanced picture? Consider the juxtaposition of the deceitful title
and well written content. Do you see what the author did there?

~~~
kbenson
My understanding is that chromatic is not the only person at that company that
knows Perl, not that has had experience with Perl 6 and/or Parrot. I think
it's appropriate to judge the article on it's merits and how well it covers
the issue, not the specific views of people that may be associated with it.

Truth be told, I was thinking while reading it that it sounded quite a bit
like chromatic but with tones down criticism, and said as much to a friend I
fowarded it to. I wrote this "Sounds a lot like chromatic when he was
disillusioned, but not yet bitter. Which is to say harsh, but definitely
constructive." That it's from the company he's involved in doesn't surprise
me. If he wrote it and wants to keep it as aonymous, I think that's perfectly
acceptable. If someone else there wrote it, that wouldn't surprise me either;
I doubt all of his thoughts and opinions happen in a vacuum.

------
alien3d
if ain't php ,think will stick to perl.. first web base language learn..

~~~
alien3d
why down vote,since it my first web base language in 2001. By that time,php is
new and .net is version 1. When i got visual studio dvd,my pc run slow. So i
moved to php and stick till now.

------
vampirechicken
I never understand the apparent glee with which people perform premature post-
mortems on Perl.

You never really see people declaring any other language moribund, and then
kicking it a couple of times for fun.

I don't see the point?

------
spacemanmatt
No language syntax causes me higher cognitive dissonance than perl. I just
find it fugly.

------
pnathan
Another perspective: Perl lost because the culture of internet software
development moved away from hackers who grokked humor and cleverness towards
team-driven business application developers who preferred synergistic
framework solutions.

------
oscargrouch
Whenever i read perl code, i feel somebody is cursing me through the source
code

------
lovelyday
Write once, read never.

~~~
Roboprog
Speak for yourself! (or maybe, for annoying coworkers???)

It's certainly possible to write functions (subs) with comments about what
they do, and use meaningful variable names. The built-in syntax/operators do
require some study, though.

For the "Enterprise!" developer pool, there's Java. The 500 line methods are
still hard to slog through, though. Too many never got the note about a
"business logic layer" and abstraction, and just shove all the details in-
line. In which case, the language of mandate doesn't matter much.

~~~
EdwardDiego
> For the "Enterprise!" developer pool, there's Java. The 500 line methods are
> still hard to slog through, though.

Great straw-man there. I didn't realise that javac required 500 line methods
before compilation.

> In which case, the language of mandate doesn't matter much.

It's a lot easier to pass two collections to a method in Java than to a sub in
Perl.

~~~
Roboprog
\--- Java ---

List <Integer> aList = Arrays.asList( new int [] { 1, 3, 5 }); // probably
missing some more type stuff in <>

Map <String, String> aMap = new HashMap <String, String> ();

aMap.put( "name", "Joe");

aMap.put( "ID", "42"); // I need to check if Java 8 has map literals a la
Groovy...

doSomething( aList, aMap);

...

void doSomething( List <Integer> aList, Map <String, String> aMap) {

System.out.println( "First: " \+ aList.get( 0) + ", Name: " \+ aMap.get(
"name") );

}

\--- Perl ---

&do_something( [ 1, 3, 5 ], { 'name' => 'Joe', 'ID' => '42 });

...

sub do_something {

my( $list_ref, $hash_ref) = @_;

printf "First: %d, Name: %s\n", ${ $list_ref }[ 0 ], ${ $hash_ref }{ 'name' };

}

\------

I'm not seeing _that_ much of a difference in parameter passing, other than
the explicit reference/dereference syntax.

Of course Java doesn't _require_ 500 line methods. But the bondage and
discipline imposed is independent of whether or not readable code will be
produced.

I actually _like_ strongly typed languages for larger programs, but prefer
something more fast and loose for smaller ones. TMTOWTDI!

~~~
EdwardDiego
> List <Integer> aList = Arrays.asList( new int [] { 1, 3, 5 });

You can drop the inner array, asList takes variable number of arguments.

> // I need to check if Java 8 has map literals a la Groovy...

Sadly not, IIRC they've backed off from literals towards a Guava style static
factory methods, which I'm not thrilled about.

> I'm not seeing that much of a difference in parameter passing, other than
> the explicit reference/dereference syntax.

So let's say I'm a newbie Perl developer just exploring subs.

    
    
      sub stuff {
          my ($a, $b) = @_;
          print "$a and $b\n";
      }
    
      my $a = 1;
      my $b = 2;
    
      stuff($a, $b);
    

It works! Hurrah. Feeling clever, I move onto collections.

    
    
      sub stuff {
          my (@a, %b) = @_;
          print "$a[0] and $b{A}\n";
      }
    
      my @a = (1);
      my %b = (A => 2);
    
      stuff(@a, %b);
    

And it doesn't work at all. @a has some additional values, and %b is undef.

So yes, let's use references.

    
    
      sub stuff {
          my ($a, $b) = @_;
          print "${$a}[0] and ${$b}{A}\n";
      }
    
      my @a = (1);
      my %b = (A => 2);
    
      stuff(\@a, \%b);
    

Except now, I have two ways of working with Perl's collections, two separate
sets of sigils, and all because I wanted to pass two collections into a
function and Perl treats function arguments as a collection, and Perl
implicitly flattens collections.

The difference _I_ see, as a Perl newbie only working with it out of
necessity, is that having (because you need it because of earlier design
choices) more than one way of operating on data structures, violates the
principle of least surprise.

~~~
__david__
> Except now, I have two ways of working with Perl's collections, two separate
> sets of sigils, and all because I wanted to pass two collections into a
> function and Perl treats function arguments as a collection, and Perl
> implicitly flattens collections.

It's not really two sets of sigils, it's two concepts: "collection", and
"pointer to collection". I guess coming from C that didn't bother me too
much—once it sunk that references were just (safe) pointers, using them works
almost exactly the same:

    
    
        int a = 1, *b=&a, **c=&b, ***d=&c;
        printf("%d %d %d %d\n", a, *b, **c, ***d);
    
        my $a = 1; my $b=\$a; my $c=\$b; my $d=\$c;
        printf("%d %d %d %d\n", $a, $$b, $$$c, $$$$d);
    

Perl even stole C's pointer syntax to make working with collections nice:

    
    
        my $a = [1,2,3];
        printf("%d\n", $a->[0]);

~~~
EdwardDiego
> it's two concepts: "collection", and "pointer to collection". I guess coming
> from C that didn't bother me too much

Fair point. I guess what bugs me is that you can use collections merrily
without references until you want to pass more than one collection to a
function - or create a collection that isn't flattened - at which point you
have no choice.

------
mantrax5
In one of the WWDC sessions an Apple engineer was adamant one should never
choose terseness over clarity, because every line of code is written once by
one person, but read many times by many people.

And funny enough Objective-C is taking this quite seriously, being a very
verbose language (the new Swift language also keep the verbose method names,
enums and properties).

While Perl is exactly the opposite. There's a reason people jokingly call it a
write-only language.

It has real implication on its usage. You use Perl for one-off scripts you
intend to forget and maybe delete after you run them a few times.

While CPAN happened, I wonder how much Perl was an obstacle in multiple people
joining to work on a single library (versus multiple people just downloading
it and using it, big difference).

~~~
mst
Most of the modern perl ecosystem is libraries built by substantial teams -
it's a lot different now than a decade or so ago.

The Modern Perl dialect is basically what came out of the new wave of CPAN
(Enlightened Perl) movement which is all about using perl's flexibility in a
way that scales to larger teams.

Sadly, every attempt to explain this to people not already writing it results
in a deluge of 'write-only' jokes and nobody bothering to actually look at the
code, so while the technical capacity is there, the pop culture nature of
programming language choice means people generally never realise.

~~~
mantrax5
Perl's brand is damaged. No amount of explaining fixes a broken brand.

The best that can probably be done is to create a new language which is, say,
a clean subset of Perl 6 and call it something new, focusing the message on
how readable and intuitive it is.

------
danbmil99
There are so many snarky things to say, but my mother taught me to never speak
ill of the dead.

