I find this quite amazing. With refinement types one can say/prove things like:
- This function only returns even numbers.
- The input for this function is not just any vector, it must be an ordered vector.
- It's possible to make compile time unit tests. Where we write a function that exercises the code, and returns True if the test succeeds. Then one adds a refinement type saying that the function must always evaluate to true. The theorem prover does the rest.
 - http://ucsd-progsys.github.io/liquidhaskell-tutorial/02-logi...
That said, it's no small feat to do a correct translation from the semantics of a full, modern, programming language into the semantics of a SMT solver (which appears to be the primary back-end for deciding propositions in this tool). I'll have to go read the actual dissertation to see how far that goes and whether any escape-hatches for user guidance exist (tactics, manual term manipulation, etc.). I haven't yet found a tool that doesn't allow extensive user guidance to be all that effective for proving things about code/systems that are interesting (to me).
The assert function shown in the post is really cool. Amazing how easy it is to define a function that will compile time check an assertion (e.g. something is not "null"). That's code contracts done in the 101 class.
The UCSD Programming Systems lab has also applied refinement types to dynamic languages and systems programming languages. The MIT Computer Assisted Programming Group has similarly used liquid types-based techniques for program synthesis, while a group at Purdue has been working on maching learning of complex refinement types[4,5] that are difficult to state or infer using the liquid types techniques.
I suspect they're a form of confirmation bias, however, because it's not easy to remember that you heard about an idea or term you're unfamiliar with. On the other hand, something you've just recently heard or learned stands out: it reinforces the lesson you've just learned.
This has me down a rabbit-hole because I'm now trying to find the name for a related concept: once you've learned a new idea/model, you start to notice how it applies to everything around you. I find this happening most often with algebraic ideas but the article you linked alludes to the fact that you're liable to notice this effect at play more in the days after reading about it. I want to call it overfitting but that's not quite right.
What really gives me the goose bumps is if you're, say, listening to a recording of a lecture while looking out the window watching a leaf tumble through the wind - and then the professor uses a leaf blowing in the wind analogy. It's not something you do very frequently; watch and listen to two independent events.
Not only does it stand out, at times it seems to appear more frequent. I found out that was called the Baader-Meinhof Phenomenon.
Albeit I am sure this is more comprehensive.
I think because Code Contracts are not utiling any form of Dependent Types (i.e. refinement types), there is only so much that it can statically check/enforce. Refinement Types can go much farther, and their whole utility is in static checks, not runtime checks/unit tests.
Also, Agda is an implementation of Martin-Lof type theory, which is very, very different from what SMT is.