"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.