SCOUG-Programming Mailing List Archives
Return to [ 09 |
January |
2004 ]
Content Type: text/plain
Greg,
I doubt if we have any real differences in this matter. In fact I
have considerable empathy for your position, for your desire
to provide the best that you know possible.
In starting this thread in what now seems oh so long ago I
wanted to address QA issues on error detection, correction,
and prevention with respect to the use of logic programming.
The first two, detection and correction, deal with introduced
errors, while the third, prevention, deals with preventing their
introduction.
I don't concern myself with the education, intelligence,
experience, knowledge, and skill than anyone has to have to
understand and specify a process properly. I do concern
myself with easing the specifying and re-specifying effort. It's
primarily a thinking and writing process with an initial
minimum. It quickly becomes a re-thinking and a re-writing
process that quickly exceeds and outdistances the initial
minimum.
You can't avoid communicating requirements. You need a
record of them. While other possibilities exist and get used
you need a more permanent and traceable record, normally a
written record.
However clearly written the requirements in the user
language, so that he understands what you understand and
vice versa, they need translating into a formal language which
translates them into the language of the machine. So you
have the translation from requirements language to the
programming language. The question which remains deals
with the distance between them, the number of translations
into intermediate languages necessary. Therein lies the
difference between imperative and declarative languages.
Note that the difference lies not so much in the effort in initial
writing, but in the ongoing rewriting: what must occur to
implement a change, particularly one which we must replicate
not only within a program but across all programs in an
application system and even possibly across application
systems.
We have the first problem of change synchronization, the
global effect of change. Once completed the second problem
of change impact, the effect of a global change. This latter
we can only determine through testing.
I had thought I had made the case for use of logic
programming when it came to ease of writing and rewriting
source code. To begin with it required only one manual
rewriting of requirements to specifications, one
translation...instead of the four, the additional writing
associated with analysis, design, and construction.
That left only testing. If I could demonstrate that logic
programming had a similar effect on testing, in terms of the
amount of manual writing and rewriting which must occur
initially and with each change, then we should have closure in
choosing the most cost and time effective means of
programming.
Somehow we got sidetracked on the issue of order when I
placed such an emphasis on supposedly unordered input. I
should have made a distinction between necessary and
unnecessary ordering. Within a code segment necessary
ordering occurs because frankly no software has the means to
make that determination. Among code segments, however,
you can avoid unnecessary ordering as "internal" references
to names of other code segments create an "implicit" ordering.
This the software can do millions of times faster and cheaper.
Now to take fuller advantage of this implicit ordering you
need to have reusable code segments less than a procedure
block. You need something similar, but not identical to the
use of paragraphs in COBOL. In COBOL a "named" segment, a
paragraph can range anywhere from a statement on up.
That means regardless of reuse instances the segment only
appears once in input. It also means that any change in any
segment only occurs once. Both of these have an effect of
reducing writing and rewriting.
You may have provided an instance where such savings do
not exist. Thus no advantage of declarative over imperative
languages. I do not have the knowledge necessary to
determine or challenge this. On the other hand you have not
shown any disadvantage of declarative over imperative. If
true, the net effect goes from zero to some plus figure
depending on application for declarative and from zero to
some minus figure for imperative.
Steven hasn't offered a counter argument to my last response
about using a single language. If we assume, however, that a
single language exists, whose comparative use across the
entire range of applications ranges from zero to a plus
position in terms of writing, then you only need the one
language for all applications.
In truth we have only one theoretical language that we use:
formal logic. Every specification language, every programming
language represents some proper subset of it. Why not a
subset equal to it in a single language? SL/I represents a
personal attempt at such an effort. In truth we may have
better choices. Whatever we choose, however, we still end
up with a single language.
=====================================================
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
"rollin@scoug.com".
=====================================================
Return to [ 09 |
January |
2004 ]
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.
| 
