3 ms·

Author isn't wrong though. Most accurate and practical definition of a breaking change is - change dependents can't detect and complain. You replace O(n) algo

• djur 3y ago
  You can make a breaking change without changing the type signature ("do_something now uppercases and reverses the input string before using it"), and you can change the type signature without making a breaking change ("do_something now accepts None and treats it equivalently to an empty string"). The author is conflating these two scenarios.
  • actionfromafar 3y ago
    Someone is also sitting on the sidelines, snickering about how primitive the types and function signatures must be for that to happpen.
    • anonymoushn 3y ago
      Do you know of a language that encodes whether a function has the capability to make a reversed uppercased copy of a string in the type of the function?
      • RedNifre 3y ago
        Maybe Idris or Blodwen. Idris can at least define a printf function where the string must contain the right template, i.e. printf("number %i text %s", 5, "hey") compiles, but printf("number %s text %s", 5, "hey") does not, so I'm not sure it's impossible to encode string reversal in the type signature.
        • deredede 3y ago
          You really don't need dependent types to do the printf thing, any language with GADTs or equivalent typing functionality can do it, see for instance OCaml's Printf module. Although you do need a little bit of magic from the compiler to get that exact syntax, which you can get rid of with dependent types.
      • codebje 3y ago
        Dafny and Whiley are two examples with explicit verification support. Idris and other dependently typed languages should all be rich enough to express the required predicate but might not necessarily be able to accept a reasonable implementation as proof. Isabelle, Lean, Coq, and other theorem provers definitely can express the capability but aren't going to churn out much in the way of executable programs; they're more useful to guide an implementation in a more practical functional language but then the proof is separated from the implementation, and you could also use tools like TLA+. https://dafny.org/ https://dafny.org/ https://whiley.org/ https://whiley.org/ https://www.idris-lang.org/ https://www.idris-lang.org/ https://isabelle.in.tum.de/ https://isabelle.in.tum.de/ https://leanprover.github.io/ https://leanprover.github.io/ https://coq.inria.fr/ https://coq.inria.fr/ http://lamport.azurewebsites.net/tla/tla.html http://lamport.azurewebsites.net/tla/tla.html
• kaba0 3y ago
  That’s a definition for observational equivalence, not of breaking change. There would be very little point in doing changes that are completely undetectable. Surely, there is Hyrum’s law and fixing even a bug can be a breaking change, but I believe it is not as black-and-white as in the case of compiler optimizations. For example, the reverse of your aforementioned algorithm from O(n^2) to O(n) is still detectable, but should not cause any harm in any reasonable program. Surely it can break a program full of race conditions that just so happened to work with the former implementation, but it should be similar to how compilers handle UB — if you are in the wrong, then I really can’t save you (at least that is my opinion). Also, relevant xkcd: https://xkcd.com/1172/ https://xkcd.com/1172/
  • Ygg2 3y ago
    Breaking change in practical terms means a change that doesn't break my environment. That's why Microsoft was in a bind. You fixed an issue. Your change obeyed all relevant theoretical stuff, but to a consumer it's a breaking change. But customer sees that going from Win X to Win X+1 broke their stuff and they will harass your support.