I’m confused: you say that transparency and verification are the same thing, but your examples only seem to support that transparency enables verification. Is that closer to what you were trying to say?
Type signatures in a strongly typed language can be seen as a method of ensuring that the compiler proves that certain errors cannot occur, while also giving a human reading the program a better sense of what various functions do.
Yes! A programming language does this by restricting the set of programs that you can write, disallowing both correct and incorrect programs in the process. It has to, because it’s infeasible (uncomputable, to be precise) to tell whether a program will actually hit “certain errors”. For example, suppose that searchForCounterexampleToRiemannHypothesis() will run forever if the Riemann Hypothesis is true, and return true if it finds a counterexample. (This is a function you could write, I think.) Then if the Riemann Hypothesis is true, this program:
if (searchForCounterexampleToRiemannHypothesis()) {
"string" / "stringy" // type error
}
is a perfectly fine infinite loop that never attempts to divide “string” by “stringy”. Nevertheless, a (static) type system will overzealously disallow this perfectly dandy program because it can’t tell any better.
So type systems weaken the language. While that example was concocted, there are more realistic examples where you have to go out of your way to satisfy the conservative type checker. But, to your point (and against my point in the beginning), they weaken the language by requiring type annotations that make the language easier for the type checker to reason about (verification), and also easier for people to understand (transparency). There is a tradeoff between verification&transparency and expressiveness.
[Y]ou say that transparency and verification are the same thing
It’s important to me to note that I only claimed that they are “sort of the same”.
[Y]our examples only seem to support that transparency enables verification. Is that closer to what you were trying to say?
No, but you’ve picked up a weakness in my exposition (or rather something that I just forgot to say). Verification also enables transparency: by verifying a large number of properties of a system, one provides a ‘view’ for a user to understand the system, just as a transparency method can itself be thought of as verifying some properties of a system: for example, sharing the source code of a binary verifies that that source code compiles into the given binary, and that the binary when executed will use such and such memory (if the source code is written in a language that makes that explicit), etc. As such, one can think of both verification and transparency as providing artefacts that prove certain properties of systems, although they ‘prove’ these properties in somewhat different ways.
There is a tradeoff between verification&transparency and expressiveness.
Indeed, an important point—although in many cases, this is a plus, since sometimes precisely the thing you want to do is to make it impossible to create certain malformed systems (e.g. type systems that ensure that you never attempt to divide one string by another). As such, these methods work better when one has good reasons to rule out the class of objects that cannot be transparified/verified by them.
I’m confused: you say that transparency and verification are the same thing, but your examples only seem to support that transparency enables verification. Is that closer to what you were trying to say?
Yes! A programming language does this by restricting the set of programs that you can write, disallowing both correct and incorrect programs in the process. It has to, because it’s infeasible (uncomputable, to be precise) to tell whether a program will actually hit “certain errors”. For example, suppose that
searchForCounterexampleToRiemannHypothesis()will run forever if the Riemann Hypothesis is true, and returntrueif it finds a counterexample. (This is a function you could write, I think.) Then if the Riemann Hypothesis is true, this program:is a perfectly fine infinite loop that never attempts to divide “string” by “stringy”. Nevertheless, a (static) type system will overzealously disallow this perfectly dandy program because it can’t tell any better.
So type systems weaken the language. While that example was concocted, there are more realistic examples where you have to go out of your way to satisfy the conservative type checker. But, to your point (and against my point in the beginning), they weaken the language by requiring type annotations that make the language easier for the type checker to reason about (verification), and also easier for people to understand (transparency). There is a tradeoff between verification&transparency and expressiveness.
It’s important to me to note that I only claimed that they are “sort of the same”.
No, but you’ve picked up a weakness in my exposition (or rather something that I just forgot to say). Verification also enables transparency: by verifying a large number of properties of a system, one provides a ‘view’ for a user to understand the system, just as a transparency method can itself be thought of as verifying some properties of a system: for example, sharing the source code of a binary verifies that that source code compiles into the given binary, and that the binary when executed will use such and such memory (if the source code is written in a language that makes that explicit), etc. As such, one can think of both verification and transparency as providing artefacts that prove certain properties of systems, although they ‘prove’ these properties in somewhat different ways.
Indeed, an important point—although in many cases, this is a plus, since sometimes precisely the thing you want to do is to make it impossible to create certain malformed systems (e.g. type systems that ensure that you never attempt to divide one string by another). As such, these methods work better when one has good reasons to rule out the class of objects that cannot be transparified/verified by them.