Fare's response on threads

[Lynn H. Maxson]

Responding to Derek L. VerLee response to my response about Fare's 
response to his (Verlee's) inquiry, a series of reflective 
communications.<g>

"First, I dont think anyone is claiming sentience or free will in 
the way the humans experiance it, or in even anything but the most 
stretched definitions of the words."

I would feel better if anyone pursued such a claim for the 
challenges it offers, but, in fact, a disclaimer with respect to 
"reflection" occur in an earlier set of responses on this list.  I 
accept this as fact except for Fare's continued references in his 
documentation and communications to the "system" and what "it" 
does.

If we agree that software running on hardware together form a 
"system" of automata, then the best that they can offer is 
mimicry.  They mimic (within their horribly restricted domains) 
what (and how) humans have instructed them to do.  While we may 
for convenience in communication refer to such mimicry as "the" 
system, in truth it is "our" system: nothing occurs there not 
"allowed" by us.

Now why do I stress such a distinction, that regardless of how we 
refer to something we remain cognizant of its "true" nature?  For 
me it gets to use of metrics, a means of measuring, and within a 
group of such measures a quantitative means to allow comparisons.  
This means doing what computer science has never done: provide a 
system of comparative linguistics.  In a history which to date 
encompasses literally thousands of programming languages and 
variants we despite other claims to computer "science" have 
provided for no "objective" comparative (quantitative) measures.

Let's be clear competition for "a" or "the" Tunes HLL exists.  We 
are not cojoined in an independent, collaborative discovery 
process.  Instead we have candidates.  We have candidates even if 
we do (or did) not offer them as such.  When I first came to this 
group I had a language, SL/I (Specification Language/One), which I 
felt met the requirements that Fare has documented.  In point of 
fact I had no intention of or interest in offering SL/I as a Tunes 
HLL.  From my perspective SL/I is a pure, but universal 
specification language.  Whatever choice made here on a HLL would 
be implementable in SL/I.  The primary purpose of SL/I lay in 
producing a tool, the Developer's Assistant, which would enable 
the implementation of any language or languages including itself: 
self-reflexive, self-defining, and self-extensible.

On the other hand why should Tunes opt for anything less?  It's 
not a matter that not doing it is bad for some reason, but why 
would you select a choice of one HLL which required the use of one 
(or more) different HLLs for its implementation?  Why would you 
settle for a 10%, 50%, 75%, or 99.9999% when you could have 100%?

Now within the definition of HLL I include symbolic assembly 
language, having spent my early years functioning as a (manual) 
compiler in writing in actual machine code.  With the advent of 
imrovements to symbolic assembly first offered in IBM's H-level 
Assembly Language and now in its Advanced Assembly Language it 
certainly provides more native HLL support than either C or C++ 
(if you exclude their "need" for third-party libraries).

"The highest goal of computer science is to automate that which 
can be automated.  Most computer scientists, it seems to me, have 
forgoten this high goal (with the exception of the TUNES crew, 
which is one of the things that has me so intrigued with TUNES)."

Here we have to part company.  As an IT professional with some 44 
years of practice in application development however tempting to 
make automation an end in itself I see it as a means.  Moreover 
one in which we have to measure its cost relative to its value.  
That equation dominated automation decisions in the early years 
when such decisions ran into the tens and hundreds of millions of 
dollars.

However, as hardware has become significantly less expensive in 
that time to now software costs have continued to rise.  Those 
costs continue to offer an economic barrier with respect to the 
cost versus value judgements for automation.  Thus if a HLL does 
not offer a "solution" to the cost equation relative to other 
HLLs, then for other than esoteric anomalies what does it have to 
offer?

Let's be even more specific.

We have two ways of defining a variable, explicitly and 
implicitly.  It is one thing for a language to "support" one or 
the other, it is another for it to "require" one exclusive of the 
other.  Any language metric in which one language supports both 
while another "allows" only one provides a means of comparison.

Now, so what?  Well, consider another attribute (a Fare HLL 
requirement).  Extensibility.  Does an implicit variable defining 
language support extension to explicit?  If it does not (and only 
on its own linguistic terms) and another does, should we not have 
a means, a metric, a measure, which clearly depicts this?

You may be impressed by a Slate that has been implemented in 
Scheme or a Self that has involved the use of some other language, 
but I am not.  For if you cannot implement Slate entirely with 
Slate or Self entirely with Self, then you are not talking about 
"a" Tunes HLL, but multiples.  I would have to go back over the 
list, but I don't remember "self-sufficient" as a Tunes HLL 
requirement.  If it was, then none of the current candidates would 
qualify.

You must understand then as I develop SL/I that I can make no 
references to something being handled by the "system", a cop out 
(IMHO) which occurs frequently in these discussions.  Nothing is 
handled by SL/I except in SL/I.  It is not an academic exercise 
which is left up to the student.<g>

At the same time I believe that the Tunes HLL requirements need 
specifying to incorporate a "proper" metric to allow "objective" 
comparisons of features.  To that end I would refer to the rules 
in Prolog which allow specification of a set of relationships 
(instances) and algorithms.  With such and in that manner we could 
"automate" the comparative evaluation.  It would certainly save 
time when it comes to offering a Tunes HLL candidate relative to 
existing ones as well as indicate when someone has offered a 
"better" (in some manner) choice.

Now if you cannot provide such an operational definition with 
clear measures for differences, then you have failed a basic tenet 
for a "science" or the claim to represent one.  For my money we 
can defer consideration of Tunes HLL candidates until we have 
given Fare the assistance he has requested with his requirement 
definitions.  At that point we may tolerably better associate our 
efforts with "computer science".