SCOUG-Programming Mailing List Archives

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

Date:	Fri, 17 Mar 2006 18:19:11 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: Check this out

Content Type: text/plain

Uncle Lynn has never offered a silver bullet on software.
Never intend to. Just intend to fire the existing bullets
differently so as to create more firepower.

I don't know how many times I have to repeat the
incorporation of existing technology within existing tools into
a single tool differently, offering a significant process
improvement. The fact that a improved software
development process might offer significant productivity gains
over another doesn't mean that you've invented a silver
bullet, only that you have improved the process...which still
exists.

Greg, if I followed your logic, we would have had no reason to
go from manual systems in applications like payroll, accounts
receivable, or process control to the use of software and
computers. These improvements did not come as silver
bullets, but as a means of improving existing processes. To
expect the same gains when applied to software development
over the largely manual systems with software assist in use
today seems not unusual. By shifting more of the process,
specifically the clerical aspect, by continually letting people
do what software cannot and software what people "need"
not, to software, the very basis of IT and even your precious
process control is at work. So why then assume that I have
proposed any thing more than process improvement?

As for the pictures Sheridan took I'm not aware that I have
offered anything which conflicts. If I could figure out where
those pictures were on the website, I could more easily verify
that assertion.

It begins with a PM-based editor, adds in turn syntax
checking, semantic analysis, a two-stage proof engine which
can produce either interpretive or standalone executables. It
uses a data repository/directory instead of files. You can use
the organized source produced by the completeness proof to
optionally provide visual analysis and design documentation.
It allows an unlimited and unordered amount of input source
which can encompass everything from a single statement to
any combination up to a program, any number of programs up
to an application system, and any number of application
systems including all within an enterprise.

It does this with no more than a single language with a single
tool. It is an IDE. You can compare it with any other existing
one or those undergoing development. You can take a picture
of it with its functional components of data
repository/directory (whose description/specification I know
you now have), its PM interface, its editor, its syntax checker,
its semantic analyzer, its two-stage proof engine, its optional
visual output from source, its ability to generate interpretive
or standalone executables, and its ability to generate test
data based on the use of predicate logic as part of the
exhaustive true/false proof.

Except for the optional visual output from source or anything
with the simplicity and functionality of the data
repository/directory I don't know of anything which does not
currently exist. The "principle of logical equivalence"
between input and output of defined processes which allows
"role reversal" should take care of the optional visual output
as it does with current flowcharting programs. That leaves
the data repository/directory as the only "unproven"
component. At least you know the scope of its functionality
in terms of referents, references, raw materials, assemblies,
homonyms, and synonyms.

For example, I have yet to specify the interface, the set of
APIs, for the data repository/directory for use by the tool, the
Developer's Assistant. I can and will do so at some point. The
most obvious change to the editor menu occurs in the "file"
menu option with "open", "new", "save", "save as", and
"close" and what meaning they have in use with a database
instead of a file management system. It has impact on "file"
statements in source code like "include" or "define" as in the
current macro definitions which disappear.

It means that any open source editor we choose will have to
deal with these issues. Just as it may take us awhile to bring
PM programming within our comfort zone as Nathan suggests
we have other mental habits to adapt to different processes.
With everything "reusable" as well as uniquely named we
have to change our mental picture. For example, versioning
and version control is universal with respect to referents and
references, opening up a whole new set of options.

Now what will reduce most of this into our comfort zone will
come through a more complete absorption of list processing.
Right now we talk about using an existing relational database
manager, possibly open source. In fact for "consistency" we
will have to write a replacement in SL/I. Doing so with the
perspective that the tool source includes the database source
and that both have a common list aggregate for data storage
means that the tool will "natively" accept the list output of a
query, eliminating the current "one list element at a time"
processing now occurring between a relational database
manager and an application. In truth we will have only one
application with improved performance...because no
translation or transcribing of a query result (a list with zero,
one, or more entries) into an application occurs. The query
result occurs as a native data type to the application.

Again, that's not a silver bullet but what occurs from the
integration possible with processing only source in the
generation of executables. It doesn't and can't occur in
current applications invoking SQL queries. It can occur when
the SQL source and application source appear as a single
source. It applies a different process to achieve a process
improvement.

If it appears as "silver bullets" or "magic", I can only assert
that none such occurs. Instead I will simply assert that it
comes as a process improvement of existing processes.
Frankly that's why we seek to improve them.

Now what lies beyond our tool and its data
respository/directory? Well, how about AI customized for and
to an individual user. Why not use the user's past behavior as
a predictor of his future? Thus why not detect patterns of his
personal development habits and previous choices to offer as
choices in the course of code entry? Do it in the same manner
as the anticipatory option for spelling words occurs currently
in OpenOffice. Remember the name of the tool is "Developer's
Assistant". When you're all alone it's nice to know that you
are not completely alone, that "someone" stands at the ready
to ease your effort.

Thus Sheridan's pictures, if and when I locate them, remain
valid. They will still exist as the larger more complete picture
develops. We have a whole host of mental pictures we will
have to change as well. I will do my best to insure that yours
and mine will remain in sync.

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

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.