----- Original Message -----
From: "Julian Leviston" <[email protected]>
To: "Fundamentals of New Computing" <[email protected]>
Sent: Sunday, October 10, 2010 10:21 AM
Subject: [fonc] Spec-Driven & Self-Testing Code
<--
Does anyone know about a language (possibly something in smalltalk) that
involves spec-driven development?
A language that stipulates a spec (in code - ie a test) must be written
before any code can be written, and that can also do self-checks (sort of
like a checksum) before the code is executed?
Julian.
-->
possibly relevant questions:
what would be the merit of imposing such a restriction?
how would one enforce such a restriction?
how could this be done without compromising the ability to use the language
to get much useful done?
...
IMO, any such restrictions are better left under the control of "the
development process" rather than trying to enforce them at the language
level.
this sounds sort of like:
http://en.wikipedia.org/wiki/Big_Design_Up_Front
or:
http://en.wikipedia.org/wiki/Waterfall_model
although this could also be intended:
http://en.wikipedia.org/wiki/Test-driven_development
design and testing is typically a sensible and important part of the
process, however:
usually, design, implementation, and testing are interlaced to some extent
(it is unlikely that any staged model apart from BDUF could be successfully
applied on a larger scale).
there is no good way to formally enforce these (in the toolchain), given the
widly varied nature of design, possible tests, and implementation
strategies. there are only a minority of cases where fully automated tests
can be used and produce sensible results (for many sorts of testing, some
level of human involvement is needed, such as reviewing input/output for
"sensibility", as in many non-trivial cases the behavior may be beyond what
can be both completely and accurately handled by an automated test, or
require multiple stages to become testable but in the process introduce
internal "hidden layers" which may themselves conceal various edge cases or
problems).
in effect, likely pulling off such a requirement in the general case would
likely require homunculi, and short of that, developers would likely just
end up short-circuiting the mechanism anyways for all the cases where it
would (inevitably) prove inconvinient or unworkable, and thus solving little
of value.
static provability is also another possible (and generally more workable)
strategy, however, this tends to focus on far more narrowly defined and
testable properties (such as verifying that all types are used correctly,
...).
however, "programmer has written a spec before starting implementation" is
outside the grounds of what can be achieved via a proof (nor is even
necessarily proven to always be the most desirable course of action).
or such...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
