7 ms·

I'm curious what the lesson here is. A lot of the changes in Python 3, such as the byte format of strings, seem to be a good thing--just something that breaks c

by Eyas 12y ago

I'm curious what the lesson here is. A lot of the changes in Python 3, such as the byte format of strings, seem to be a good thing--just something that breaks compatibility. Is the lesson never to bother fixing a major flaw in your software/language after it has been widely used/available?

tormeh 12y ago
Yes, exactly. The bugs have now become features that people depend on, and thou shalt never fix them. It's a horrible lesson, if you ask me.
sqrt17 12y ago
There are two precedents to look at: Java and Perl. Perl grew from merely useful to your-favorite-whiz-bang by being a decent language and growing a large collection of third-party modules. Then Larry Wall decided Perl5 wasn't fun anymore (also because of wart accumulation) and declared Perl6 to be The Future(tm). Years later, we have some remaining stuff that's running in Perl5, and also some enthusiasts that use Rakudo and Parrot in an attempt to reach the Shangri-La of Perl 6. But, in many important respects, Perl is an ex-parrot and Parrot won't change that all that much. Now for Java. Java started out as a slow and ugly cousin of C++ that ran alot slower and gave you the worst of having a bad compiler and a stupid bytecode interpreter. As Java gained traction, Sun and others (e.g. IBM, Apache) proceeded to fix all the warts in a backward-compatible way. Java 1.2 finally had decent collections. Java 1.5 adopted Philip Wadler's proposal for generics through type erasure. Newer Java releases added some sorely-missing utility functions that you'd take for granted in other languages, such as converting between an array and an ArrayList, or splitting a string. Somewhere in-between, we got servlets, JSP, JDBC, Hibernate, JAXB, a fast compiler. It's not so bad, even though the language still bugs me sometimes. What's in store for Python? Similarly to Perl, and differently to Java, Python2 has byte-strings, and just when people where coming to grips that there are some things for which str is a good fit and others where you want to use unicode, you got the "unicode as default" in Python3. A conservative approach would be to extend the language and libraries so that it becomes natural to use unicode objects in the places where you're dealing with text, and keep the functionality that bytestrings have around so that the old code is still working. Python3 did not choose the conservative approach - indeed the goal was to do all the compatibility-breaking things that were needed, upfront. Despite that fact, there is hope that Python will not undergo the Parrot-to-ex-Parrot transition that Perl underwent. The Python core is already there, and many important libraries - including the numpy/Cython etc. toolsuite, and different web frameworks, are actively trying to find the remaining issues. So, as a summary: A lot of the changes in Python 3, such as renaming the old strings into bytestrings and removing a lot of their functionality, are well-intentioned but have considerable problems. It definitely gets harder to fix major flaws in a language that is widely used, and blackmailing the users by declaring the "not as fun" old version of your language dead should not be done lightly if you don't want to become the next Perl.
- chromatic 12y ago
  Perl is an ex-parrot and Parrot won't change that all that much. It's worse than that. Rakudo developers declared Parrot deprecated (in favor of a new VM which had yet to be written). That, of course, drove off all of the Parrot developers--see the decline in commits in March 2011: https://www.ohloh.net/p/parrot/commits/summary https://www.ohloh.net/p/parrot/commits/summary If Rakudo ever reaches a point of stable equilibrium where it's reasonable to think about creating libraries for it, P6 still faces an adoption cycle that's more difficult than that of Python 3. There's no plan for P6 to replace Perl (partly to avoid that adoption pain, for one, and partly because P6 has taken so long, there wouldn't be any Perl users remaining unless P6 had publicly changed its strategy). Python's transition hasn't been quick or easy, but it's gone much, much better than the P6 fiasco.
  - kamaal 12y ago
    I won't comment on Parrot, because I know nothing of Parrot or Perl 6 internals. But from what I hear and read on the internet, the new VM, Moar VM is doing pretty good as a parrot replacement. P6 still faces an adoption cycle that's more difficult than that of Python 3. I don't see how, especially when p5 developers are saying they will continue to support p5 long after p6 is released. And p6 is such a far drift from p5 that you can almost call it a new language. And no one if their right frame of mind will re write all p5 software in p6. So it will be p6 for any new projects and p5 supported all along. There's no plan for P6 to replace Perl (partly to avoid that adoption pain, for one, and partly because P6 has taken so long, there wouldn't be any Perl users remaining unless P6 had publicly changed its strategy). From what I read(Again, I have no personal contributions or sources and I rely on what I read or hear on the internet) in http://jnthn.net/papers/2014-fosdem-perl6-today.pdf http://jnthn.net/papers/2014-fosdem-perl6-today.pdf [pdf] rakudo is very close to spec completeness. And bulk of the effort currently is implementing last bits of spec and improving the speed. Python's transition hasn't been quick or easy, but it's gone much, much better than the P6 fiasco. Python is hardly comparable with Perl 6. They just changed a print statement and iterators in Python 3. Perl 6 is a very different story completely altogether.
    - 12y ago
marcosdumay 12y ago
The lesson I see is that you should always implement a compatibility layer for using the old libs.
dagw 12y ago
I think the lesson is that if you're going to break backwards compatibility, you better offer something really enticing in exchange. Python 2 wasn't so broken that people where clamoring to get off it, and Python 3 wasn't so much of an improvement that people are clamoring to hop on it.

by Eyas 12y ago

tormeh 12y ago

Yes, exactly. The bugs have now become features that people depend on, and thou shalt never fix them. It's a horrible lesson, if you ask me.

sqrt17 12y ago

There are two precedents to look at: Java and Perl. Perl grew from merely useful to your-favorite-whiz-bang by being a decent language and growing a large collection of third-party modules. Then Larry Wall decided Perl5 wasn't fun anymore (also because of wart accumulation) and declared Perl6 to be The Future(tm). Years later, we have some remaining stuff that's running in Perl5, and also some enthusiasts that use Rakudo and Parrot in an attempt to reach the Shangri-La of Perl 6. But, in many important respects, Perl is an ex-parrot and Parrot won't change that all that much. Now for Java. Java started out as a slow and ugly cousin of C++ that ran alot slower and gave you the worst of having a bad compiler and a stupid bytecode interpreter. As Java gained traction, Sun and others (e.g. IBM, Apache) proceeded to fix all the warts in a backward-compatible way. Java 1.2 finally had decent collections. Java 1.5 adopted Philip Wadler's proposal for generics through type erasure. Newer Java releases added some sorely-missing utility functions that you'd take for granted in other languages, such as converting between an array and an ArrayList, or splitting a string. Somewhere in-between, we got servlets, JSP, JDBC, Hibernate, JAXB, a fast compiler. It's not so bad, even though the language still bugs me sometimes. What's in store for Python? Similarly to Perl, and differently to Java, Python2 has byte-strings, and just when people where coming to grips that there are some things for which str is a good fit and others where you want to use unicode, you got the "unicode as default" in Python3. A conservative approach would be to extend the language and libraries so that it becomes natural to use unicode objects in the places where you're dealing with text, and keep the functionality that bytestrings have around so that the old code is still working. Python3 did not choose the conservative approach - indeed the goal was to do all the compatibility-breaking things that were needed, upfront. Despite that fact, there is hope that Python will not undergo the Parrot-to-ex-Parrot transition that Perl underwent. The Python core is already there, and many important libraries - including the numpy/Cython etc. toolsuite, and different web frameworks, are actively trying to find the remaining issues. So, as a summary: A lot of the changes in Python 3, such as renaming the old strings into bytestrings and removing a lot of their functionality, are well-intentioned but have considerable problems. It definitely gets harder to fix major flaws in a language that is widely used, and blackmailing the users by declaring the "not as fun" old version of your language dead should not be done lightly if you don't want to become the next Perl.

chromatic 12y ago
Perl is an ex-parrot and Parrot won't change that all that much. It's worse than that. Rakudo developers declared Parrot deprecated (in favor of a new VM which had yet to be written). That, of course, drove off all of the Parrot developers--see the decline in commits in March 2011: https://www.ohloh.net/p/parrot/commits/summary https://www.ohloh.net/p/parrot/commits/summary If Rakudo ever reaches a point of stable equilibrium where it's reasonable to think about creating libraries for it, P6 still faces an adoption cycle that's more difficult than that of Python 3. There's no plan for P6 to replace Perl (partly to avoid that adoption pain, for one, and partly because P6 has taken so long, there wouldn't be any Perl users remaining unless P6 had publicly changed its strategy). Python's transition hasn't been quick or easy, but it's gone much, much better than the P6 fiasco.
- kamaal 12y ago
  I won't comment on Parrot, because I know nothing of Parrot or Perl 6 internals. But from what I hear and read on the internet, the new VM, Moar VM is doing pretty good as a parrot replacement. P6 still faces an adoption cycle that's more difficult than that of Python 3. I don't see how, especially when p5 developers are saying they will continue to support p5 long after p6 is released. And p6 is such a far drift from p5 that you can almost call it a new language. And no one if their right frame of mind will re write all p5 software in p6. So it will be p6 for any new projects and p5 supported all along. There's no plan for P6 to replace Perl (partly to avoid that adoption pain, for one, and partly because P6 has taken so long, there wouldn't be any Perl users remaining unless P6 had publicly changed its strategy). From what I read(Again, I have no personal contributions or sources and I rely on what I read or hear on the internet) in http://jnthn.net/papers/2014-fosdem-perl6-today.pdf http://jnthn.net/papers/2014-fosdem-perl6-today.pdf [pdf] rakudo is very close to spec completeness. And bulk of the effort currently is implementing last bits of spec and improving the speed. Python's transition hasn't been quick or easy, but it's gone much, much better than the P6 fiasco. Python is hardly comparable with Perl 6. They just changed a print statement and iterators in Python 3. Perl 6 is a very different story completely altogether.
  - 12y ago

marcosdumay 12y ago

The lesson I see is that you should always implement a compatibility layer for using the old libs.

dagw 12y ago

I think the lesson is that if you're going to break backwards compatibility, you better offer something really enticing in exchange. Python 2 wasn't so broken that people where clamoring to get off it, and Python 3 wasn't so much of an improvement that people are clamoring to hop on it.