1. 15
  1.  

  2. 0

    This is a good step. But, I personally not agree with nowadays languages that most of them do not have backward compatibility.

    1. 7

      I respectfully disagree. I think as advancements are made in languages it’s only natural that you’re going to reach a point where additions or changes will force incompatibilities. It’s a natural, albeit sometimes painful, part of progress.

      1. 7

        Otherwise you get a few billion lines of COBOL powering all the critical stuff. ;)

      2. 3

        What are these languages without backward compatibility? From what I can tell, Go and Rust both seem to maintain backward compatibility pretty well.

        1. 4

          Frankly, python’s backwards compatibility isn’t bad in my opinion. Outside of the python 2 and 3 differences, there isn’t really much to complain about.

          1. 3

            I’m mostly annoyed that one interpreter can’t handle both 2 and 3 code. The changes are small enough this seems totally reasonable.

            1. 1

              In terms of syntax I might agree with you, but under the hood it changed enough that’s it’s acceptable.

          2. 2

            Go and Rust are both very young, and neither has even had a major version increase yet. Combined they have a much smaller installed base than Python and therefore fewer people driving new changes. They’re also tightly controlled by corporations who are likely to take a conservative stance on compatibility.

            Most older languages have had backward compatibility issues. C++, for example, has added keywords, deprecated and removed auto_ptr, made changes to how lambdas behave, etc. Ada made major changes between Ada83, 95, and 2005, which are mostly compatible, but incompatible in some corner cases.

            Nobody likes breaking compatibility, but refusing to do so implies the language is perfect or that the users must live with mistakes forever.