Hacker News Reader

Comment by fiddlerwoaroof | Hacker News Reader

The definition of breaking change here completely destroys any idea of abstraction or bug fixes. If calling a function requires knowing how the function is implemented, then the function should not exist in the first place: the whole point of an abstraction is that, if the use-site fulfills the precondition, it can assume that the postcondition holds after it used the abstraction.

This means that relaxing the precondition is, by definition, not a breaking change because the old inputs are a subset of the new ones. Similarly, strengthening the postcondition isn’t a breaking change because the new outputs are a subset of the old ones. (If and he use-site assumes that it gets a specific member of the function’s codomain for specific input values, you have an abstraction leak and the use-site has a bug [or the function should be inlined because it’s a false abstraction])

View on HN

I really wish I had the ability to downvote articles. Agree with you 100%, and I feel like I lost braincells from reading this sentence:

> You are changing the behavior of the function. That is a breaking change.

So this guy is declaring someone else "wrong" because he unilaterally decides to redefine what a "breaking change" means? This is one of the dumbest "all Internet arguments are over semantics" examples I can think of.

As an aside, I've seen a number of recent instances (here's another, https://news.ycombinator.com/item?id=36826111) where a flat out ridiculous blog post makes it to the front page, only for the top comments to all point out how dumb and ridiculous it is. To stay within the HN guidelines, I'm going to refrain from speculating why, and I certainly know that HN audience is not some monolithic group, and that people have many different opinions. Would just like to know if others have noticed this or have other specific examples.

For the record, I'm not the author, nor do I agree with him. But I posted this because there was no comment section and I was curious if anyone would either

1) Agree with the article (virtually no one has) 2) Point out that the breaking changes Rich Hickey pointed out might be worth it, or not a big deal

A few people have responded with sentiments of #2. Not because it's not annoying to change these things, but that it's a smaller price to pay for relatively good type systems (I'm thinking more F# than Haskell)

Unfortunately, the talk Rich Hickey gives explicitly says Clojure spec doesn't have a solution for a flexible type system either, and the solution they proposed is still in alpha 4 years later. So while I appreciate the insights he offered, I'm torn between the problem of refactoring with the extra work of a finicky type system, or the work of hoping my tests are good enough to refactor my Clojure code.

Types in Clojure is the number one requested feature in their surveys, year over year, and despite the reputation he has, Rich recognizes that it can really help refactoring a code base. Good variable names aren't going to help you with this. Pushing Spec2 along would be a big win without having to implement a full blown type system.

My issue is that the author doesn’t seem to know what a breaking change is. Spec itself is annoying to me for a couple reasons, but this isn’t some novel insight of Rich Hickey’s: the claim about relaxing preconditions and strengthening postconditions is in Bertrand Meyer’s _Object Oriented Software Construction_ and is a relatively basic claim in texts about what it means for software to be correct.

Extending a function to accept null, under dynamic typing, can break a program which depends on the documented behavior of that function having thrown an exception for that case.

  (defun strlen (s)
    (assert (stringp s))
    (len s))

  (defun map-len-test ()
    (mapcar (lambda (arg)
              (ignerr (strlen arg)))
            '("abc" nil "defg")))
  

  (pprinl (map-len-test))

  (defun strlen (s)
    (if (null s)
      0
      (len s)))

  (pprinl (map-len-test))

Output:

  (3 nil 4)
  (3 0 4)

The caller had one idea of substituting a value in the null argument case. The function changed behavior, implementing a different idea.

Only in a statically typed language in which the call with nil is impossible, and which provides no dynamic access to the compiler, can we be 100% confident in saying that extending the function to support nil is a non-breaking change.

If the is impossible, then the function has no behavior for that case; a program invoking that case doesn't exist in a translated, executable form and so there is nothing to break as far as the program is concerned.

It's possible for another program to break: a compilation test case which validates that code which calls that function with nil cannot be compiled. If the language supports dynamic access to the compiler, then an application can be written which can behave differently due to the change: an application which dynamically compiles a call to the function and now gets a valid result (compiled code) rather than an error.

In the dynamic world, it's a non-breaking change for applications that wisely don't rely on exceptions being thrown on bad inputs, and instead handle those themselves.

If you're changing the function, you cannot know that is not the case; at beast you can decide not to care.

Not caring is not the same as knowing.

> Extending a function to accept null, under dynamic typing, can break a program which depends on the documented behavior of that function having thrown an exception for that case.

This just means that the preconditions are “the value is not null” even if there are no types to capture that precondition. I was pretty careful not to use the word “type” in the comment you’re replying to.

The problem is that in fact there are no preconditions; the function can be called unconditionally using any value as an argument. It throws for some values, and any change in which ones is a visible change.

Programmers will make code dependent on anything that is visible in an API, even if the specification tells them not to, an ISO standard tells them not to and even if their mother tells them not to.

Here, the spec may even be saying: if you call this function with a non-string, it throws an exception.

> The problem is that in fact there are no preconditions; the function can be called unconditionally using any value as an argument.

There are no _checked_ preconditions. It’s only meaningful to talk about the correctness of a program relative to a specification of its behavior and a specification needs to specify preconditions and postconditions. So, if there are no preconditions, any behavior of the function being called is as correct as any other behavior.

The fact that some programming languages allows the callers of a function to pass values that don’t satisfy the spec is irrelevant to the point I’m making.

The function checks for a type with assert: (assert (stringp arg)). But that check is a documented behavior which generates a predictable exception that the caller can detect and so can tell when that is suddenly missing.

No matter what consequence you give to the failed check, something can break when the check is taken away.

We could have a True(r) Scotsman's checked precondition like this

  (unless (stringp arg)
    (abort)) ;; bail the entire process image with abnormal status

If we check it like that, nobody will try to depend on the behavior within an application, in the way that my test program did.

It can still be a breaking change if the function is written that way, and then changed so the abort is taken away. Because the application can do this:

  (defun my-stupid-abort ()
    (strlen nil)) ;; this calls abort!

So now if the program relies on (my-stupid-abort) to abort, that will break; suddenly that function call returns zero and the process keeps going.

You really need:

  ;; ... ffi definitions here ...
  (unless (stringp arg)
    (acpi-power-off))

But again, dumb program can depend on (strlen nil) to power of the machine, which could be part of some critical system that breaks as a result of it not powering off.

Only a compile time check can do it, by preventing the program from existing. A program that never compiled and therefore was never deployed to its installation will never break.

> So, if there are no preconditions, any behavior of the function being called is as correct as any other behavior.

Umm, no. If the program is supposed to unconditionally produce the output "Hello", but it instead produces "Goodbye", then it is incorrect. Unconditionally means not that there are no preconditions but that the precondition is T (true). If the precondition is constant truth, it means that there are no circumstances under which the program can be excused for not satisfying the postcondition (e.g. producing "Goodbye" rather than "Hello").

Correctness is almost irrelevant here, because the question is about breakage. It is in fact the change in specification which is behind the breakage. The function is correctly implementing its specification at all times; the correctness of my example strlen is never being called into question. What it means for it to be correct has been changed, and the function's definition followed suit.

A breaking change is one that breaks code that uses it correctly. This means that the code that uses it uses it according to its specification. Breaking code that uses your code incorrectly should happen early and often because using code incorrectly is a bug in the using code, not the code being used.

That's just a blame game that is neither here nor there to the user who can't open his ten-year-old word processing document with the latest version.

It makes all the difference in the world for that problem. It’s how you build programs that can be maintained and evolved in a consistent fashion long-term.

I would agree the author was wrong, and I would hazard a guess that you're a lot more well read than most of us on this kinds of stuff, because this talk is widely seen as an insightful.

Is there a language that you feel solves this problem better than Spec could ever hope to?

My first thought was, "I wonder what the author considers a non-breaking change..."

Comments, updating dependencies, or documentation

Updating dependencies could way more easily be a breaking change than what we're discussing... And comments and documentation aren't code changes at all.

Very few people write code whose output purely depends on the choice of types involved. Somebody, somewhere, has to make the choice of placing max/min/wrapping_add/wrapping_sub/wrapping_mul/... in the (u32,u32)->u32 shaped hole in your program, and placing the wrong one is probably a bug. Any caller expecting an arbitrary (u32,u32)->u32 recieving your changes shouldn't break, but not all callers have correct behavior for truly arbitrary functional dependencies.

From the other side, people picked your function in particular not because it fills that type hole but because it does something in particular. If you meaningfully change the thing it does then that probably breaks the callers.

The author's argument is something along the lines of (1) if you're changing the type signature, that's probably because a new implementation requires it, and (2) if the new implementation is sufficiently different to warrant a change in the type signature then it's going to break somebody. I don't particularly like the example since in my experience somebody adding a nullable input will leave the old behavior alone and just wants to call the same function somewhere else, so it probably actually is a non-breaking change for all existing callers, but it's not hard to imagine stronger examples where the author would be right.

To be clear, nothing I said has much to do with types: preconditions and postconditions are a more general notion and types are one way to approximate them in such a way that they can be automatically checked. However, because of the halting problem, there will always be correct programs that cannot be typed.

"Breaking change" means it changes existing behavior. As in I used to get 'banana' when I passed 'b' and now I get 'bicycle'. If I still get 'banana', you didn't break anything.

No, a breaking change is if the interface contract changes in a non-backward compatible way. If the interface contract never promised you to get “banana”, and you still relied on that behavior, then yes your client code may break, but that’s on your side of the program, and your fault for relying on unwarranted assumptions, and not a breaking change in the library you called.

The purpose of interface contracts is exactly to precisely specify what can change and what can’t change without breaking clients, and conversely which assumptions clients can or can’t make. This is a precise give and take. The clients are expected to play by those rules just like the implementations of the interface are expected to maintain their promises — nothing more, nothing less.

This is an academic definition. In a system with dependencies, if you change behavior your dependents relied on, you broke them. If you didn't, you didn't.

In other words, if you break prod, "but we never promised to behave this way" is a poor excuse. When changing something, it's your responsibility to check for breakage, not just throw up your hands and say "not our fault" if it occurs.

E.g. a number of years ago now someone in Glibc development thought it would be fine to change the behavior of memcpy for overlapping objects.

Nobody does that, right? It's undefined behavior.

Downstream distros broke; it had to be backpedaled out.

It sounds like we agree.

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 by a O(n^2)? Breaking if someone complains. Vice versa as well.

Is fixing a bug a breaking change? Yes. Ask Microsoft about porting SimCity that relied on a bug in MS-DOS.

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.

Someone is also sitting on the sidelines, snickering about how primitive the types and function signatures must be for that to happpen.

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?

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://whiley.org/

https://www.idris-lang.org/

https://isabelle.in.tum.de/

https://leanprover.github.io/

https://coq.inria.fr/

http://lamport.azurewebsites.net/tla/tla.html

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.

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.

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/

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.

I agree with you wholeheartedly

Reply on news.ycombinator.com