I say this somewhat facetiously as a major difference between
third and fourth generation HLLs lies in who does the analysis,
design, and construction. In third generation languages we
perform these stages manually. In fourth generation the
software performs them.
Now if you understand the principle of logical equivalence,
then the specifications contain the necessary and sufficient
information while analysis, design, and construction represent
different logically equivalent forms of the same information. I
tried also to illustrate that using the predicate logic option of
logic programming (the basis of fourth generation languages)
you can specify ranges of data values, leaving it up to the
software as part of its exhaustive true/false proof to
automatically generate the test data.
So if you only have five stages--specification, analysis,
design, construction, and testing--and you can relegate four
of them to software, that logically implies their clerical
nature. That's the penalty we pay when mired in third
generation mode with C, C++, JAVA, Python, Perl, and
whatever else you fish out of this pot.
That leaves only specification as the creative (non-clerical)
task which requires people to do what software cannot. Once
done the software takes over. That leaves us with only two
written input forms, one, the text of the user requirements,
and, two, their translation into formal specifications. Literate
programming offers us a means not only to associate the two
forms but also ease the task of keeping them in sync.
Now how many tools do we need to write text or code? Do
we need two editors or can we do equally well with only
one? What's the best filet knife when we base both, easily
discernable forms in ascii text? Why have two when they
can't do more (or better) than one?
So you develop an "extra-smart" editor which lets you do
your creative thing on input while it does its clerical thing on
output. Just because its clerical thing executes a seamless
sequence of activities producing the various outputs along the
way doesn't mean it has to compromise on any activity. Thus
its analogy to a Swiss Army knife or any other such
multi-purpose tool falls way off the mark.
A multi-purpose tool in hardware may have to compromise its
function due to physical constraints. It doesn't apply to
software which we base 100% in logic within the physical
constraints of the host system. We have only three such
physical constraints with respect to software: storage
(internal and external), channels (i-o), and processor.
Today's technology brings all of these in excess of any
physical needs in executing software.
I don't engage in speculation about how fourth generation
languages work. SQL executed tens of millions of times daily
works that way. I didn't invent it. I don't make it up.
It doesn't violate or modify the software development process
in any manner. It simply shifts who, people or software, does
what. It allows people to do less and software more. No
matter how you cut it that increases productivity.
=====================================================
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".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 01 |
April |
2003 ]
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.
