51–60 of 138 posts
I like the idea of attaching tests to the function itself - oftentimes I'm finding myself combing through the unit tests for various components to understand the expectations around how they are meant to be used (especially when they are not documented well enough), I feel this approach could help in this aspect (and also with adding new test cases that could have been missed).
> # this is true > ((1 / 3) * 3) == 1 This is a slippery slope. Early versions of Dart tried to use rational numbers by default, but then it was cancelled because denominator size can grow exponentially. Also, I seriously doubt you can make a language that will correctly resolve checks like this one: sin(pi / 6) == 1 / 2
https://www.wolframalpha.com/input/?i=sin%28pi+%2F+6%29+%3D%...
o = Object.new
def o.my_method(x)
self.y + x
end
def o.y
10
end
o.my_method(5) == 15 # true
method_as_fun = o.my_method
# Wrong number of arguments, 0 for 1
Which should make the error message obvious. Ruby makes this syntax optional for readability purposes, which becomes obvious once you start going through real world ruby code.
I built a library for doing modular runtime verification in Python (https://github.com/mwshinn/paranoidscientist) and evaluated it for scientific software. In the end, it was pretty effective, but not perfect, and there are some major changes I would make if I were to do this again. One problem was that some of the most important cases to check were important because they were difficult to check. (E.g. some function arguments change the meaning other arguments - this is extremely common in major frameworks like numpy/scipy.) By contrast, the flashiest feature in my package was runtime checking of hyperproperties (i.e. checking properties like monotonicity or concavity that depend on relationships between multiple executions of the function), but this was rarely used in practice.
The two most common criticisms I hear about runtime checking are (a) it is just an assert statement under the hood, and (b) the performance hit is unacceptable and the only solution is static checks. Regarding (a), sure, they may reduce to assert statements, but most idioms in programming also "reduce to something under the hood". The question is whether dynamically-checked (refinement) types/predicates are a useful abstraction, and in my experience, yes they are. Regarding (b), you probably don't want to use runtime checks on software intended to be run primarily by people other than the developers. But many classes of problems, software is written as a means of discovery rather than as a tool for someone else to accomplish a particular task. For these problems, runtime checks and static checks are approximately equally useful. Static checks are nice to avoid because they can get you into deep water really quickly, so their scope can be quite limited. Also, people tend to overestimate the performance penalty of dynamic checks. Even complex checks often incur no more than a 10% performance penalty.
The same in other languages: function, func, fun, fn, etc.
I like the idea of attaching tests to the function itself - oftentimes I'm finding myself combing through the unit tests for various components to understand the expectations around how they are meant to be used (especially when they are not documented well enough), I feel this approach could help in this aspect (and also with adding new test cases that could have been missed).
And in python you can use doctests (tests inside de docstrings of functions)
> # this is true > ((1 / 3) * 3) == 1 This is a slippery slope. Early versions of Dart tried to use rational numbers by default, but then it was cancelled because denominator size can grow exponentially. Also, I seriously doubt you can make a language that will correctly resolve checks like this one: sin(pi / 6) == 1 / 2
With every Mandelbrot iteration* the integers doubled in size, producing exponential complexity. With 100 iterations this essentially means that the program never completes and even runs out of memory at some point.
The newbie-friendly feature turned out to be not so friendly.
* complex z_{n+1} = z_n^2 + c
I love this. I think people often underestimate the value of dynamic runtime checks. For certain applications, e.g. many types of scientific/exploratory software, dynamic checks and static checkcs have nearly identical utility. But static checks can get really tricky to work with as a developer. I built a library for doing modular runtime verification in Python ( https://github.com/mwshinn/paranoidscientist ) and eva…
Regarding hyper-properties: I assume they only work on immutable data values, otherwise it would be hard to manage historical objects so that they can be part of any of the predicates.
I'm working on a similar project that you may find interesting: https://odipar.github.io/manikin/. I may want to include hyper-properties in future releases.
edit: found this on hyperproperties: https://lamport.azurewebsites.net/pubs/hyper2.pdf
> # this is true > ((1 / 3) * 3) == 1 This is a slippery slope. Early versions of Dart tried to use rational numbers by default, but then it was cancelled because denominator size can grow exponentially. Also, I seriously doubt you can make a language that will correctly resolve checks like this one: sin(pi / 6) == 1 / 2
The Wolfram language successfully resolves it: https://www.wolframalpha.com/input/?i=sin%28pi+%2F+6%29+%3D%...
Earlier quoted context omitted.
And in python you can use doctests (tests inside de docstrings of functions)
That's also pretty nice, although elevating those tests to be first-class-citizens makes more sense to me. My approach is that "code is truth, despite what the comment says", and docstrings feel too much like comments, but I haven't used Python professionally that much so I just may not be used to those.