Response regarding coding efficiency

[Lynn H. Maxson]

Billy wrote: "It's certain to be worse than what a 
hand-coder could achieve, because the logic system 
is limited to things which are actually identical 
to the original.  The hand-coder is only thus 
limited during the process of refactoring, not the 
process of rewriting."

Here I must strongly disagree.  There is no 
hand-coder on the face of this earth which can 
match the ability of a logic engine to examine all 
possible logical instruction sequences which are 
logically equivalent to the higher level source.  
In the time that the best hand-coder examine a 
sequence, decided on its order, and keyed it in a 
logic engine would have done the same (and much 
more extensively) tens and possibly hundreds of 
millions of times.

Read once more what Fare has written in the 
glossary under "reflective" (and elsewhere) with 
respect to automating more (clerical) activities 
thus freeing the user up to engage in more creative 
pursuits.  It is this division of labor, of 
deciding who gets what, that leads to the 
guidelines of "let people do what software cannot 
and software do what people need not."

On the other hand we do not preserve equality or as 
you say "actually identical".  No HLL source code 
looks like machine code.  Therefore some 
translation occurs.  Besides we are engaged in 
translating (decomposing) a higher-level source 
into a lower level format.  The best we can achieve 
as identity (or identical) is out of the question 
is logical equivalence.

I support this with what occurs now in practice in 
compiler optimization or, for example, in 
Transmeta's "software morphing", where the actual 
logical organization of the executable differs from 
the programmer-specified source.  In effect the 
programmer is writing a specification of "what" he 
wants while the optimizing process translates this 
into a "how".  If you read the Transmeta report in 
the May 2000 issue of the IEEE Spectrum, this will 
be made quite clear to you.

On a final note it is the hand-coder who suffers 
the fate (and expense) of rewriting.  That in plain 
terms is "maintenance", bringing about a change to 
something that exists.  A logic engine never 
rewrites, only regenerates, in effect tossing out 
whatever existing previously and starting from 
scratch.

Now of this is clear to you because it simply is 
not done today by implementers of compilers and 
interpreters whose "personal" logic engines 
"demand" that only one code generation option 
(result) occurs.  The output of their compilation 
is "one (and only one)" executable.  Even the logic 
programming compiler writers, e.g. Prolog, fall 
into this trap though they have the means to 
generate every possible logically equivalent 
executable.

Now I am not Michael Abrash ("The Zen of Assembly 
Programming").  I may be comfortable in C but far 
less so in assembly language.  In truth I don't 
want my result to depend on selecting the "right" 
compiler and library to get the best possible code.  
I should get it regardless of what tool I choose.  
There is no reason for a user to get screwed by a 
vendor even if both are acting in "good faith".  
Nor is there a reason why if I have expressed a 
situation correctly that the performance I get 
would differ from writing it one way as opposed to 
another.

Again read the requirements (and the glossary) that 
Fare has written.  The essence is to increase user 
productivity, not decrease it, nor overburden the 
user with details best left up to what he calls the 
"computing system".  A user should have to write no 
more than the minimal specification which is 
logically correct.  That logical correctness in 
logic programming occurs as the first proof 
(completeness) in a two-stage proof process.  

It occurs in every SQL query.  Users are interested 
in results, not in how they are achieved.  That the 
logic engine organizes it in a manner far different 
than it is written is of no interest to the user as 
long as it satisfies his purpose: logical 
equivalence.