[plt-scheme] Re: to define, or to let

Bill Richter wrote:
> I thought the opposite of static is run-time.  And I certainly would
> only think you can detect order of evaluation problems at run-time.

Sure, but that's not a particularly harsh restriction. Much of my day
job involves checking the correctness of programs at runtime. Most
sources I've seen recommend a 50% allocation of development resources to
runtime testing. And it's even possible to instrument Scheme code so
that you can test it with more than one order of evaluation, making it
much easier to flush out sequencing bugs.

> But I bet MF would say just that, and it sounds reasonable: "My
> interpreter isn't gonna let people assert things that my interpreter
> (static or no) can't enforce."

That doesn't make sense: The interpreter is just one tool for testing
correctness, and it's not even the most important tool. "It compiles and
runs" is a very weak verification criterion. See /The Art of Software
Testing/ and /Test Process Improvement/ for a full treatment of the
subject.

Code annotation makes it easier to write testing tools, like Anton's
BrBackwards. The interpreter alone may not be able to enforce all
assertions, but that's only a problem if you think of the interpreter as
the sole testing tool (and if you do, you've got much bigger problems).

> MF is really really interested in good programming practices.

So am I. That's why I recommend explicit annotation for sequential
requirements. /Code Complete/ recommends it, /The Laws of Software
Process/ (which discusses software as a medium for knowledge delivery)
suggests that it's important to take advantage of this ability to encode
knowledge, and BrBackwards shows that the annotations are useful for
software testing.
-- 
Bradd W. Szonye
http://www.szonye.com/bradd