Old Dog's New Tricks

Martel Firing mfiring@PrimeNet.Com
Mon, 15 May 1995 14:34:22 -0700 (MST)


Thank you Francois-Rene for your message a few days ago.  I wanted to 
visit your WWW site before responding.

On Sun, 14 May 1995, Francois-Rene Rideau wrote:

>    I've been very interested in your post about CANDO, and I completely
> agree with your diagnostic as of what is lacking now in the computer software
> world, as well as with the general philosophy you propose to asnwer the
> problems.
>    Actually, I already began my own project just for the very same
> reasons, and with mostly the same goals (some aspects being stressed more
> or less by me than by you according to the history of the project):
> 
> Here is where I disagree slightly:
> 
> >   I propose
> >   that all data be represented as strings with only the address, length
> >   and type transmitted from one module to another.  This needs to be very
> >   simple and highly generalized.
>    Ahem. I propose we use some higher-order type system, much like what the
> Coq proof system does, but made more usable, by adding reflectivity, access
> to low-level considerations, and multiple level of error-tolerance. A proof
> system is really the most reliable thing possible, plus it's clean, the
> theory is well known, and its so generic it will last for years (with perhaps
> adjustements in encoding). It's much more secure and accurate than English,
> it is very well-known theoretically, and has already been implemented very
> successfully, though not integrated into a real-work oriented platform yet,
> only dedicated research software.

Unfortunately, I'm not familiar with Coq proof systems.  The idea behind 
the generalized representation is simply to avoid the complications of 
data representation such as numbers being: 8-bit integer, 16-bit integer, 
single precision floating point, etc. etc.  My approach would be to just 
call them numbers and represent them in ASCII.  I realize that this has a 
performance penalty, but believe the tradeoffs are worthwhile.  Other 
data types should be similarly generalized as well.

> 
> >	Secondly, a means has to be devised for modules to tell one another
> >   what they do or what they need.  This is the most difficult problem.
> >   I've worked on this for some time looking for a "computerish" solution
> >   of formal words and phrases that could be used.  My conclusion, at this
> >   point, is that English would work best, because people (even
> >   programmers?) understand it.
>    With a formal proof system like Coq, you can precisely define what modules
> can do and what they need. When formal specifications were not entered yet,
> and/or for people to understand what a module is meant to do, english is also
> a good point (but it can't be used as the basis for computer security,
> whereas proofs can). This is why the reliable modules will have formal
> specifications. But a fundamental concept in TUNES is annotations: you can
> annotate a module object with english text as well as formal proofs, types
> in any type-system, display options, or just anything. Understanding of
> english would be a fine longer-term goal, but it is still very remote.
> 
Your solution sounds optimal if it isn't too complex.  My notion is more 
general in this respect.  The idea of English to specify lets programmers 
decide what to match.  The machine or language would not do this itself. 
However, if it could be automated, that would be so much the better.

 > 	
> >    A) How to let modules compete.  How to score and select the best
> >       modules for an application instance.
>    This is a point that the TUNES team already considered: TUNES is going
> to be a distributed, persistent system. Which means there is a persistent
> distributed database of modules. By the means of a distributed publishing
> system, people can make available world-wide their feedback about any
> module (as well as any real-life subject they would), in any computer
> or human language (including real-life measurements).

Sounds good to me!

> 
> >	Undoubtedly, some will ask: "Why hasen't Firing implemented CANDO
> >   himself?" The answer is simple.  I haven't thought it out completely and
> >   don't see how to make a living on it.  But I might do it anyway if
> >   someone else doesn't do it first.
>    What I'll ask is: Why not join our efforts ?
>    We seem to have very similar ways to envision the world how it is, and
> how it should be.
> 
After spending a little bit of time with your WWW pages, I did, indeed 
find some similar ideas and spirit.  It struck me, however, that you seem 
to have taken on an immense task.  I was also puzzled by what seemed to 
be a "conspiratorial" view of the computer biz.  Having been in the biz 
myself for some years and being critical of the direction  things have 
taken, I still don't believe that any conspiacy is involved -- just the 
exercise of power in a free enterprise environment.  It is customer 
choice (whether we think this choice is rational or not) that determines 
who weilds power -- and this tends to change over time.

You have some good ideas and I'll follow your progress with great 
interest -- perhaps even participate as it develops.

Thank you, Francois-Rene, for your response and for your kind invitation 
to join in your project.

Best wishes,  Martel

---------------------------------------------------------------------
Martel Firing                   
mfiring@primenet.com       
---------------------------------------------------------------------