SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Fri, 17 Mar 2006 07:53:41 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Off We Go......

Content Type: text/plain

"OK. I'm sure you have heard the saying "the road to etc. etc.
etc."

Steven"

Unfortunately the saying never tells us about the road filled
with bad intentions which certainly leads to the same place.
Surely we need something more than intentions to determine
the path taken. I had thought a road map based on existing
tools and technology applied differently did that. Whether or
not it does depends upon seeing "what" the road map leads
to, which will determine the path taken.

The road to either a compiler or interpreter begins at some
point with an editor, a means of providing source. You can
make it either a separate or integrated feature. IDEs tend to
treat them as integrated even though "under the covers" they
exist separately. "Smart editors", for example, perform
syntax checking with colorization. Separated compilers and
interpreters perform their own syntax checking normally
without colorization.

The question arises whether to produce an integrated product
or a set of separate ones. The road map proposes integration.
This means that syntax checking occurs only once. The road
map proposes an even "smarter" editor which does semantic
analysis. Having gone that far it further proposes to use a
two-stage proof engine, which logically and optimally
organizes source: the completeness proof. It then generates
executable code either interpretive or standalone. It then
uses a range of values entered for variables to generate test
data as part of an exhaustive true/false proof.

Now if the completeness proof logically and optimally
organizes the source, you may overlook the implication that
user does not pre-organize the source, a requirement
currently of third-generation programming languages. That
implies that the source may appear on input in any order, i.e.
unorganized and at random.

Now having an integrated IDE with a builtin interpreter mode
means that the completeness proof must continually attempt
to come up with a "true" condition, meaning that it has all
that it needs to now generate executable code. If it it
doesn't, then it must through its backtracking mechanism
inform us of the "missing pieces" or "gaps" in logic.

You may have forgotten in all this that interpretive implies
"real time", i.e. immediate feedback. The completeness proof
may overall indicate "false", but may also include partial
truths, i.e. subsets of "true" segments. That means it can
provide a "visual", i.e. graphical, result of the current state of
the input source...in real time. As it is entered.

That means that you can input code snippets as they occur to
you, i.e. randomly. The tool will provide a visual, i.e.
graphical, view of the current state of the input, what
connections exist, which do not. The user then can pick and
choose which connections he needs to change, i.e. where the
tool indicates an unintended connection (a user logical error),
or which he needs to make. Again the results of either
appear in real time, i.e. immediate feedback.

That's the result of integrating CASE tools with the
completeness proof. You can brainstorm to your hearts
content writing only specifications with the software saving
you from first drawing "little" pictures, redrawing them until
you get a big picture, and then writing the corresponding
source code. You may enjoy spending your time in this
manner to get to the ultimate source code, but why not begin
with the source code to end with it? Particularly if the
software will "instantly" rewrite it, i.e. reorganize it, based on
changes in logic among segments.

Now if you have a library of source code "snippets" to draw
upon you can "list" them as input...by name. You could, for
example, input an entire application system, a set of
associated programs, make a change in the logic within one or
more "snippets", have it reflected throughout immediately and
then exhaustively tested.

That to me reflects the intent of open source which
empowers an individual to seek his own path...successfully. It
does increase the scope of effort in which an individual can
succeed or undertake in a practical manner. You do not
require the services of 1400 testers, as a leading proponent of
open source has used an an example of his own effort. Even
with them or even 14,000,000 you may not get an exhaustive
test.

I don't really understand how you can "brainstorm" and get to
a successful result any easier or more quickly. If you don't
care how much time you spend or how much of your physical
rework occurs during the course of it, then this tool is not for
you. It's only for people who want to get the most for the
least effort. Those who do not need not apply.

I have yet to understand where I objected to plugins or to
jEdit whose performance challenges my 1.67 GHz ThinkPad
and overwhelms my 200 MHz Pentium Pro machine on which I
do most of my work. I have no objections to plugins insofar as
integrating them within the tool. That means I have their
source in SL/I where plugging and unplugging is a matter of
"specification" as part of the completeness proof applied to
the source of the tool.

At some point it will dawn upon you that I have no interest
other than empowerment, a more complete enablement, of
the individual developer. I see no reason to place an arbitrary
upper limit on the scope of that empowerment. That doesn't
prevent collaboration. In fact it enhances it without ever
"endangering" the independence of the individual to go his
own way.

=====================================================

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 [ 17 | March | 2006 ]

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.