[perlgeek]

> And Perl 6? Fourteen years and nothing to show for it

... except a nearly feature-complete [1] compiler [2] and an impressive test suite [3]

[1] http://perl6.org/compilers/features [2] http://rakudo.org/ [3] https://github.com/perl6/roast/

> and it'll have to be backwards compatible to all the things violently wrong with Perl 5

Not at all. The whole point about Perl 6 is that it breaks backwards compatibility to fix the things that are wrong with Perl 5.

[chrisdone]

> The whole point about Perl 6 is that it breaks backwards compatibility

I think this is is a contributor to why Perl 6 will never amount to anything. That boat has sailed. Python 3 broke backwards compatibility and to my knowledge everybody is still using Python 2. Python has a lot of energy right now, so that might save it, or it might go the way of Perl when the next cool language comes out and everybody jumps ship.

[scrollaway]

Everybody IN ENTERPRISE is still using Python 2. Realistically, most of the Python ecosystem is compatible 2+3, we are seeing new libraries and programs compatible 3.3+-only, and there's no broad reason to use Python 2 anymore, with minor exceptions.

[perlgeek]

> and there's no broad reason to use Python 2 anymore, with minor exceptions.

If you count big chunks of legacy python 2 code a "minor exception", I agree.

Anyway, the big difference between python 2 -> 3 transition and the Perl 5 and Perl 6 coexistence is that nobody within the Perl community tried to end-of-live Perl 5.

Yes, that means less incentives for migrating to Perl 6, but it also reduces the risk for Perl 5 users.

[sp332]

I don't think anyone advocated for converting large legacy codebases 2->3. But 3 should be the "default" for new projects, and only use 2 if they have a reason.

[pyre]

> Python 3 broke backwards compatibility

While this is true, it's possible to write a script that will run on both Python2 and Python3, so long as you have that goal in mind. The breaking of backwards compatibility is the breaking of several APIs and assumptions.

> to my knowledge everybody is still using Python 2

This is mostly because the release of Python 3 didn't see everyone stop everything and immediately start coding in Python 3. Conversion has to bubble up from the major libraries (e.g. Django, Flask, SciPy, etc) first, before people are able to convert.

Also, switching the default Python on Linux distros takes time because you have to go through all of the packages in the package manager looking for Python scripts and make sure that anything pointed at /usr/bin/python will work with Python 3[1].

Another point is that a number of libraries delayed conversion, and didn't consider Python3 to be "stable" until around Python 3.3. Some of other libraries (cough Flask cough) delayed support for a long time because the maintainer just didn't like Python 3.

[1] I know that these aren't always working well though. A while back I found out that Comix (installed via Ubuntu) had "/usr/bin/env python" in the shebang line instead. Launching it from a Virtualenv that doesn't have PyGTK doesn't work so well... :P

[raiph]

One way to look at things is that Perl 6 breaks backwards compatibility with Perl 5. Another is that Perl 6 has well designed language interop and evolution features that make it so easy to nicely use code and libs from other languages that backwards compatibility becomes irrelevant.

The big problem with Perl 6 has been that the implementation has trailed the ambitions of the design. But that's changing due to pieces like Inline::Perl5 falling in to place. (See my comments nearby for more details.)

[kbenson]

Well, not quite irrelevant. Just because language interop is easy doesn't make the fact that there doesn't exist the interop for a library you need. That said, it's also a good chance to get good sane default implementations in first. On of the problems with CPAN is finding the best of the multiple modules available that fit the need.

[raiph]

As I said elsewhere in this thread, Inline::Perl5 hasn't been tested against all 130,000 modules on CPAN to my knowledge, but, based on what I know of the tech and its 100% success rate so far, I'm going to assume until I hear otherwise that it already works, or will do so this year, for the vast majority.

In the unlikely event there's a module that doesn't work, then yes, you have to learn and wield a new language that isn't backwards compatible. But it is Perlish, and it is designed to coexist beautifully with Perl 5.

[kbenson]

Ah, I had heard that Inline::Perl5 worked with (some?) XS modules, but wasn't sure I was remembering correctly, and assumed it didn't. Unfortunately, my ability to keep abreast of new Perl 6 developments has taken a big hit the last six months or so, due to increased workload. :(

[kamaal]

Perl 6 is a new language. Its not a Python like scenario where people are looking to migrate their existing code bases from 2 to 3.

Perl 6 is for new projects. Perl 5 ecosystem continues evolve untouched. Unlike the Python 2 scenario, where 2.x won't be supported and 3.x series and its library ecosystem isn't ready anymore.