Any such presentation would be non-technical and thus open to a
general audience. The primary issue lies in increasing individual
productivity, i.e. of achieving the same output with less effort
in less time. That individual is a human. This achievement lies
in requiring less human effort, transferring most of today's
activities to software.
In truth the key lies in recognizing that software development in
every stage depends upon writing. The question becomes, "What is
the least or minimal amount of writing required?" The answer lies
in the only two people involved, the user and the developer.
Basically you have only two levels of logic, the informal logic of
the user and its translation by the developer into the formal
logic required in software.
This corresponds to the integration of the informal and formal
descriptions contained in Knuth's "Literate Programming". The
difference lies in the production of a single document containing
both forms. The implication lies in no longer having "comments in
code" but in having "documented code" with a "loose coupling"
between them. That means having the same code separable from the
document as input into a compilation and the same documentation
separable from its associated code.
The implication here is that both have been decomposed into
information units (IUs) with an implied connection between each
informal IU and its associated formal one. This gives the ability
to have a change in either signal the need for a potential change
in the other. In either case the connection remains and with it a
single source of documentation to keep in sync. You can compare
this approach to any other currently in use.
The fact that you have decomposed the document (source and code)
into IUs, each of which is independent and independently
referenceable, i.e. has a name, means that you can recompose them
in any manner to suit any purpose. Thus you can organize the same
source IUs to suit the styles of a User Guide and a Reference
Manual while at the same time satisfying the structural needs of
input to a compiler.
In further remaining true to the KISS concept, which the previous
does, the second need lies in matching the solution set of the
developer (the formal logic) to the problem set of the user (the
informal logic). That match of the solution set should occur at
the same rate and in the same order as it occurs in the problem
set. In that manner we match the dynamics of the output (the
solution set) to that of the input (the problem set).
Note that in no instance do we change the problem set to conform
to a "need" of the solution set. We use strictly a one-way
correspondence. Thus the formal logic, the language of the
solution set, has to have the same universe of expression as the
problem set. In short the problem set dictates the terms.
If you understand the implications of the problem set dynamics
mentioned earlier on the development of the solution set, meaning
that each input, i.e. each IU, is independent of any other and
occurs in no specific order, then the order of the corresponding
formal logic IUs is also unimportant. This means that the
procedural logic is contained only within an IU, formal or
informal, and not across their boundaries. This means that the
IUs are loosely, not tightly coupled.
This is important in that it means that the input into a formal
logic processor can occur in any order and that the final order
occurs within the process and not as a pre-processing prior to its
use as input. It means the developer (or programmer currently)
does not organize the formal code. That organization occurs
within the compilation process. That means the developer engages
only in a process of selection, of determining which IUs are
contained in the input.
Now when a developer (or programmer) has only to do one thing in
his writing (selection) instead of two (selection and organizing)
he spends less time and effort in the activity, i.e. he increases
his productivity. As software can analyze and organise a
selection millions of times faster than a developer as well as do
it with 100% accuracy each time, you not only increase
productivity but quality as well.
So, Peter, if you think anyone is interested in something that
works in this manner currently, then I would be happy to present
it in July. Lord knows we can offer JAVA and C++ a decent
burial.
=====================================================
To unsubscribe to this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-general".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
<< Previous Message <<
Return to [ 17 |
June |
2001 ]
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.
