3 ms·

Its almost like fixing compiler bugs means no language is truly ever backwards compatible for long...

• thesuperbigfrog 5y ago
  What you are saying is true in the Hyrum's Law (https://www.hyrumslaw.com/ https://www.hyrumslaw.com/) sense, but should not be true for a mature programming language which maintains backward compatibility. The question then is how does someone define backward compatibility? The answer is a formal definition of what the expected behaviors and expectations of the programming language in question. This usually means a language specification or extensive unit tests that effectively define what the programming language should or should not do for a given set of circumstances.
  • aseipp 5y ago
    Rust already does this, they have extensive testing of new releases via e.g. crater. "Run the new compiler on every public piece of code possible" is actually a very unsurprising strategy these days and communities beyond Rust use this tactic, and this is all on top of the probably ~thousands of unit tests in their suite (not that users go looking at unit tests to decide what's "valid" Rust or not.) As someone who's invested a lot of time in PLT and even at one point had their name on a draft of the Haskell standard, the unfortunate reality is that language specifications are very often not useful to the wide majority of people, while being quite laborious to produce and maintain and work with over time. The culture of computer programming, at large, is part of this, it's not some mathematical fact, but a social one. At the end of the day, what constitutes "Rust the language" in any formal capacity doesn't matter; "Rust the language" is a social construct in that sense, a guarantee Rust will still be Rust even if some minor bugs are fixed that they let slip by. This is how most people think of it, when you get down to the nitty gritty. I'll also say that tons of regressions happen in mature languages with backwards compatibility. Ask any Linux distro maintainer! I don't even keep track of all the weird reasons regressions happen anymore; it's like counting sand on a beach. It's not a happy fact of life, but it is what it is, and regressions do happen, no matter if your language is stable for 5 years or 50.
    • thesuperbigfrog 5y ago
      >> the unfortunate reality is that language specifications are very often not useful to the wide majority of people, while being quite laborious to produce and maintain and work with over time. The culture of computer programming, at large, is part of this, it's not some mathematical fact, but a social one. At the end of the day, what constitutes "Rust the language" in any formal capacity doesn't matter; "Rust the language" is a social construct in that sense, a guarantee Rust will still be Rust even if some minor bugs are fixed that they let slip by. This is how most people think of it, when you get down to the nitty gritty. What you are describing is the less fun and sometimes tedious nature of software maintenance. It can be thankless work, but it is very important work to ensure that a programming language is reliable and to minimize the regressions that sometimes occur. It is very much a social contract, but essential so that expectations are met, particularly for systems programming that Rust targets. I wonder if anyone has ever tried to create a literate programming-style specification for programming languages--something that combines the high-level descriptions of programming language semantics with executable unit tests. Such a system would provide detailed semantics and give programming language creators and maintainers a good way to prevent regressions and create RFC branches to try out and test new ideas. It would help to bring the social constructs of the programming language closer to the technical implementation semantics. The Ada programming language has a specification: http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-TTL.html http://www.ada-auth.org/standards/rm12_w_tc1/html/RM-TTL.htm... and a conformity test suite: http://www.ada-auth.org/acats.html http://www.ada-auth.org/acats.html which ensure that any Ada implementation conforms to what the specification requires. Does anything similar exist for other programming languages? If so which languages have conformity tests or similar? I use Ada professionally and Rust as a hobbyist. Rust is moving very fast and I would like to see it mature for use in safety critical domains. Also, thank you for your work on Haskell.
      • tialaramex 5y ago
        Like Ada, C++ is standardised by ISO. With I suspect much the same consequence, ie there is a big gap between the ambition of the language's most important architects and what they can persuade the committee to sign off on for the standard. It is informative for example to review talks Bjarne gave about C++ Concepts in 2015 compared to the C++ 20 feature Concepts. That's five years to get something similar in scope into the actual language standard, and of course since this isn't exactly what Bjarne designed, you then to have transition compilers and codebases to the actual standard feature... I'm dubious about the value of conformance testing as a deliberate exercise. In practice real world implementations will definitely be defective and it's important that defects are cured when identified, mostly by changing implementations but sometimes in reality by changing the specification to reflect what is implemented. But I don't know how much value I believe there is in somebody sitting down to try to construct a test suite starting from the standards documents, rather than gathering minimal samples of real world code that did not do what the standard says it should do so that implementations can check they get those right (and where appropriate the standards body can reconsider whether the standard itself is wrong here). It appears to me that ACATS tries to do the former, right?