On 12/31/12 10:30 AM, Paul Homer wrote:
Now I know that sounds weird, but not if one accepts that a clunky,
ugly language like COBOL was actually very successful. Lots of stuff
was written, much of it still running. Its own excessive verbosity
helps in making it fixable by a broader group of people.
For the waterfall approach used by designers behind COBOL
implementations, the philsophy of "measure twice; cut once" is
consistent with a formal approach. But if there are so many bugs that
last for decades, and bugs that can just be fixed by superficial
analysis as facilitated by COBOL's verbosity, then there is something
seriously wrong with the design and/or verification in the process.
I think design without automated code generation and proof-checking
support is passing the buck. Ideally, the principles underlying a
program should be in that program, and not just as comments. If there
are contradictions in the design, the program shouldn't compile. As
the design is fleshed out to make a useful program, the programmer (now
also a designer) should have the tools to continue to prove all of the
pieces. At the end of the day, all bugs should be considered the
responsibility of highest level designers. There should be no `cut' at
all.
Of course, there is rarely the time or incentive structure to do any of
this. Productive programmers are the ones that get results and are fast
at fixing (and creating) bugs. In critical systems, at least, that's
the wrong incentive structure. In these situations, it's more important
to reward people that create tests, create internal proofs, and refactor
and simplify code. Having very dense code that requires investment to
change is a good thing in these situations. A `bad change' should be
trivial in practice to identify: The compiler and/or test suite would
not let it through -- an objective fact, not an opinion of `experts'.
Marcus
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
