3 ms·

> 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 bo

> 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 12y ago
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 12y ago
  > 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 12y ago
    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.
raiph 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
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.
pyre 12y ago
> 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

scrollaway 12y ago

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 12y ago
> 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 12y ago
  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.

raiph 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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 12y ago

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.

pyre 12y ago

> 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