7 ms·

Common are they suppose to support python 1? Every languages has breaking change at some point. People needs to move on.

• userbinator 6y ago
  How common is Python 1.x? Was 2.x backwards-compatible with 1.x? I don't know, but my suspicion is that it was.
  • uranusjr 6y ago
    It was not, although they are indeed considerably less different from 2 to 3 and easier to migrate.
• Blikkentrekker 6y ago
  > Every languages has breaking change at some point. This is where you are quite wrong. Many languages and other software projects take backwards compatibility quite seriously. Backwards compatibility is far more interesting to many clientele than the quality of the language itself. — the idea that one would have to rewrite one's codebase again later with all the potential regressions that that might lead to is not an appealing prospect. Planes would crash if the software that ran airports would have to do this.
  • pjmlp 6y ago
    They do, but you are yet to find one example in the mainstream languages that never did at least one breaking change.
    • tgv 6y ago
      Is Go mainstream enough? They haven't made any breaking changes so far. Which brings me to another point: not all breaking changes are equal. Sometimes, a change to a syntactic element is needed. But if there's an identical replacement for it, and it can be updated mechanically, there shouldn't be a problem (in theory). Making constructions or the standard library do things (subtly) differently without a fall-back to the original functionality is a much bigger problem: then you have to inspect every occurrence and verify if it still works under all conditions.
      • pjmlp 6y ago
        Wait for it, https://blog.golang.org/path-security https://blog.golang.org/path-security
        • ainar-g 6y ago
          That's a change in a library though, not in the language. And if you want to never have changes in libraries, including for fixing security bugs, you'll end up with stuff like mysql_real_escape_string.
          • pjmlp 6y ago
            I guess you missed to read the comment I replied to. "Making constructions or the standard library do things (subtly) differently without a fall-back to the original functionality is a much bigger problem: then you have to inspect every occurrence and verify if it still works under all conditions. "
    • userbinator 6y ago
      I believe latest GCC/MSVC/Clang will still do C89 (which is still in common use, precisely because of its widespread portability) and even K&R.
      • pjmlp 6y ago
        That is specific implementations, we are talking about languages, and in regards to C there are definitely a collection of breaking changes across ISO revisions. Even minor ones aren't so minor, if the code happens to rely on them all over the place.
    • Blikkentrekker 6y ago
      Perhaps of minor things that nobody actually used or to fix soundness issues. What Python did is far beyond that; — it knowingly broke what everyone was using with the full knowledge that almost no Python 2 codebase could run under 3 unmodified.
• CJefferson 6y ago
  Gcc will, still run c89, c++98 and even fortran66 code. There has never been any suggestion support for these older versions be removed. Packaging Python 2 & 3 together, like gcc, would have had another big advantage -- it would have meant early on I could assume everyone had Pythkn 3. There are still, plenty of macs with 2 but not 3 by default.
  • user5994461 6y ago
    Well, there hasn't been a C standard after c89 so it's hard to move forward. In theory there is a c99 standard but it was never adopted by MSVC so good luck with that (that is a long story on its own). On the C++ side, C++ didn't get more spec until C++11 (2011), then it took a decade to be supported by compilers. Imagine how long it takes to roll out a language/library change when compilers themselves are on a 3+ years release schedule. Either way, the C++ world is heavy on proprietary extensions and tools. There is little care about standards. The standard itself is hard to consider a standard, all it does is suggest tens of new features -some of which are impossible to implement- that may be added one by one over the decade.
    • whizzter 6y ago
      Hmm, is there any other major blocker in modern MSVC (that supports C11) other than variable size local arrays to be considered C99 compatible? (Designated initializer fields came into C++20 so they were forced to put that in). Blocking var-sized arrays might've been a blessing in disguise from a security standpoint.
      • user5994461 6y ago
        Variables can only be declared at the beginning of a block in C89. In my opinion that's the main difference between strict C89 and C99. MSVC is very strict about that and there's no workaround to allow it.
        • whizzter 6y ago
          That's not really a compiler limitation though (since in C++ mode it will happily handle it) but rather a validation/mode thing. Since they now support C11, I'm sure that part is removed if you select C11 mode?