4 ms·

Meh, breaking backwards compatibility isn't all that bad. It will be a bit rough for a few years, but it's worth it to clean things up for a brighter future.

untog 12y ago
The example of Python 3 is a good one. "A bit rough for a few years" might be an underestimation.
- sdegutis 12y ago
  I don't think Python 3 is a good example. Unlike other cases where languages broke backwards compatibility, the Python community actively discouraged upgrading for years, constantly saying "don't use Python 3" for years, and Python 2 was actively maintained in parallel to Python 3, with features constantly being back-ported. It would have been much smoother overall if they'd just dropped Python 2 altogether, even if a little more painful up-front.
  - pmelendez 12y ago
    I believe he was being sarcastic. And breaking backwards compatibility can be really bad. Imagine if the next version of C would break the previous one. How many operating systems and critical software would have to be rewritten in order to be maintained.
    - cwyers 12y ago
      Python is in a different boat than C++. If the Python language leaders decides to make a version that breaks backwards compatibility... well, they also make the most popular Python interpreter. The group responsible for the C++ standard isn't in the same position at all, they have to convince the different compiler groups (GCC,LLVM,Intel,Microsoft,etc.) to implement it for them.
      - pmelendez 12y ago
        Agreed but even there were a monopoly for the interpreter/compiler you would see people marrying with a specific version and having the implementer to maintain two different branches of the compiler for security reasons.
    - Silhouette 12y ago
      Imagine if the next version of C would break the previous one. How many operating systems and critical software would have to be rewritten in order to be maintained. I don't think the idea is to force existing software to be rewritten. It's to provide a clean break so that new software isn't saddled with the baggage of the old. Over time, most of the older software is retired or replaced, and the industry migrates to use the better tools with more and more projects. This seems a very reasonable strategy, as long as your ABI or equivalent interface specifications can remain compatible for the common subset of functionality, so that programs built using the new language can still use libraries written in the old one. (See also: Every successful general purpose programming language in decades has offered a FFI for C.) It doesn't work so well if you don't have proper formal standards for your old and new languages. It's also much harder to achieve in practice if your code is effectively running on some sort of virtual machine so you can't have that clean break at the ABI level, which might be one reason why several languages have failed to make a convincing big jump in recent years (Perl 6, Python 3, etc.).
ChuckMcM 12y ago
The weird thing is, why not just call it something new? I've always wondered if they called Perl 6 "Smeebly" or something would it get a better reception? C+++ ? My personal taste is that if you break backwards compatibility that is when you have a 'new' language and you just just name it as such.
- deleted 12y ago
  [deleted]
- tshepang 12y ago
  People would, on the surface, see a different beast, even though it remains 99% the same language. Not worth it. With this argument, every release that adds a new keyword (for example) would have to be given a new name, since it will very likely break some code. Question that remains is how much must the changes be before the thing deserves a new name.

untog 12y ago

The example of Python 3 is a good one. "A bit rough for a few years" might be an underestimation.

sdegutis 12y ago
I don't think Python 3 is a good example. Unlike other cases where languages broke backwards compatibility, the Python community actively discouraged upgrading for years, constantly saying "don't use Python 3" for years, and Python 2 was actively maintained in parallel to Python 3, with features constantly being back-ported. It would have been much smoother overall if they'd just dropped Python 2 altogether, even if a little more painful up-front.
- pmelendez 12y ago
  I believe he was being sarcastic. And breaking backwards compatibility can be really bad. Imagine if the next version of C would break the previous one. How many operating systems and critical software would have to be rewritten in order to be maintained.
  - cwyers 12y ago
    Python is in a different boat than C++. If the Python language leaders decides to make a version that breaks backwards compatibility... well, they also make the most popular Python interpreter. The group responsible for the C++ standard isn't in the same position at all, they have to convince the different compiler groups (GCC,LLVM,Intel,Microsoft,etc.) to implement it for them.
    - pmelendez 12y ago
      Agreed but even there were a monopoly for the interpreter/compiler you would see people marrying with a specific version and having the implementer to maintain two different branches of the compiler for security reasons.
  - Silhouette 12y ago
    Imagine if the next version of C would break the previous one. How many operating systems and critical software would have to be rewritten in order to be maintained. I don't think the idea is to force existing software to be rewritten. It's to provide a clean break so that new software isn't saddled with the baggage of the old. Over time, most of the older software is retired or replaced, and the industry migrates to use the better tools with more and more projects. This seems a very reasonable strategy, as long as your ABI or equivalent interface specifications can remain compatible for the common subset of functionality, so that programs built using the new language can still use libraries written in the old one. (See also: Every successful general purpose programming language in decades has offered a FFI for C.) It doesn't work so well if you don't have proper formal standards for your old and new languages. It's also much harder to achieve in practice if your code is effectively running on some sort of virtual machine so you can't have that clean break at the ABI level, which might be one reason why several languages have failed to make a convincing big jump in recent years (Perl 6, Python 3, etc.).

ChuckMcM 12y ago

The weird thing is, why not just call it something new? I've always wondered if they called Perl 6 "Smeebly" or something would it get a better reception? C+++ ? My personal taste is that if you break backwards compatibility that is when you have a 'new' language and you just just name it as such.

deleted 12y ago
[deleted]
tshepang 12y ago
People would, on the surface, see a different beast, even though it remains 99% the same language. Not worth it. With this argument, every release that adds a new keyword (for example) would have to be given a new name, since it will very likely break some code. Question that remains is how much must the changes be before the thing deserves a new name.