6 ms·

> I don't know if HN can find any counter-examples, of a language that thrived through an incompatible, code-breaking upgrade. Ruby qualifies, I'd say. From 1.

> I don't know if HN can find any counter-examples, of a language that thrived through an incompatible, code-breaking upgrade. Ruby qualifies, I'd say. From 1.8 -> 1.9 there were syntax changes, changes to how strings worked and so on. Code written for 1.8 would not in general work on 1.9 and the other way around. While it was possible (sometimes with some extra if statements) to write code that worked on both versions I would definitely call it an incompatible, code-breaking upgrade.

saurik 9y ago
The fact that it was possible to write code that worked with both wasn't just so critical, though. It allowed you to upgrade your code incrementally to support 1.9 while doing regression testing on 1.8, and then come up with a deprecation schedule for 1.8.
- rplnt 9y ago
  Python could be written that way (2/3-compatible) as well and plenty of programs and modules were.
  - saurik 9y ago
    Uhhhh... sort of? I mean, I could go through all of the needless "why the hell did they make this partner incompatible also" stuff like, like removing u'' support (thai was added later), or all of the ludicrous breakage in the underlying APIs (like filesystem calls that made assumptions about character encoding that make no sense for the underlying Unix model and literally caused files to just disappear from iteration)... a lot of this stuff was fixed in later versions of Python 3, but that was years later, making it nearly impossible to deal with the existing land mines of people who had installed Python 3.0-3 (or even 3.4). But what makes me shocked that you think that that is the case is basic basic stuff... I mean, as one obvious example, they changed the exception syntax. So, "uhhhh.... sure?" it was possible to make a program that ran on both 2 and 3, but it required using "try" with no variable assignment and then digging into Python's exception reflection support to recover the variable. And you had to do this every single time. (And of course a lot of the time the underlying core library would now throw different exceptions, making the situation all the more ludicrous.) I had code that straddles the 1.8/1.9 boundary of Ruby, and even though I wasn't an expert at Ruby it was trivial to have code that worked for both (and I mean 100% correct: Unicode and everything; remember that neither Ruby 1.9 nor Python 3 added Unicode support, they only made Unicode support easier to obtain. for Python 2 there was already comprehensive, if non-default, support, and for Ruby 1.8 you just needed to be careful about where you did conversions).
    - icebraining 9y ago
      it was possible to make a program that ran on both 2 and 3, but it required using "try" with no variable assignment and then digging into Python's exception reflection support to recover the variable. What? The PEP that added the new syntax also added it to Python 2.6: https://www.python.org/dev/peps/pep-3110/#compatibility https://www.python.org/dev/peps/pep-3110/#compatibility
    - sametmax 9y ago
      Half of the problem you mention are either: - if you tried to support Python < 2.7. - if you tried to support Python < 3.3 But nobody used 3.0, 1 or 2. And supporting 2.6 is like supporting ruby 1.7 and 1.8 and 1.9. Which nobody did. And it's easy to rewrite libs when really the language started to be used in 2004. Or maybe not, given that "gem install" still regularly crashes on anything other than the top 20 packages, so it's still not a solved issue.
      - opencl 9y ago
        Python 3.0 came out in 2008 and 3.3 came out in 2012. Are you really saying that nobody used Python3 for the first 4 years of its existence? I was certainly using 3.1 and 3.2 back then.
        sametmax 9y ago
        Pretty much yes. Some Linux distrib where still using 2.6, and not a lot of them had even 3.2 in their packages. Only a few like you and me tried it. I can't recall of any big project or lib ever supporting < 3.3.
        UncleEntity 9y ago
        Blender was using py3k for quite a while before 3.3. I was doing blender dev work back then and can recall the almost immediate upgrades as soon as the newest python release came out -- kind of painful really since I prefered to use the fedora installed version instead of building from scratch so would often stall my dev work until fedora caught up to blender. They jumped on so early the python devs were saying "WTF are you people thinking?!?"
Freaky 9y ago
It's notable that 1.9 came with a significant performance boost, so there was a good practical reason to want to upgrade. People were motivated by the prospect of their code running twice as fast - sure, the language was improved a bit too, but it's Ruby, it's already pretty nice, so that was hardly going to light a fire under anyone. When Python 3 turned up and it was on average slower, my first thought was "well, good luck getting people to adopt that".

saurik 9y ago

The fact that it was possible to write code that worked with both wasn't just so critical, though. It allowed you to upgrade your code incrementally to support 1.9 while doing regression testing on 1.8, and then come up with a deprecation schedule for 1.8.

rplnt 9y ago
Python could be written that way (2/3-compatible) as well and plenty of programs and modules were.
- saurik 9y ago
  Uhhhh... sort of? I mean, I could go through all of the needless "why the hell did they make this partner incompatible also" stuff like, like removing u'' support (thai was added later), or all of the ludicrous breakage in the underlying APIs (like filesystem calls that made assumptions about character encoding that make no sense for the underlying Unix model and literally caused files to just disappear from iteration)... a lot of this stuff was fixed in later versions of Python 3, but that was years later, making it nearly impossible to deal with the existing land mines of people who had installed Python 3.0-3 (or even 3.4). But what makes me shocked that you think that that is the case is basic basic stuff... I mean, as one obvious example, they changed the exception syntax. So, "uhhhh.... sure?" it was possible to make a program that ran on both 2 and 3, but it required using "try" with no variable assignment and then digging into Python's exception reflection support to recover the variable. And you had to do this every single time. (And of course a lot of the time the underlying core library would now throw different exceptions, making the situation all the more ludicrous.) I had code that straddles the 1.8/1.9 boundary of Ruby, and even though I wasn't an expert at Ruby it was trivial to have code that worked for both (and I mean 100% correct: Unicode and everything; remember that neither Ruby 1.9 nor Python 3 added Unicode support, they only made Unicode support easier to obtain. for Python 2 there was already comprehensive, if non-default, support, and for Ruby 1.8 you just needed to be careful about where you did conversions).
  - icebraining 9y ago
    it was possible to make a program that ran on both 2 and 3, but it required using "try" with no variable assignment and then digging into Python's exception reflection support to recover the variable. What? The PEP that added the new syntax also added it to Python 2.6: https://www.python.org/dev/peps/pep-3110/#compatibility https://www.python.org/dev/peps/pep-3110/#compatibility
  - sametmax 9y ago
    Half of the problem you mention are either: - if you tried to support Python < 2.7. - if you tried to support Python < 3.3 But nobody used 3.0, 1 or 2. And supporting 2.6 is like supporting ruby 1.7 and 1.8 and 1.9. Which nobody did. And it's easy to rewrite libs when really the language started to be used in 2004. Or maybe not, given that "gem install" still regularly crashes on anything other than the top 20 packages, so it's still not a solved issue.
    - opencl 9y ago
      Python 3.0 came out in 2008 and 3.3 came out in 2012. Are you really saying that nobody used Python3 for the first 4 years of its existence? I was certainly using 3.1 and 3.2 back then.
      - sametmax 9y ago
        Pretty much yes. Some Linux distrib where still using 2.6, and not a lot of them had even 3.2 in their packages. Only a few like you and me tried it. I can't recall of any big project or lib ever supporting < 3.3.
        UncleEntity 9y ago
        Blender was using py3k for quite a while before 3.3. I was doing blender dev work back then and can recall the almost immediate upgrades as soon as the newest python release came out -- kind of painful really since I prefered to use the fedora installed version instead of building from scratch so would often stall my dev work until fedora caught up to blender. They jumped on so early the python devs were saying "WTF are you people thinking?!?"

Freaky 9y ago

It's notable that 1.9 came with a significant performance boost, so there was a good practical reason to want to upgrade. People were motivated by the prospect of their code running twice as fast - sure, the language was improved a bit too, but it's Ruby, it's already pretty nice, so that was hardly going to light a fire under anyone. When Python 3 turned up and it was on average slower, my first thought was "well, good luck getting people to adopt that".