Response regarding coding efficiency
Lynn H. Maxson
Tue, 27 Jun 2000 14:03:52 -0700 (PDT)
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
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
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
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