[RANT] Mr. Scruffy versus Mr. Neat

[mpd@netcom.com (Mike Duvos)]

"E. ALLEN SMITH" <EALLENSMITH@ocelot.Rutgers.EDU> writes:

 > One interesting phenomenon is the in-migration of neats
 > into formerly scruffy-only domains. For instance, take a
 > look at the third, fourth, and fifth international
 > conference proceedings on genetic algorithms. You've got
 > scruffies who are just doing what feels right and seeing if
 > it works (my viewpoint) and mathematicians/neats who are
 > trying to derive what _should_ work the best.

The scruffy/neat competition has been around for a long time in
the hard sciences as well.  Good examples are the competing
notions used by mathematicians and physicists for doing
differential geometry, calculus of variations, and field theory,
and the physicists who think physicists can do chemistry better
than chemists can.

Ultimately, there tends to be a merger of notations and
approaches. The big Misner, Wheeler, Thorne book on Gravitation,
for instance, presented everything both from the view of the
physicists, who like to write everything as algebraic equations
in terms of components of geometric objects with respect to a
basis, and the view of mathematicians, who like abstract maps
between abstract geometric objects, and terms like tangent
spaces, exterior products, and germs.

Usually the scruffies get great results using formal manipulation
that horifies the neats, and then the neats come in and do the
rigorous proofs that demonstrate that everything the scruffies
did was valid.

This was certainly the case in quantum mechanics as well, where
questionable formal manipulation got the right answers for many
years before a rigorous theory of unbounded linear
transformations on Hilbert spaces was developed.  Indeed,
physicists happily computed commutators and anti-commutators of
such operators blithely unaware of their domains and ranges long
before the equivalent definitions in terms of one parameter Lie
groups or projection valued measures were known.

While Java is currently a scruffy invention and has yet to
recieve the official blessing of the neats, there are a number of
things that speak in its favor.

First, object-oriented runtime structures such as those used by
Java have pretty much been researched to death in various other
venues, such as APL, APL2, Smalltalk, and the MIT Lisp Machine
project.  It is not likely that we will discover some previously
unknown mode of corruption in such systems, and defensively
coding interpreters for these kinds of languages and verifying
them to prove that they contain no errors which could result in
the violation of container boundaries is a well-developed art.

This doesn't mean that such systems are free of bugs, of course,
but it does mean that they are free of the type of really cute
bugs that allow users to trick the machine into executing
arbitrary machine instructions, or into making disingenuous
requests to the kernel.

Second, there is quite a bit of experience on the part of OS
designers in meeting various levels of MIL Specs for security,
and with the standard techniques, such as audit trails,
authentication, and ACLs, which are commonly employed to
implement the features required.

So although the neats have not yet given Java their blessing, it
is extremely unlikely we won't manage to create an environment
which can safely run untrusted Java code, and filter the
program's requests for system services in a way which will block
and log any attempts to do nasty things, both for the Applet
model, and for more general applications.

A prior poster suggested that in the absence of formal proofs of
correctness, flaws permitting the exploitation of covert channels
and other such things in a language such as Java were "a
certainty." I think the situation is more complicated than this
suggests, and while I probably wouldn't want an artificial heart
with Java software today, I think a lot of the worries will
resolve themselves as time passes, and the things we are
all discussing are implemented.