[PLUG] Worms that attack Linux...

[Chris Genly]

Writing a bug free software system is a daunting task.  For any real
world commercial program I think it is impossible.  There has been a lot
of research into formal proofs of correctness to show that the code
implements the spec.  But the techniques are not practical.  Also, when
you are done, all you know is that the program matches the spec (a very
big achievement).  You don't know if the spec is correct.  Often a
system is specified and built, and then it is not quite what the
customer wanted.  But in the real world the spec is informal, and often
quite incomplete.

So the problem of writing a correct program is left to the skills of the
architects and programmers and the processes which support them, such as
iterative programming.  Unfortunately architects and programmers are
humans.  They have good days and bad days and they have all the
frustrating limitations that come with a human mind.  To a large extent,
programming is the process of managing complexity (using the techniques
you mentioned).  Even the best minds can't keep constant vigilance for
all bugs all the time.   Often a programmer is working on getting a
function or method to work in the common cases, then comes work on the
more rare edge conditions.  But what happens if you forget to work on
one of the edge conditions.  Or what if you worked on it, but you made a
mistake.  You got the general idea right, but the code is in fact
wrong.  Another programmer reading your code may understand your
intention, but machines do not.  As in civil engineering, if you get it
wrong and the bridge falls down, good intentions don't count.  Some
small fraction of this erroneous, missing or extraneous code may present
vulnerabilities which are accessible to a clever and evilly intentioned
virus writer or system cracker.  

Code reviews can help.  But this is not done everywhere. 
(Interestingly, for popular open source software, the code may be
reviewed in a totally informal and opportunistic way without the authors
knowledge).  But even in code reviews not everything is flagged. 
Programmers are often very busy and often find it hard to begrudge time
for a code review.

I like languages which support the quest for correctness. C and C++ are
not among those languages.  Pointers, arbitrary casting, lack of array
bounds checking, the ability to clobber arbitrary memory, and not
flagging memory problems when they occur are some of the problems.  C
and C++ rely heavily on the programmer for correctness.  A language like
Java or C# gets rid of these low level problems by requiring type
safety, garbage collection, bound checking, etc.  This still leaves a
lot of complexity for a programmer to deal with.  But it does lighten
the burden.  

I view the features of C# and Java devoted towards correctness like a
spell checker in a word processor.  The spell checker reduces spelling
errors enormously.  But that doesn't mean you writing a good novel.

I'm a Java fanatic.  But even I realize that Java is not appropriate for
every situation.  I can't wait to see what the languages of the future
will do to help the quest for correctness.

P.S.  I wrote this during compile times while debugging a Java program.
:-)

On Mon, 2003-11-10 at 02:27, Michael C. Robinson wrote:
> It depends on how affectively I use modularization, functional
> abstract, in some languages classes.  It helps to program 
> piecewise.  This is where a statement of what code does 
> can be nicer than the looking at the code itself.  Where 
> such a statement is concise, accurate, and covers what's 
> needed to depend on that code safely it can be satisfactory
> to skip direct code inspection.