
Three Tales of Second System Syndrome - cygx
http://blog.brentlaabs.com/2015/05/three-tales-of-second-system-syndrome.html
======
ceronman

        It just might be possible that Perl 6's crazy long development process can
        produce the best-adopted second system around
    

Unfortunately, I don't share the same optimism as the OP. In the real world,
adoption is not only driven by how cool a language is, but the ecosystem of
tools and developers around it. There are lots of Perl 5 codebases which won't
be migrated because it's too expensive.

The true lesson learned for language developers is: Don't break backwards
compatibility. Ever.

The Python community made this mistake, and they acknowledge it. Guido said
this won't happen again. But at least for the case of Python 3, the number of
breakages is relatively small, and the migration from 2 to 3 while tedious,
it's not that hard. Even so, the migration of the whole ecosystem has been
really really slow. But I think in the end the community will move.

The Perl case, on the other side, is much worse. Migrating a relatively
complex project from 5 to 6 is extraordinarily hard. It's probably the same as
a whole rewrite. Also, the community is divided, with some developers keeping
the improvement of Perl 5, fixing bugs and adding new features. There is no
incentive for migration.

If the migration has been so slow for Python 3, which had a much smaller
barrier, I don't see how it could be better for Perl 6.

New languages are able to develop a new ecosystem when they introduce
innovative features, e.g. Rust. But Perl 6 while being a nice language,
doesn't seem to have any killer feature compared to mainstream languages.

~~~
amyjess
The more I think about it, the more I realize that Perl 6 was misnamed. It
should have been treated as a new language with some Perl heritage, not just a
new version of Perl.

The Perl 5 diehards aren't going to switch, and people who aren't already Perl
hackers are going to think it's the same old Perl that scared them off ages
ago.

It's a shame, because Perl 6 is a great language (and I say this as somebody
who was put off by Perl 5), and the Parrot VM is particularly awesome.

It also has some of the best error reporting I've seen: it offers a number of
possible solutions, and if you try to use a Perl 5-ism that's not supported
anymore, it'll tell you what the Perl 6 equivalent is.

~~~
gahahaha
> Perl 6 was misnamed

Damian Conway agrees with you - but Larry Wall decides, and he insisted on
calling it Perl 6. Maybe Conway has a point, but maybe so many people wouldn't
have worked so hard on it for so long if it was called something else.

------
choult
I think the author is mischaracterizing all of these examples; none of them
are "second systems" but major revisions of software with large install bases
and no built-in update mechanism. They are reliant on distributions and third
parties to provide any form of automatic update; oftentimes the upgrade path
without distribution-level support is painful for an average user.

Certainly, in the case of PHP, it was a very painful process to get major
adoption of 5 - especially as so many of the users are reliant on managed
hosting. It took a long time for the install base to grow there; PHP 7 will
similarly take a long time to get up there. At least the decision to scrap 6
(a decision also taken in light of all of the literature out there describing
the features of 6) was a pragmatic one; PHP 7 is now just around the corner.

What the author is describing are two general problems for any software
development where there is a large install-base: development cycles and
release management. Just look at uptake numbers for operating systems for an
example as to why this is absolutely not a problem confined to scripting
languages or even OSS software:
[http://en.wikipedia.org/wiki/Usage_share_of_operating_system...](http://en.wikipedia.org/wiki/Usage_share_of_operating_systems)

~~~
castell
The transition from PHP3 to PHP4 and from PHP4 to PHP5 wasn't that painful. At
the time, most PHP open source projects simply avoided OO concepts due to
their slow implementation in PHP4 and to be downwards compatible with PHP3. It
solved the transition as they only slowly adopted class based OO later in PHP5
era. Also the transition period of parallel version of PHP4 and 5 was between
2004 and 2008 - long enough so that most shared hosters were able to make the
switch. PHP6 failed, and most planned features were backported to PHP5.3+. As
several books were published in the months before the planned PHP6 release,
the next PHP version will be named PHP7 to avoid any confusion. Nevertheless,
PHP7 isn't a bigger change than let's say PHP 5.2 to 5.3. Overall I would say,
PHP's developers and the community has done a great job. Modern PHP.net and
HHVM are certainly better than their reputation. The same goes for MySQL and
MariaDB.

~~~
Bahamut
If anything, my takeaway here is that PHP might have handled things the best
of the three. PHP doesn't have the huge schism that Python 3 does, and the
development cycle isn't nearly as crazy as Perl. Sometimes pragmatism is more
important than idealism.

~~~
juliangregorian
We don't know that, because PHP 7 isn't out yet, but also PHP 7 doesn't change
in breaking ways. All of the language warts that plagued 4 and 5 are still
around.

------
TazeTSchnitzel
> Well, after a little over six years of development, we discovered that we
> were never going to see a PHP 6 at all. Having seen how long Perl 6 had
> taken, and how long PHP 6 was taking, the number 6 is associated with
> failure. So they cancelled PHP 6 and voted to change the name to PHP 7.

Uh, what? Did the author do the most _basic_ of research?

PHP 6 was a real thing, a development branch. But it dragged on for years.

Due to delays, they made an interim release in the 5.x series, PHP 5.3. It
backported some stuff from 6.

Eventually, PHP 6 was killed off because it just wasn't going to work. So they
made another 5.x release, PHP 5.4, backporting more stuff from 6, and adding
some other features.

After that, with PHP 6 dead and gone, work focussed on the PHP 5.x series
again. So out came PHP 5.5 (2013) and PHP 5.6 (2014).

During this time, some people did some experiments and realised it was
possible, by breaking internal (not userland) compatibility, to greatly
improve PHP's performance. This project became phpng. Since it would break so
many (internal) things, they decided that if it should be merged into PHP, it
needed to go into a new major version.

It was after this that the ridiculous version number vote was held. I don't
see why we ever had that debate, really. PHP 6 was a thing and was killed off,
re-using the version number was silly. Anyway, the number chosen was PHP 7.

Fast forward to the present day: PHP 7 has gone into feature freeze and should
be released in a few months. Alongside the performance improvements of phpng,
it has some other new features developed independently, and includes a few
deliberate backwards-compatibility breaks.

tl;dr: the time line goes: 5.2 release, work begins on 6.0, 5.3 release, 6.0
killed off, 5.4 release, 5.5 release, 5.6 release, 7.0 in development.

Edit:

> JIT to the Zend engine

...what? No, PHP 7 does not have that.

> Asynchronous IO and functions

...PHP 7 doesn't have that either?

> Standalone Multi-threading Web Server (HHVM)

...huh?

> phpclasses.org

Oh, so that's why the author is so confused.

~~~
McGlockenshire
> Oh, so that's why the author is so confused.

So for anyone wondering about this, phpclasses was the answer to PEAR, which
itself was trying and failing to be CPAN. PEAR ended up being laughable and
underwhelming, while phpclasses ended up being a breeding ground for _some of
the worst PHP code on the planet_.

Nobody should be using it and anyone pointing to anything on it as a good
example should be laughed at.

Meanwhile, the article author probably needs to read this slide deck from the
PHP6 team explaining exactly where the breakdown occurred:

[http://www.slideshare.net/andreizm/the-good-the-bad-and-
the-...](http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-
what-happened-to-unicode-and-php-6)

The postmortem starts on slide 60, but the rest is worth reading.

It had nothing to do with second system syndrome at all.

~~~
serve_yay
Sounds like a disaster. Also funny how anyone discussing PHP's flaws gets met
with "oh THERE'S your problem, you decided to use this terrible awful piece of
shit thing instead of not doing that". Well why in the hell was that an option
in the first place?!

The golf course is full of landmines, and if you bitch about how shitty it is
to step on one, nobody goes "yeah it sucks how this course is full of
landmines", you're just an idiot because you stepped on one, like an idiot.

~~~
stephenr
So you're suggesting that the PHP community at large, is somehow responsible
for a single site, that gives bad advice, has bad information, etc.

What exactly is your solution? a SWAT raid to take down this travesty of
technology?

------
forgottenacc56
There's nothing that will convince the Python 3 haters. So silly. I use
nothing but Python 3 and I rarely if ever find I can't move ahead for lack of
a library. The Python2 only libraries are just being replaced with more up to
date alternatives. This article is total FUD and garbage from yet another
Python 2 ideological holdout dogmatist.

This article would have you believe that if you tried to use Python 3 that
within hours you would hit a library roadblock that would be a showstopper.
Completely wrong, and you have to ask why the author wants to create this
perception.

Python 3 works beautifully and is a pleasure to program.

If you WANT to hate Python 3 then you'll find no lack of ways to hate on it
for the next 20 years (HEY! I found some package built by a fellow Python2
holdout! See, it simply is not possible to write the code to upgrade it!
PYTHON 3 IS FINISHED! THE SKY IS FALLING!) etc etc ...

If you want to succeed with Python 3 then that's easily done, you just get on
with it.

No one using Python 3? Flat out lie. Prove me wrong by scientifically
explaining your assertion that no one uses Python 3. Lies, spoken to back the
wishes of the Python2 holdouts to sabotage Python 3 - they hate Python 3 and
will say any lie to bring it down and spread the FUD. I'm wrong? Prove it in
detail with science. Alternatively make vague, handwavey statements about
downloads, as though that defines how many people are writing code today with
a language.

~~~
aidos
I've found exactly the same thing.

As someone writing applications using Python 3, I found the switch to be easy
and I haven't had any problems with libraries. I've switched from some of the
old ones I was using to more modern alternatives that are being actively
developed.

It annoys me that there are people on Python 2 that haven't really tried to
make the switch and stand on the sideline shouting insults at Python 3. It's a
tremendously self destructive thing to do for all involved.

To anyone looking to get started with Python, there's no real reason to start
with Python 2 these days.

~~~
SudoAlex
Libraries are a problem - it's difficult to switch unless _all_ your
dependencies are Python 3 compatible. The only ways to fix it are to either
use an alternative, or perhaps to fork or contribute patches to the project -
both of which take up valuable time when your code is still functional under
2.7.

I'm currently creating 2.7/3.3+ compatible code in whatever I create, but I'm
still deploying to 2.7 hosts. For most of my projects this is due to just one
package which has some Python 3 related bugs, so hopefully I can just flick
the switch soon and use 3.4.

It's only easy when your project depends on a few popular packages (eg. the
top 200 where 86% are currently Python 3 compatible [1]), it's much more
difficult if you've got a long list of dependencies.

[1] [https://python3wos.appspot.com/](https://python3wos.appspot.com/)

~~~
mpdehaan2
Yep, for me, distributions are the biggest thing holding things back right
now, because the existing ones are out there, and will be deployed for a long
time.

If deploying a .com website, you can control your dependencies completely, and
it's much easier than if you are deploying a system that must interact with
existing systems the user/customer might have (for instance, management or
monitoring apps).

Thankfully that's not a huuuge class of systems, but it's what I typically
work with :)

~~~
aidos
I suspect most people don't have to deal with that issue (fortunately, because
that must _suck_ ). Is there not some way of wrapping the entire binary with
your distribution? If I was working in that space I think I'd probably choose
a different language, if possible.

As you say, it's not a problem for most of us as we get to dictate the
platform.

------
allendoerfer
I have my problems with the Python 3 implementation. Unicode is great, but
standard library APIs should understand each other without the need to call
decode.

I like the way the change was rolled out, though:

1\. Find a defined amount of cruft that needs to be fixed backwards
incompatibly, so you do not take 15 years for it or fail completely. Release a
new major version.

2\. Make one or two minor releases to the older version to ease the upgrade.

3\. Then STOP developing the older version, work with the community and
perfect the new version to get everyone on board.

I think it is the perfect middle ground. If you do this constantly you will
not have the need to change everything at once and will also not amass cruft.

The problem with the justification of the author for 15 years of Perl 6
development is, that Perl 6 will have issues, too. Are you going to change
them all at once again and take another 15 years for Perl 7?

~~~
masklinn
> Unicode is great, but standard library APIs should understand each other
> without the need to call decode.

If one "standard library API" generates integers and an other consumes
strings, would you expect the second one to take the output of the first one
without conversion?

~~~
allendoerfer
No, I would not. To stay with your problematic analogy that differently
encoded strings are to each other what integers are to strings:

Would you write a function, that takes either a string or an integer and
returns therefor either a string or an integer, so you can not feed the output
of this first function into a second function, that is often called after the
first, but can only take integers?

Or would you rather say "Okay, we are working with numbers here, lets just
take and return integers in this module."?

You can read more about this here:

[http://lucumr.pocoo.org/2014/1/5/unicode-
in-2-and-3/](http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/)

------
tokai
This post made me move to Python 3. I replaced all print statements, in the
code I am currently working on, with print functions, and yum-installed
python3 versions of the libraries.

The code ran correctly on first try. Guess I was lucky, should have made the
shift earlier!

~~~
a3n
Does your code use division, and do you have unit tests for at least those
parts? Because the same code will compile and run in either version, but
you'll get different results, depending.

~~~
tokai
Thanks for the heads up. Fortunately I was aware of the kinks with division,
so it caused no trouble.

------
jsn
This is ridiculous. The author makes it sound like perl6 is more of a success
than python3 -- despite python3 being used for real projects for years now,
and perl6 being "slow and about to have its first release" (just like it was
for the last, I don't know, 7 years?). I mean, come on.

~~~
sundarurfriend
IMHO, the practical best-case scenario for Perl 6 at this point is a Lisp-like
status where the language itself does not see much commercial use, but ideas
from it fuel innovative attempts in existing and new languages. That would be
the best-case though, and it might just bomb and be forgotten within months,
which in fact seems to be the common expectation from many.

In any case, this was one of the most unabashedly biased articles I've seen on
HN, with badly made attempts at revisionistic history. Perl is still my
favourite scripting language, but even I have to admit that Perl 6 has little
hope of adoption, and Perl 5 is dying a slow and painful death: due to the
momentum, clarity and leadership and P6 took away from it. A few ported-back
features gained can't possibly make up for the lack of a cohesive vision that
resulted from nobody being sure of the status of the Perl 5 language.
Subroutine arguments have long languished in interminable bikeshedding due to
this (despite actually having a few enthusiastic implementors - a rare
phenomenon in P5 world now!), and we have embarrassments like autoderef and
smartmatch[1] which reduce people's trust in the language even more.

What makes the situation truly infuriating though, is the snarky and superior
attitudes taken by most P6 folk, just like this article exhibits. Even if you
begin with an attitude of collaboration, it soon begins to feel like you're
talking to King Joffrey, with that ever-condescending smile of his.

[1]
[http://www.perlmonks.org/?node_id=961344](http://www.perlmonks.org/?node_id=961344)

~~~
kbenson
> it might just bomb and be forgotten within months

That seems unlikely for any project with over a decade of work behind it.

> What makes the situation truly infuriating though, is the snarky and
> superior attitudes taken by most P6 folk, just like this article exhibits.
> Even if you begin with an attitude of collaboration, it soon begins to feel
> like you're talking to King Joffrey, with that ever-condescending smile of
> his.

Do you have any examples, because I've dropped in their IRC channel
occasionally over the years, and it's been nothing but welcoming. The attitude
at YAPC (at least in 2013 when I went) was very positive from everyone I
heard, from both P5 and P6.

------
RVuRnvbM2e
So what is different about the Ruby approach to language evolution? The
community has moved forward relatively painlessly from 1.8.x to 1.9.x to 2.x,
all of which had breaking changes. Why has change been such an issue for e.g.
Python?

~~~
kbutler
I think it's largely because ruby use is dominated by a single, pure ruby
application domain: rails. Once rails supports the new version, it's easy to
move. google "ruby programming" 3.5M hits and "ruby programming rails" 1.6M
hits.

In contrast, python has many different application domains, each with their
own dependencies that need to be updated, and native code extensions are much
more common. "python programming" 38M hits, no single application is a
significant percentage.

~~~
jeltz
We are not a rails shop but moving to 1.9 was almost entirely painless. I
think that is because Ruby never did any release which broke everything. 1.9
did not break that much.

------
peteretep
I wonder if Typescript will serve as a lesson to us all. It feels like the
next generation of JavaScript, and (can) compile to ES(really old) without
adding too much ugly Dart-like cruft.

Another interesting subject only slightly touched on here has been the degree
to which Perl 6 features have been slowly rolled in to Perl 5; maybe Perl 5.30
will look a great deal like Perl 6.

~~~
castell
Typescript may serve as another showcase for Microsoft tactics to influence
and steer a language (JavaScript/ES6 & 7).
[http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish](http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish)
You know the Java vs. MS Java (later transformed to C#) - both MS Java/J++ and
C# as well as Typescript were guided by Anders Hejlsberg (former Turbo Pascal
fame).

~~~
Shamanmuni
I try to be as cautious as any free software loving programmer when it comes
to Microsoft, but it's hard to see how they could get away with that strategy
in TypeScript's case. The code uses the Apache License 2.0 (FSF approved, OSI
approved and compatible with GPL v3) and it's been on github for a year with
lots of forks.

You don't need to depend on anything from Microsoft for development, I've
toyed with TypeScript using Node.js and Eclipse on Linux without issues. And
as stated before TypeScript compiles directly to Javascript and they are
trying to align their syntax with ES6.

Seems quite kosher. I think at this point if Microsoft tried something shady a
community fork is very doable, or if it doesn't happen you can always compile
to plain JS and continue working there.

It's really different from the situation you describe because developers and
users won't tolerate a MS JS that only works with MS browsers, they have to
remain compatible with the others or risk irrelevance.

------
punch_card
I can run Fortran IV code on a modern compiler without change. 2015-1966=48
years. And counting. Ada95 was a very easy transition from Ada83. Pay
attention to users ! Backwards compatibility is MANDATORY for a language.

~~~
thraxil
Well, that explains why Fortran and Ada are such wildly popular languages
today!

~~~
amyjess
In their communities, they are.

Parts of the scientific community still insist on Fortran, and the DOD still
loves Ada.

------
nercury
Please consider the time it takes for a new language to be fully developed and
to take hold. These major revisions are simply new languages, because they
_break backward compatibility_.

Except, um... PHP.

~~~
mathgenius
Yes, and in the mean time: Go, Rust, Dart, Julia... maybe someone someday will
get the sweet spot of performant code that is just plain fun to write. I guess
that was the idea with PyPy, but after 15 (?) years that goal is still a ways
away.

------
TheLoneWolfling
With regard to Python 3's print statement, I don't understand it. Or rather, I
don't understand why they changed only the print statement. If nothing else,
raise and assert should have had the same treatment.

And Python 3's unicode handling isn't sane. Or rather, it is saner internally,
but not sane on the interface. I mean, recreating `cat` is bad enough. Python
3 made unicode handling slightly easier and byte handling gratuitously harder.

But this is probably bikeshedding.

Personally, the bigger problem is not creating a relatively frictionless
upgrade path. If you can't run things on the new version without manual
editing, you won't move over unless everything you depends on moves over.
Catch-22. Python is slowly moving over, largely because a) it's not generally
too difficult to port the code (and largely automated to boot), and b) you can
relatively easily write code that works on both versions.

------
recurve28
My main problem with Perl 6 is that it seems overly large and complex. It is
very different from Perl 5, there is effectively no up to date tutorial, and
I'm overwhelmed by Perl 6's apparent complexity.

~~~
Ovid
Perl 6 isn't as complex as people make it out to be. I have friends who are
race car enthusiasts who could go in to _excruciating_ detail about cars and
if you don't know how to drive, it could seem daunting. The reality is that
most of us get in to our car and just drive.

That's part of the issue with Perl 6: its proponents get very excited about it
and write about all the really cool stuff you can do with it, but for those
who don't know the language, it sounds intimidating.

Here's a talk I gave at FOSDEM explaining how day-to-day Perl 6 is fairly
straightforward and easier than people think:
[https://www.youtube.com/watch?v=lpu-3UF_b48](https://www.youtube.com/watch?v=lpu-3UF_b48)

~~~
recurve28
> The reality is that most of us get in to our car and just drive.

I don't mean that the internals appear complicated (I wouldn't know anyway), I
mean just learning it as a user appears that way.

> That's part of the issue with Perl 6: its proponents get very excited about
> it and write about all the really cool stuff you can do with it, but for
> those who don't know the language, it sounds intimidating.

Yes. But it's not just that; trying to read the Synopses is daunting. It's
very easy to get stuck there, try for a while on IRC, then give up.

> Here's a talk I gave at FOSDEM ...

Thanks for the link, and for the talk.

~~~
raiph
The Synopses are intended for compiler writers.

The writing intended for users is at
[http://doc.perl6.org](http://doc.perl6.org).

~~~
recurve28
Unfortunately, even the docs at doc.perl6.org give me the impression that
either the language is extremely complicated, or that the docs leave out too
many essential details, or both. I don't wish to pick apart docs here though.

I think that what Perl 6 needs if it is to have a chance to succeed is a
really good comprehensive and comprehensible tutorial.

~~~
raiph
Right. Imo Perl 6 ought to be fairly easy to learn -- the basics are simpler
than Perl 5 for example -- but several parts, of which doc is one, are still
weak enough that this simplicity is currently obscured.

If you're interested, I'd be willing to try to personally tutor you (for free
of course). I'm raiphmellor at gmail if you want a private email exchange.

------
PebblesHD
Perl, Python, and PHP: or why PHP just sucks because I can't figure out its
benefits and Python 3 sucks because change and Perl sucks because Perl. Every
language solves some problems well and some not so well. Why does everyone
(figuratively) bash other languages simply because they aren't quite right for
your particular use case??

~~~
a3n
Because we're instinctively tribal. See: friends don't let friends drive
Fords.

------
a3n
This was a fascinating article to me, a python2 user.

I suspect there are three large subsets of readers, where the process
described for "their" language is familiar, and those for the other two
languages sound like tales of "inside baseball."

I am familiar with the progress and arguments related to python2/3\. I am
aware, from a distance, of similar issues with perl5/6 and php5/6/7.

It occurs to me that I haven't heard about similar breaking shifts for other
currently active languages, including C and C++. I'm dimly aware that Java
recently moved to 8(?) and 9(?) is starting(?). And I wonder about Fortran,
which I'm dimly aware still has active users and some standards process.

Can anyone who is familiar with these languages' progress characterize them as
breaking and angst-ridden, or smooth and relatively trouble free, and say why?
What's different about the process and community from the three languages in
the article?

For a possible initial point of contrast, my impression of the three
languages' changes are that they are all but new languages that are easy to
read for anyone familiar with previous versions.

~~~
lbarrow
C, C++ and Java generally don't break backwards compatibility in new language
versions (or at least not as much as other languages), so upgrading to the
next version is usually easier.

------
k__
Sometimes I have the feeling that Scala is the "Second System" of Java. But it
wasn't designed by the same people who did Java.

~~~
_pmf_
Scala is Java done even wronger; C# is Java done right.

~~~
amyjess
I would argue that Groovy is Scala done right.

~~~
justthistime_
I guess that's why they just lost their commercial sponsors recently.

~~~
amyjess
Popularity != quality.

Or would you argue that Honey Boo Boo was the best show on television?

~~~
vorg
> I would argue that Groovy is Scala done right

The creator of Groovy, James Strachan, said 6 yrs afterwards that if he'd
known about Scala at the time, he'd never have created Groovy, so he's arguing
the exact opposite viewpoint.

> Popularity != quality

The recent blog by Jochen Theodorou, the tech talent that practically built
and maintained Groovy for 10 yrs, at
[http://blackdragsview.blogspot.com/2015/04/about-being-
paid-...](http://blackdragsview.blogspot.com/2015/04/about-being-paid-oss-
developer-for.html) says about Groovy's quality...

> G2One management adding feature after feature without testing or
> documentation

...and identifies that G2One (SpringSource, Pivotal) management as...

> all of the paid Groovy guys... Cedric (developer), Guillaume (manager and
> evangelist) and me (developer) had to leave Pivotal

Groovy has two use cases:

* scripting Java (tests, Gradle scripts)

* providing a M.O.P. for Grails

If you want to actually build a system on the JVM or Android, use Java or
Scala or some language created specifically for that purpose. Groovy was built
as a dynamically typed language, with static typing features shunted on much
later, and hardly anyone uses them. Groovy's for quick and dirty scripts, like
those 30-line Gradle build scripts (unless you need readable stack traces then
you're out of luck).

------
upofadown
I think that Brooks' Second System Syndrome assumes that there is actually a
compelling reason for the second system. A language is more subtle in that the
value there is mostly in the convention of how to do things. In any case where
you make a big change to a language there are always going to be people who
either don't agree with the change or simply don't think the change is worth
the bother.

There are zillions of proposals for new languages around at any particular
moment in time. Very few ever become popular. If you significantly change a
currently popular language then there is a good chance that you will fall off
the side into unpopularity.

------
yellowapple
Except Perl 6 isn't a "Second System", but rather a "Third System"; Perl 4
(for whatever god-forsaken reason) is to this day still mentioned in the Perl
documentation in various places, despite being about 2 1/2 decades old and
having been effectively abandoned in favor of Perl 5 for nearly as long. Perl
4 and Perl 5 are pretty much entirely different languages, and Perl 6 is just
an extension of that heritage.

The 5->6 transition might be more painful because of how long Perl 5 has been
around and in active use, but this isn't exactly new to a whole lot of veteran
Perl programmers.

------
collyw
What does Java do differently that it doesn't seem to have adoption problems?

~~~
Macha
90% of Java 1 code works on Java 8.

There are still enterprise apps stuck on Java 4, 5 and 6.

~~~
lucian1900
More importantly, bytecode produced by old Java compilers still runs on new
VMs.

I believe that if Python 3 had been able to call into Python 2 modules (even
by embedding CPython2) adoption would've been better.

~~~
Alphasite_
I think byte code compatibility is gone now, its supports the current and
previous versions only.

------
makeitsuckless
Unfortunately, most of this post is just content-free snark, pissing on
certain (phases of) languages with no effort whatsoever to provide any insight
beyond the author's prejudice.

Apparently the "gratuitous negativity" guideline doesn't apply to content.

Edit: And let's not forget that 99% of the criticism levelled at those
languages has nothing at all to do with Second System Syndrome. That very
valid subject is apparently just an excuse to go on a rant.

~~~
mst
He's attempting a general comparison, concluding that each language took a
different gamble and he looks forward to seeing how it turns out for all
three.

He doesn't piss on anybody. Honestly, to me your comment is more "gratuitous
negativity" than the blog post is.

------
lugus35
Too sad to see so many efforts on Python 3 although nobody is using it...

~~~
chx
One data point: the smartcard library
[https://pypi.python.org/pypi/pyscard](https://pypi.python.org/pypi/pyscard)
is still not Python 3 compatible. Six and a half years and counting.

~~~
gnud

        Downloads (All Versions):
        0 downloads in the last day
        0 downloads in the last week
        0 downloads in the last month

~~~
taspeotis
That's what I saw, plus the description mentions Windows 2000, but if you go
to the SourceForge page:

    
    
        206 Downloads (This Week)
        Last Update: 2014-12-13

------
laichzeit0
I imagine this would be a similar problem if C++ tried to get rid of all the
crap that's been layered onto it over the last decade.

------
epimenov
MySQL also started version 6.0 and then stopped developing it. They also tried
to fix the unicode support (utf8mb4 by default).

