SCOUG-Programming Mailing List Archives
Return to [ 03 |
January |
2004 ]
>> Next Message >>
Content Type: text/plain
Peter Skye wrote:
"Then you are burning a bridge. You are, _arbitrarily_,
deciding that humans shall no longer need to understand the
source -- and you are designing a system which will make it
somewhat impossible for humans to do just that. ..."
Peter,
What am I failing to communicate here? First, I'm writing
source code and text using literate programming. That says
that every formal description, i.e. specification, has an
associated informal, i.e. understandable, description. That's
what people can do that software cannot.
If IBM were to suddenly drop the source code for OS/2 on you
with its hundreds of different and separate modules, what is it
that you could with any degree of rapidity understand?
Certainly no more than a piece at a time. Then like any
puzzle you would have to assemble it a piece at a time. Even
then how much would you understand without iteratively and
repeatedly rereading the code, possibly drawing pictures on
the side which you cannot incorporate as comments within the
code?
You seem to be upset by the occurrence of unordered input.
You do not seem to pay attention to the fact that this same
input processed by the completeness proof is ordered on
output. You now have two source forms, one unordered, one
ordered. Moreover you didn't have to exert any time and
effort in ordering it or any future reordering of it. Yet you do
get a logical and optimal organization. No people can do
better. They certainly can't do it faster...or cheaper.
This logical organization has a logical hierarchy from the
highest level to the lowest. The software can offer you a set
of dataflow charts as it completes analysis, a set of structure
charts as it completes design, and an logical organization of
the source as input to compilation. So you get both text and
visual output.
Moreover logic programming implements "backtracking". This
basically carries you in a stepwise manner why it organized
the source in the manner it did. As it is part of the
completeness proof which may prove "false", meaning that it
didn't have information (incomplete specifications) to go to
completion. The same backtracking method not only shows
you the point(s) of disconnection, i.e. an incomplete path, but
also tells you why, i.e. what is missing.
Now I do not know of any software tool, any implementation,
that offers you so much with so little input: specifications
only. Certainly draws and redraws pictures, visual output,
millions of times faster and cheaper than you can. Moreover it
draws them without error. You know that's something else
you're a little short on. More importantly they all occur
synchronized, all from the same logical source organization.
Humans have to understand the source, the specifications,
because they have to write them by translating requirements
which they also need to understand. They may not
understand how they fit together entirely either in segments
or in whole from the unordered input. They certainly have
more than enough accompanying the ordered output, knowing
that the outputs visual and otherwise arise from the same
ordered source.
The point is that they get to understand the source faster,
better, cheaper, and more accurately than any of the means
they have had up to now. The truth is that they don't have
to know the whole (the large) to get the parts (the small)
right. They may not have the whole, but the completeness
proof will tell them what is missing and why. They have to
write the specifications that connects the "gaps" based on
information gleaned from the completeness proof.
Now I started off doing analysis and design with flowcharting.
In the 70's I switched to structured analysis and design with
dataflows and structure charts. Even with CASE tools I had to
draw and redraw them. Then came the translation to source
code. Flowcharts were a separate source as were dataflows,
structure charts, and source code. If I made a change to one
source, I had to manually ripple the change throughout the
others. It doesn't take much investigation into almost any IT
shop to know how frequently the ripple didn't occur.
Otherwise the first action we need to undertake would not be
to document the system.
Now I offer you the ability to alter a set of specifications,
each written in a literate programming manner, and submit
this unordered source to a software process which ultimately
orders it optimally, producing from this ordered source a
complete set of visual and textual output.
The only bridge I am burning is the one that says I have to
perform clerical work instead of turning it over to software. I
guess there is a second bridge as well: not having to do
unnecessary work. It's amazing how much more necessary
work you can get done if you don't have to screw around
with the unnecessary.
The completeness proof, whether complete (true) or
incomplete (false), is as capable of accurately depicting an
incomplete state visually as it does a complete one. From the
same partially complete or totally complete ordered source it
can produce flowcharts, dataflows, structure charts, or any of
the sixteen UML charts. The fact that you don't have to
create and maintain them means you have more time to
understand them.
=====================================================
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".
=====================================================
>> Next Message >>
Return to [ 03 |
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.
|
