Re: SEMIS Bulletin
Jean-Luc,
I strongly believe in the importance of logic and in
approaches that have a solid theoretical basis, but
I also believe that we have to face two nasty little
facts: (1) most of the software we use every day was
written without any theoretical tools, and (2) only
a small percentage of practical software has much,
if any solid theory behind it.
Formal grammar theory, which supports compilers and
translators, is the only widely used theoretical tool
-- and that is technology from the 1950s. (By the way,
every notation for formal grammars is nothing more
than a special-purpose notation for a subset of logic.
A parser is just a special-purpose inference engine
whose axioms are the grammar rules.)
JS> Although I do believe that work on decidability
> and complexity is valuable, I don't believe that
> an inference engine is absolutely necessary for
> many practical applications.
JLD> Right for any single SIMPLE or SMALL application.
Other than parsers, please cite some complex or large
applications that have benefitted from such tools.
Windows, for example, is a large piece of garbage that
was written without any theory to support it. But Linux
is a much more reliable system that was written by good
programmers writing good code without using any special
theoretical tools to help them.
The single most important feature of Linux that makes it
more reliable is modularity. Like all Unix-like systems,
Linux is highly modular, but Windows is a single monolithic
lump -- and Microsoft's strategy is to continue making it
even more monolithic. I would claim that modularity is
far more important than complexity theory or inference
engines as a technique for building large systems.
JLD> Alas, what challenges us are the problems of large,
> intricate, interconnected applications with multiplicative
> and even exponential complexity. The capabilities of
> current automated inferences engines are VERY POOR indeed,
> far from matching human abilities except on some brute force
> computations (SAT problems, "faking" chess players...)
On the contrary, I would claim that current theorem provers
*surpass* the abilities of most humans -- including most
mathematicians -- in the ability to apply rules of inference
and manipulate mathematical formulas. On a couple of occasions
recently, I have been talking with some very good mathematicians
who were delighted with the aid they get from tools such as
Mathematica, which relieves them of an enormous amount of effort
in manipulating formulas and carrying out long derivations.
Human beings are not as good as machines in carrying out the
mechanics of theorem proving. What humans do best, however,
is visualizing or intuiting the overall structure of a
mathematical subject and getting a "deep insight" or "gut feel"
for how it all fits together. That insight or feeling is not
always 100% correct in detail, and that is why mathematicians
can benefit from things like Mathematica for carrying out the
nitty-gritty steps.
JLD> Yet, I guess we all acknowledge that we DO meet already
> our limits in human management of complexity.
People always meet their limits very quickly. That is what
Dijkstra said about programming in 1965, and his solution
was to modularize. To put his ideas into practice, he and
his students implemented the THE Multiprogramming System in
a modular way that could be proved correct BY HAND, not by
machine. He didn't prove every line of code, but he proved
that the overall stucture was sound; then he and his students
wrote small modules, which they wrote and tested by the usual
hand-coding methods, to fit into that structure.
JLD> None of the technological fancy trends of the day makes
> sense if we cannot solve the complexity conundrums first.
Programmers have been using modularity to solve the complexity
conundrums for the past 40 years, and they'll continue to do
so for a long time to come. Following is a paper I wrote about
the FMF (Flexible Modular Framework):
http://www.jfsowa.com/pubs/arch.htm
Architectures for Intelligent Systems
We now have an implementation of the FMF in which 100 interacting
agents successfully collaborate on solving a problem. Each agent
is running in a separate thread on the same machine (with 1 GB
of RAM), and they get the job done without crashing. Furthermore,
you can move some or all of the agents to run on separate machines
connected wirelessly or through the Internet, and they will behave
in exactly the same way -- and different machines can even run
different OSes, such as Windows and Linux, and there is no
difference whatever in the way they behave (or they way they
are programmed).
For another view of how to achieve modularity through plug-ins,
see the following article:
http://pyre.third-bit.com/~gvwilson/xmlprog.html
Extensible Programming for the 21st Century
I mostly agree with that approach, but it is not as simple or
as general as the FMF. Instead of having a different plug-in
for each task, the FMF is based on a single universal plug-in
that supports a general message-passing protocal for everything.
That allows the interacting agents to organize or reconfigure
themselves dynamically, and it allows new agents to replace ones
that have failed (because of either hardware or software problems).
The author of that paper (Gregory Wilson) also recommends extensible
languages. So do I, but my favorite extensible languages are
controlled natural languages, which can be extended just by adding
vocabulary to a universal syntax. (I don't rule out the option
of using more traditional programming languages, but I would
rather learn new words in English than learn new syntax.)
John