
Why Perl Didn't Win - aiurtourist
http://outspeaking.com/words-of-technology/why-perl-didnt-win.html
======
beat
You know what rocked? Perl 4.

I started on Perl 4 in the mid-1990s. It was fantastic! I started replacing
thousand-line C programs with hundred-line Perl programs that were more robust
and worked better, and replacing shell scripts made of awkward sed/awk
pipelines with neat, tight Perl. Arrays and hashes as first class data
structures? Marvelous!

Then Perl 5 ruined it all. The ridiculous, bloated "object oriented" syntax
rendered it basically unreadable, without adding much useful functionality.
The layers of syntax options forced teamwork-driven Perl (I wrote about 10k
lines of it) to pay close attention to coding standards, closer than more
consistent languages, just to not step on each other or have fights.

Then along came Python and Ruby, which shared most of the benefits of Perl
(scripting, mostly), but added very clean, elegant OO syntax. Everyone who
actually cared about writing decent OO scripts switched. Plus Python had much
better math libs, and Ruby soon had Rails.

And Perl 6? Fourteen years and nothing to show for it, and it'll have to be
backwards compatible to all the things violently wrong with Perl 5. There's no
use case that isn't already covered by Python and Ruby. Unless some new
technology comes along and Perl jumps in firstest with mostest (like Ruby did
with Rails), no one will really care.

The average age of Perl programmers has been increasing by about one year per
year since 2002 or so. I don't see that changing anytime soon.

~~~
_paulc
Absolutely right - Perl 4 had a clear niche (text processing, UNIX system
scripting etc) and did this very well. Perl 5 added so much cruft and ugly
syntax on top of this in an attempt to try to become more 'general purpose'
that it lost its focus. At this point it became easier to switch to Python for
'real' programming.

There are still a lot of problems in the Perl 4 space and to be honest I wish
that distributions shipped with a supported version of 4.036.

~~~
duskwuff
If you seriously think that Perl5 is less suitable for text processing than
Perl4 was, I suspect you haven't actually used the language in a while... it's
still perfectly good for that. Perhaps even better, since 5.8 added extensive
support for Unicode (without requiring explicit conversions and breaking
everything like Python 3 did).

~~~
ptx
From a quick skimming through the docs[0], Perl 5.8's Unicode support sounds a
lot like Python 2's except that the default encoding is latin1 instead of
ASCII - i.e. unlike the Python 3 way of explicitly decoding binary data into
Unicode text at the point where it's read (where presumably the encoding of
the data is known), it will defer the decoding until the data is used (at some
completely unrelated point in the program) and decode it with some assumed
globally agreed upon encoding. Since there is no globally agreed encoding
(Windows even has different legacy encodings between Win32 and the command
prompt!) this will appear to work as long as the data is ASCII but later, when
you least expect it (and someone inputs a non-ASCII string), give
UnicodeDecodeError in Python 2 or garbage data in Perl 5.8.

Ned Batchelder gave an excellent talk[1] that explains how the Python 3
approach to Unicode works. I think it makes a lot more sense once you
understand it; the Python 2 way was clearly broken, and it looks like Perl 5
has the same problem but hides it better.

[0]
[http://search.cpan.org/~jhi/perl-5.8.0/pod/perluniintro.pod](http://search.cpan.org/~jhi/perl-5.8.0/pod/perluniintro.pod)

[1]
[http://m.youtube.com/watch?v=sgHbC6udIqc](http://m.youtube.com/watch?v=sgHbC6udIqc)

~~~
b2gills
Why are you pointing to the unicode entry doc in an ancient version of Perl?

Also according to perlunifaq the minumum version you should be using is 5.8.1
which the documents for 5.8.0 would of course not mention.

Really if you want good unicode handling you should probably use 5.16.0 or
later. If you want the latest version of Unicode there are ways of changing
which version of Unicode Perl is compiled with, but it is easier to just use
the latest version of Perl, which is 5.20.

[http://perldoc.perl.org/perluniintro.html](http://perldoc.perl.org/perluniintro.html)
[http://perldoc.perl.org/perlunitut.html](http://perldoc.perl.org/perlunitut.html)
[http://perldoc.perl.org/perlunifaq.html](http://perldoc.perl.org/perlunifaq.html)
[http://perldoc.perl.org/perlunicode.html](http://perldoc.perl.org/perlunicode.html)

p.s. I noticed in the Python talk you linked that no one knew that the pile of
poo symbol is in there because the japanese characters for luck and poo are
very similar. ( I am unable to find a link to where I first read this ) The
Japanese are also responsible for why we call them emoji (e means image, and
moji means character. ) [http://www.fastcompany.com/3037803/the-oral-history-
of-the-p...](http://www.fastcompany.com/3037803/the-oral-history-of-the-poop-
emoji-or-how-google-brought-poop-to-america)

------
sulam
Speaking as someone who lived through this period during the formative years
of my programming career, the author has completely missed the most
influential language of the time and, in my mind at least, the number reason
why Perl lost.

Yes, I'm talking about Java. It's easy to hate now, but Java back then
replaced all the server-side Perl programming that I did in the space of about
3 years, from 1994 where CGI programming was king to 1995 and the applets
craze to 1999 when I was still regularly having conversations with people
about the benefits of Java vs Perl to 2001 when you were actively hurting your
career by not learning Java (not least because it seemed like the only people
hiring were doing enterprise Java with horrible things like EJB and CMP/BMP).

Why did Java beat Perl? Well, there's a lot to that -- but at least part of it
has to do with that fact that Java was simpler and didn't have nearly as many
tricks up its sleeves (also known as the write-only problem). This is similar
to the argument people today make when picking Go over other options like
Scala. I also don't think it hurt that Java came out of Sun, which on the one
hand was extremely influential because they sold the hardware everyone with
money used, but on the other wasn't influential at all because they were "big
iron" to the web's "why would I buy a Sparcstation when I can just put a PC
under my desk?"

Fundamentally, though, Java was very successful at becoming the language you
wrote code in if you wanted to be taken seriously as a software engineer
building web applications and you didn't already have 5+ years of C++
experience. Perl programmers didn't get the same respect, and so Perl died.

~~~
nemo
There were two sides - PHP was eating a ton of share from Perl for people and
businesses who just wanted to get some simple web thing going. Sun pulled out
the "Java is Enterprise" card early and successfully marketed it as being a
professional scalable web programming solution for enterprise class
applications with a few targeted buzzwords for whatever market segment they
were going for. Perl seemed like it was always looked at as an amateur tool
(much as PHP/ASP generally were), while Java was taken seriously in
"enterprise" spaces (largely due to Sun's success at marketing Java to
businesses).

There's a wrinkle, too. Perl isn't just a web thing. It was (and is) still
used in "enterprise" spaces for scripting on servers. It's still out there
being used to create scripts rather than applications. In that space
Ruby/Python are competing, but there's still plenty of sysadmins who use Perl
since it works.

~~~
pjmlp
> In that space Ruby/Python are competing, but there's still plenty of
> sysadmins who use Perl since it works.

I don't know how it looks now, but if you login into the likes of HP-UX, Aix,
Solaris and so on, usually only Perl is available.

This is what made me learn Perl, back when I was mostly into Python (.com
days).

------
McGlockenshire
This article is pretty much spot on. I lived through this era and experienced
the downfall of perl web applications first hand.

My employer produced an amazingly popular perl-based web application, using
flat files for data storage because so few shared hosts had DBI and DBD::mysql
installed. It's some gloriously horrible code. They did a ground-up rewrite
and then hired me to maintain it, right as PHP was becoming popular.

They refused to do a PHP version until it was too late. Someone else
translated our code into PHP, then rewrote it a few times before releasing it.
Over just a year or two, our marketshare plummeted, and now the UBB is a
distant memory. We couldn't deliver a competing product.

Even if perl hadn't lost the deployability battle, the perl 6 fiasco was what
let python and company eat away at the mindshare that wasn't concerned with
just web applications.

~~~
richardbrevig
I remember the days of the UBB. Flat file databases, what memories. I also
recall UBB getting hacked because the data separator was a pipe bar and the
code didn't check for that on input. SQL injection before SQL. Maybe I dreamt
that. Either way, I remember my time with flat file databases.

~~~
McGlockenshire
Yup, that was pretty bad. The resulting filtering ended up causing a lot of
trouble for folks not using Windows-1252 or something in the ISO-8859 family,
as it'd replace pipes in post bodies with the HTML numeric entity for the pipe
in that charset. A similar incident is one of the things that got me hired - I
was the only one to actually pick up a phone and call their office and talk to
tech support about the sheer size of the possible bug.

The most fun security bug the previous major version had was a side effect of
file naming. In order to prevent users from just downloading data files, every
data file was given the .cgi extension and was always saved as 0777 because
shared hosting sucks and nobody ever used suexec like they should.

The file format for user records is the login name on the first line, and the
plaintext password on the second, email on the third. Someone figured out that
#, ! and / weren't filtered in usernames. See where this is going yet? If the
directory containing member records was available inside the document root,
someone could perform trivial remote command execution.

The second most fun was people discovering XSS before it was called XSS. With
some creative quoting, you could inject javascript into the markup.

I'm just thankful nobody figured out CSRF, I'd have hated to figure out how to
deal with that way back then...

------
pjungwir
I'm curious if anyone really expected Perl 6 to arrive like the article
describes ("The problem wasn't apparent in 2000."). I was just a junior
programmer, and I loved 5.6, but from the beginning 6 sounded to me like it
would be a wholly different language, probably never delivered, and certainly
never adopted. Maybe I'm projecting, but I felt that was a broad sentiment
back then. By 2001 I was writing Python half time or more, and even though I
felt a great fondness for Perl while Python left me cold, it still felt like
it delivered everything Perl 6 aspired to (if you could stand the lack of
regex literals, grr.....). Once Ruby became popular we got all the good things
of Perl without the aridity of Python, so there was even less reason to care.
In the late '00s I took a few years off programming to do a degree in
Classics, and I kept telling myself half-jokingly that if Perl 6 shipped I'd
know I'd been away too long. When Parrot was released I figured I'd better get
back in the game.

That's not to say Perl 6 wasn't needed. Among programming languages Perl was
probably my first love, especially the linguistics tie-ins with $ @ % etc, but
write-only was a real problem, and people were moving to Python on the one
hand and Java on the other. Maybe PHP killed Perl for low-end cheap hosting,
but for larger projects, among people who would never have considered PHP, it
lost because picking it seemed irresponsible.

~~~
CodeWriter23
I started calling it out as vaporware around the Holidays 2001. I would be
shouted down by certain zealots who would tell me code (pre-Alpha quality) was
available for use right now.

At least there are people maintaining Perl 5 at this point.

~~~
ugexe
There are commits to Rakudo, a Perl 6 compiler, every day. It's also scheduled
to be production ready by the end of 2015.

~~~
cturner
You might be right. But I have been reading forum posts to this effect for
fifteen years, and eventually eveyone switches off. Even if you are right,
would you trust your career focus to a software community who had got it this
wrong for that long? I am looking forward to checking out a future perl 6 but
part of that is now duke nukem forever curiosity - what on earth could be in
it that kept those smart people at it for that long?

~~~
pwr22
Hmmm, they've never committed to a deadline or even tried to aim for a
production release before this time, so it may turn out better than you'd
expect

~~~
chromatic
_they 've never committed to a deadline_

Baloney.

~~~
pwr22
Sorry, I didn't know was much as I thought I did

------
BuckRogers
I'd disagree with the assessment of Python3 somehow being sunset in 2020. This
2020 End of Life stuff is a marketing tactic to sell it. There are companies
with 500K line codebases of Python that won't be on Python3 in 2020, if ever.
It's just not feasible when new features have to be shipped. Expect pain (not
for the companies in question, for Python3), in the form of a fork. The book
isn't closed on this one yet.

I can't help but think that we'll eventually be seeing "Why Python3 Didn't
Win". Perl and Python both foolishly abdicated the throne. While shots are
fired, I think Python3 could still recover with more compromises from its
'leadership'.

~~~
pyre
While you may end up being right, Perl6 is a _much_ larger departure from
Perl5 (than Python3 is from Python2). Can one even _use_ CPAN with Perl6? Is
it even possible to convert existing Perl5 CPAN packages to support both
versions at the same time (like all of the PyPI packages that support both
Python2 and Python3)?

~~~
BuckRogers
It is a different departure, and it isn't a 1:1 comparison. That's true.

But Python3 is an obvious failure and no one is admitting it, yet. I've seen
claims from the core dev team about how Python3 is doing well because it has
more downloads from Python.org, which is so stupid I won't even address it. A
comparison of PyPI download statistics says it all.

Python3 migration had many ridiculous ways of pushing people to migrate. The
answer for Python3's adoption was always something new. It reads like the list
of reasons for invading Iraq.

Originally (and today's) overly optimistic EOL for Python2, then automated
code conversion utilities, then porting all the major libraries, then 'six'
type libraries to allow an ugly PythonX middle ground, then adding 3.x-only
new features as a carrot, now the bright idea from the core dev team is to
focus on pushing Python3 as the default install on distros. They all failed.
Python3 as default on most distros won't do anything either.

All that said, and I think this is the best-case scenario: Python3 will
survive and eventually thrive. It will just be a shadow of Python's former
glory.

Is that -really- worth forcing unicode handling? For Zeus' sake, I wouldn't
think so. This coming from someone who agrees with the change in theory.

~~~
bane
> Is that -really- worth forcing unicode handling?

I dunno. I'm new to Python (version 2 so far) and I easily spend 25-50% of my
coding time fighting with ascii/unicode issues in Python. I wish Python 2.x
just did something smarter.

Similar, but not quite as bad, is the need for me to put str() around non-
string values in concatenation. Just f'ing doing it for me. I'll write a bunch
of code, put together a message in a concatenation only to have it blow up at
run-time because of this.

 _sigh_ I really miss Perl's implicit behaviors sometimes.

I dunno, maybe this all is making me a better programmer and person, forcing
me to really deal with Unicode now, and breaking me of lots of Perl bad
habits. But it's really one of the sucky parts of the language.

There's some days, after spending half the day fighting with this issue, that
I almost decide to dump the whole thing and switch to Python 3.

~~~
BuckRogers
The problem is that both support unicode and 2 vs 3 unicode handling are just
two different ways to do it. Which places Python3 firmly in the 'technological
churn' category, rather than true technical innovation.

I'd probably agree 3.x is more Pythonic in this regard, but I think it was an
ill-advised move. Plenty of reasoning in my last response as to why.

Why not go ahead and use Python3, you may find it works for you. For me,
there's a long tail of libraries that don't exist there, and frankly following
the core dev teams' example- we should all act in our own best interests. I'm
far more productive in 2.x.

I may eventually move to 3.x, but it will have to be based on its merits.
Rather than dogma, salesmanship or propaganda. Today it isn't even close to
2.x and we're nearing 7 years since 3.0 was released.

Unlike most things in life such as updating some software package, the "latest
version" of a programming language isn't always in your best interests. I
think this is a hard mental barrier to break down, especially people coming
into Python now.

But I would always recommend learning/using 2.x, not only is it easier to
build cool things with it (the whole point), but you have to learn 2.x. You
can avoid 3 entirely, without any issue whatsoever.

~~~
Retra
Are you using Python 2.X because you are maintaining existing code, or because
Python 3 is just plain unsuitable for what you're trying to do?

I hear a lot of complaints about Python 3, but in my (limited) experience, 3
is better than 2.X in practically every situation I've experienced. But I've
never had to maintain anybody's old code in it, either.

------
p0nce
When I was younger I pushed myself to know Perl 5. I tried to learn Perl with
one book. It was surprinsingly hard. I took a simpler book. I also failed
grasping Perl. Those were the two recommended books for learning.

I've come to realize years after that Perl is simply difficult to learn, lots
of little things to memorize. Its community took pride in language arcana.
Things that are now simple in other languages are unbelievably difficult in
Perl, like "hashes of arrays of hashes" and things like that.

On top of that, it's also difficult to read. No wonder Perl is losing, and to
me the faster the world is cleanup from that, the better.

~~~
Mithaldu
You're incorrect in your realization. The truth is that the older books for
learning perl are simply shitty.

If you read Ovid's Beginning Perl, or chromatic's Modern Perl, you'll find
they managed to explain the concepts very easily.

~~~
not_kurt_godel
No, he's right. Perl is shitty. Have you ever read a random Perl script? It's
impossible to interpret.

~~~
Mithaldu
"No, he's right. Japanese is shitty. Have you ever read a random Japanese
scroll? It's impossible to interpret. Even in romaji!"

------
sago
Rewriting your language, like any other piece of software, is a great way to
lose your market position:
[http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html)

~~~
pjmlp
People forget that if one is forced to re-write the code, it might as well
just use another language.

------
jrochkind1
The "Maintenance and greenfield concerns are very different" section is
relevant to my interests:

> The implications for a programming language are difficult to prove
> conclusively, but simple to explain: an ecosystem focused more on
> maintaining existing projects than creating new projects will be less
> attractive for new projects.

Ruby/Rails provides an interesting example here. The ruby and rails community
ecosystem (the author is right it's about "ecosystem" more than the language)
-- has, in general, done it's best to focus as much as possible on innovation
over stability. That is, has tried to choose focus on creating new projects
over support for existing projects.

Much to the frustration of some in the ruby ecosystem with existing projects
to support.

(Rails, of course, from one perspective _is_ an existing project; from another
is a framework, which has generally over it's history cared more about new
projects that will be created with Rails than existing projects built on Rails
that need to be supported).

Of course, there still _are_ existing projects, and there are still developers
participating in the ecosystem who need to support those existing projects. So
you can only go so far.

What has this done for ruby/rails ecosystem? Hard to say. Overall it's been
successful, but it still can't make the ecosystem as greenfield as a true
greenfield ecosystem, which is perhaps why some are leaving ruby/rails for
greener pastures -- more than any qualities of ruby as a language, it's just
the opportunity to be in a greenfield ecosystem that is attractive, perhaps.

------
kijin
I don't think Perl will ever recover from the Perl 6 fiasco, and I'm worried
for Python for the same reason.

PHP, on the other hand, handled the PHP 6 "failure" relatively gracefully.
There was a bit of stagnation in the days of PHP 5.2 when the devs devoted too
much energy to PHP 6 and not enough on improving the current version. But
soon, PHP 6 was put on hold and some of its better parts began to be ported to
PHP 5. Thanks to this decision, PHP has improved by leaps and bounds since
5.3. Also thanks to the lessons learned, nobody is particularly worried about
any breaking changes in PHP for the foreseeable future. Everyone knows that
any script that works in PHP 5.6 will probably work just fine in 7.0, so new
projects continue to be written in PHP. This peace of mind is very important
for languages that carry a lot of legacy baggage.

If there's anything for other languages to learn from PHP, it would be their
graceful handling of PHP 6 -> 5.3~5.6. The syntax is still terrible, and the
default behavior remains borderline insane, but PHP since 2009 has been an
exemplar of how a widely used scripting language should handle new versions.

~~~
McGlockenshire
> Everyone knows that any script that works in PHP 5.6 will probably work just
> fine in 7.0

This is no longer strictly true. On Friday, the "let's remove all the
deprecated stuff" RFC was passed. Anything that causes an E_DEPRECATED in 5.6
will now be a fatal in 7. For example, ext/ereg and ext/mysql are no longer
included, and have been shipped off to PECL. Shouldn't be a problem for anyone
that doesn't compile their own, really. A few php.ini settings are also now
removed, which will fatal on startup.

It'll be safe to say that if your code runs fine under 5.6 with
error_reporting set to -1, then you'll probably run under 7 without too much
trouble.

~~~
ars
> It'll be safe to say that if your code runs fine under 5.6 with
> error_reporting set to -1, then you'll probably run under 7 without too much
> trouble.

Not completely, ext/mysql does not output E_DEPRECATED. Although I guess
installing a compatibility library is probably not all that much trouble.

~~~
McGlockenshire
Calling mysql_connect will cause an E_DEPRECATED. Same with mysql_pconnect.

Source: the manual page.
[http://php.net/mysql_connect](http://php.net/mysql_connect)

None of the other ext/mysql functions do so.

------
etep
Version number is micro, this is a macro question, to wit, the following:

When I converted a perl script to python and saved 50% LOC I didn't know which
version of which I was using. Am only vaguely aware of the Python 2.x vs. 3
issues. Never was aware of Perl 5 vs. 6.

When Python and Ruby fade, I look forward to the hand wringing about how
version whatever didn't get pushed out fast enough. But that won't be the
reason.

~~~
chrisdone
But you're not a thousand companies who have built their business on Python 2
and have no interest in rewriting working code when they don't have to. Your
"scripts" are pretty much irrelevant.

------
mrbig4545
Define won.

This is the way I see it. Perl5 is still being actively developed, perl6 is
coming along nicely, cpan more awesome than ever, and there's still work for a
perl dev.

If everyone was using the same language, then we'd all suffer because no one
would be getting the new ideas.

Competition keeps things healthy.

------
philwelch
Perl 6 didn't win because the successors to Perl were Python and Ruby, not
Perl 6. Agreed, Perl 6 is a sophisticated language, but Python and Ruby have
mature VMs you can use _today_. For values of "today" ranging back in time
upwards of ten years.

~~~
angersock
Yep. I've heard it put "Ruby is the best of Perl, without the rest of Perl".

------
inDigiNeous
Oh man, I remember hating to program Perl. With Perl, there wasn't just one
way to do things, but there were 10, and all of those involved different
combinations of @{} $[] [#] '%' characters put in seemingly random order and
changing completely the context on which they operated, with the logic only
clear to those who somehow understood the connection between these symbols and
their meaning.

Maybe it didn't win because the language syntax was just a mess, and same
variables just in different contexts could mean like 3 different things
depending on what way you pass them, what you you return them and what kind of
random character is in front of them.

Don't take this personally, just ranting out my feelings for the Perl
programming language, and glad that it isn't one of the things I have to know
anymore! Good riddance!

------
nemo
This was really good. The mix of PHP as a better solution for shared hosting
(and its simplicity for beginners) and the horror story of Perl 6 were both
big setbacks.

Allison Randal wrote on the death of Perl a while back and had some
observations worth nothing to understand how it fell:
[http://allisonrandal.com/2013/03/31/mythbusters-why-i-
still-...](http://allisonrandal.com/2013/03/31/mythbusters-why-i-still-love-
perl/)

I really liked working with Modern Perl, but rarely do anymore mostly since
"nobody uses Perl" kills any suggestion even when it might be the right tool
for the job. Ruby has become Perl 6 for me.

------
jimfuller2014
Perl did win, for a period of time .. expecting an interpreted language to
dominate for multiple decades is unrealistic, especially with hardware
advances that occur over time.

while I don't do anything with it today, I do know Perl/6 would be in
contention for my 'deserted island' language of choice.

yet another dph

~~~
jerf
I have to agree; if Perl didn't "win", then who did?

Python? Very popular. Solid language. Probably at some point more adopted than
Perl, but not so much so that I can say it "won", partially because of how
this list goes on.

Ruby? Same.

PHP? Maybe in the web space but not in general.

Javascript? Even in light of Node, this is still a marginal language out of
the browser, especially considered over the past 15 years.

Lua? No.

Perl may not have "won" but it has hardly "lost", and now IMHO the sun is just
beginning to set on this entire catagory of 1990s-style dynamic scripting
language and there probably will be no further "winner" in this space.

------
tudorconstantin
[probably shameless plug] I first intended to write this as an answer, but I
ended up with a complete blog post:

[http://programming.tudorconstantin.com/2015/01/perl-
already-...](http://programming.tudorconstantin.com/2015/01/perl-already-
won.html)

~~~
chromatic
_Watch out for whoever says that Perl is an ancient technology, because they
're either ignorant and completely clueless about what's really happening in
the world of computer programming, or they have hidden agendas._

That's a strong statement. Are you quite sure those are the only two
possibilities?

~~~
tudorconstantin
There's this Perl book called Modern Perl. It is written to help others learn
about the new technologies available to Perl world. Do you know about the
book? oh, you wrote it :) So yeah, if they don't have hidden agendas and they
say that writing Perl apps means writing apps in an old fashion, the only
possible alternative is to be ignorant :)

~~~
chromatic
_I_ think Perl didn't win. I don't know the specific context of Romania, but
from where I sit, it's unlikely I'll get paid to program in it in the
foreseeable future, if ever.

What's my hidden agenda in agreeing with this article over yours?

~~~
tudorconstantin
The article has valid points. Hidden agenda is when people say that writing
Perl is equivalent to using ancient technologies, solely because Perl had its
popularity peak in the nineties - and this might also be a reason why you
can't be paid for doing Perl - who would want legacy technologies in their
stack?

It's just that, well, it isn't legacy. It's more up to date and much more
robust than many of the hip languages.

------
pyre
It's no wonder there are issues with Perl 5 to 6 transition they went from:

> They're going to merge Perl 5.12 and Perl 6

in "mid-2001" to:

> There's a Perl 5.8 on the way

in 2002. ^_~

That said, I think that anyone doing serious Perl 5.x work has long since
abandoned the idea that Perl 6 has anything to do with Perl 5.x other than
sharing the "Perl" name and Larry Wall. Maybe this is confusing to "outsiders"
and the branding needs to change? It's not like the Perl 5.x line is not being
maintained. Since Perl 5.10, there were some significant improvements, with
consistent point releases coming out.

~~~
bmn_
The branding will not change, for BDFL reasons. The best all we can do is
coming to grips with Perl 6 not being a successor, but a sibling.

------
jjn1056
Not sure what 'winning is'... I've had a great career in Perl so far and every
company I've worked at has been a startup using Perl (not old legacy code). So
that's like almost 20 years and every year someone says, "Perl is dead", etc.
And every year I just have a blast programming Perl. I've met a ton of great
people and I enjoy contributing to open source. So I would say quite
complaining about something you personally don't like and get on with doing
something useful.

------
Walkman
Previous thread:
[https://news.ycombinator.com/item?id=7866834](https://news.ycombinator.com/item?id=7866834)

------
lacker
If there was no Ruby, I suspect Perl would still be popular. At one point the
scripting language holy wars were "Perl vs Python". That turned into "Ruby vs
Python". Similar philosophy, lots of better stuff in Ruby.

~~~
gaius
Online yes - but a hell of a lot of Tcl was being written too, by people who
just couldn't be bothered posting about it.

~~~
biomimic
Tcl was and still is undiscovered gold.

~~~
chrisdone
I'm very glad that only game writers are using Tcl for scripting their games.
It's a godawful language I'd never want to maintain any real software in.
Python and Ruby are bad, but Tcl is a degenerate joke. Let's please leave it
undiscovered.

~~~
razzmataz
That said, the saving grace for Tcl were things like Expect and Tk. I don't
think I ever used it for anything else....

~~~
biomimic
It's being used for AI, ML and data science.

------
riobard
Anyone feeling that Python 3 is gonna do the same to Python as Perl 6 did to
Perl?

~~~
pyre
As someone who has been both a Perl and a Python programmer, I don't feel like
Python3 is going to kill Python. Why?

\- Python3 currently exists, and there is a large push to get the majority of
the "big" packages to support it (many of which _do_ currently support Python
2.x _and_ Python3).

\- It's possible for a Python package to support both Python 2.x and Python3
at the same time or to program the Python 2.x version in such a way that
converters like 2to3 can do the conversion for you. I'm aware of no such tools
_or_ capabilities between Perl 5.x and Perl 6.

\- Python3 isn't as ambitious as Perl 6 is/was.

Edit: As to point #2, I recall that there may have existed (maybe it still
does?) some project to use Perl 6's "reprogram the grammar" capabilities to
turn Perl 6 into Perl 5. I'm not sure how I really feel about that though.
There was also a time when there was some buzz around Parrot VM[1] that was
associated with Perl 6 (I don't know if it was some official partnership or
just some announcement of Perl 6 support in Parrot).

[1] [http://www.parrot.org/](http://www.parrot.org/)

~~~
chhantyal
Indeed, big libraries supporting Python 3 is rapidly growing
[http://py3readiness.org](http://py3readiness.org)

Heck, apart from few - even those which are not supporting Py3k now have
alternative package in PyPi. So it's positive sign.

------
EdSharkey
I think it is cool to think of one's self as the hero in the story of their
life. You battle adversaries, have little victories, complete long story arcs,
find a sweetheart and have romance.

I feel Perl does not deserve to be mentioned in a hero's tale. There's been
too much rankling and nincompoopery out of perl's characters given the size of
that community. Far, FAR too much griping. Perl is a bummer, and that is why
it did not win.

My philosophy is: live the life of a champion - overcome and be a shining
light for others. Your war stories should be mostly glorious victories, no
matter how mundane the battles or battlefields were.

~~~
jnbiche
This is pretty good advice to live by. I should keep this in mind for myself.

~~~
juliangregorian
You're both joking right? I find myself wanting to google this guy in 5 years
so I can see how much real life kicks his poetic ass.

------
jjn1056
and I want to add, I am so looking forward to having this exact conversation
5, 10 and 20 years from now...

------
unlinguaf
nothing to show for perl6? it's shipping in 2015.

