SCOUG-Programming Mailing List Archives
Return to [ 19 |
November |
2007 ]
Content Type: text/plain
"...The emphasis then shifts toward getting most out of
interpretive mode, thus maximising the productivity of the
developer. Here again we don't have to invent anything as it
already exists. Instead we may take advantage of its logical
extension. You can talk to the patent office. They will
inform you that it differs from "invention"."
All along here in terms of the language, tool and methodology
I have taken them from existing instances. Thus the question
should shift from whether it will work, which it obviously will,
to when working does it produce the desired developer
productivity results?
Experience over some decades shows that developer
productivity from initiation of effort to final productivity
increases with interpretive over compile mode. Whether you
use APL, LISP, FORTH or PHP the total development time and
effort from initiation through testing and thus production
remains lower. It's only when you leave development and go
into production, where your primary emphasis is on
throughput, that compiled execution exceeds that of
interpretive.
We have an identical process in interpreting and compiling
except in the construction stage where we must state which
form we desire. We require no source changes. I used to do
both interpretive development and compiled execution with
IBM's PAS (Personal Application System) using the BASIC
interpreter which came with DOS and IBM's BASIC compiler.
The only difference proposed here lies in allowing either as a
developer option in a single product, a tool like the
Developer's Assistant.
This capability would not occur to someone whose experience
encompasses imperative languages, the first three generations
of programming languages (actual, symbolic assembly, and
HLL). Each of these rely on the developer supplying
completely organized source to the interpreter or compiler. In
fourth generation, in logic programming, that organization
occurs in the completeness proof of the software. Thus the
fourth generation can accept unordered specifications on
input. SQL doesn't, but Prolog does.
You have two types of entries, referents (data) and
references (statements or expressions, i.e. subsets of
statements). With interpreters testing can occur on the
smallest instances of either. That permits a granularity
coupled with ease of testing that compilation cannot match.
We have opted for a fourth-generation language based on
logic programming. We have further opted to use predicate
instead of clausal logic for the creation of test data.
Remember clausal logic, e.g. that used by SQL and Prolog,
depends upon a separate process to generate test data while
predicate logic supports its generation as part of the
interpretive process. We will cover this in greater detail later.
A single source statement does not a program make.
However, for an interpreter it does make an executable unit
which we can exhaustively test. Moreover an interpreter can
make an executable unit of any group of statements up to
and in our implementation beyond the boundaries of a
program. It can in fact extend to an entire operating system
and any number of applications.
The interpreter can do this as long as it has all the source
statements for all the executable units involved. Thus the
interpreter which operates on source makes none of the
distinctions that can occur in compiled executables of names
with extensions of .exe, .com, .sys, .dll, etc. To the interpreter
they all look alike. If the source contains multiples of such
units, the interpreter regards them as a single unit.
This is one of the "logical extensions" referred to earlier.
While we have examples of interpretive executions from the
statement level up to a complete program unit, thus with
interpreters we have not considered extended it to multiples
of such units. On the other hand we have done so in compile
mode with the package option.
We designate a procedure as either internal or external. An
internal procedure is contained within another, ultimately
within an external one. An external one is contained in no
other. Compilers accept one and only one external procedure
as input except for packages. In packages they accept one or
more external procedures, one of which has the "main"
designation.
We have two things to note here. One, compilers now accept
the logical extension to allow more than one external
procedure on input. Two, nothing prevents the further logical
extension to allow more than one "main" designation. In short
in doing away with the rule limiting a single compile to one
external procedure we have no reason not to extend it
further to allow multiple programs of multiple external
procedures within a single compile.
If we can do it with a compile, we can do it with an
interpreter. As stated before we can do it with a granularity
and ease not possible with a compile. It also means that
compiled boundaries, for which .exe, .dll, and other such
extensions exist, do not exist in source in interpretive mode.
Thus we can do cross boundary execution and testing at the
source statement level, which we cannot in compile mode.
While it may seem incongruous to have an entire operating
system's source in interpretive mode, the same granularity and
ease of effort to test any path at source level across module
boundaries increases developer productivity significantly over
that which occurs with compiled executables.
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"postmaster@scoug.com".
=====================================================
Return to [ 19 |
November |
2007 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
| 
