#Finicky sentence full#
#Finicky sentence code#

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. (abort)) bail the entire process image with abnormal status We could have a True(r) Scotsman's checked precondition like this No matter what consequence you give to the failed check, something can break when the check is taken away. 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. The function checks for a type with assert: (assert (stringp arg)). If you're changing the function, you cannot know that is not the case at beast you can decide not to care. 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 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.

#Finicky sentence code#

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

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

#Finicky sentence full#

Pushing Spec2 along would be a big win without having to implement a full blown type system.Įxtending 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. Good variable names aren't going to help you with this. 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.

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. 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. 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) But I posted this because there was no comment section and I was curious if anyone would eitherġ) Agree with the article (virtually no one has)Ģ) Point out that the breaking changes Rich Hickey pointed out might be worth it, or not a big dealĪ few people have responded with sentiments of #2. For the record, I'm not the author, nor do I agree with him.