4 ms·

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

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 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.

Capricorn2481 3y ago
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.
- fiddlerwoaroof 3y ago
  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.
  - Capricorn2481 3y ago
    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?
    - deleted 3y ago
      [deleted]
  - kazinator 3y ago
    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.

Capricorn2481 3y ago

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.

fiddlerwoaroof 3y ago
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.
- Capricorn2481 3y ago
  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?
  - deleted 3y ago
    [deleted]
- kazinator 3y ago
  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.