SCOUG-Programming Mailing List Archives

Date:	Sun, 15 Jun 2003 19:55:02 PDT7
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: A recap

Content Type: text/plain

When we actually received a little time with some breathing
space I think we did quite well. I think Greg has set a nice
standard in terms of presentations that the rest of us could
well emulate in future sessions.

I see three significant outgrowths of yesterday's meeting.

One the pursuit of upgrading the programming SIG webpages
to support a poly-lingual approach to learning programming
languages through comparative linguistics. This occurs on
three levels. At one level is a side-by-side comparison of a
set of selected algorithms, each written (where possible) from
the set of selected programming languages. The second level
offers a side-by-side comparison in matrix form of features
and functions of the languages. The third level offers
tutorials on each programming language based on the
selected algorithms.

The second outgrowth lies in getting a reading familiarity with
the GCC compiler, understanding its components, and then
undertaking modifications to it to eliminate the restrictions it
imposes on the language. It amounts in part to a proof of
concept. Though somewhat iffy at the moment in terms of
time available it would be nice to demonstrate the effect of
the modifications at WarpStock03.

The third outgrowth, as Bob Blair has put it, lies in developing
a front end based on an editor integrated with a data
repository/directory for the automated storage, retrieval, and
maintenance of source code and text. It's difficult to imagine
the benefits of automatic reuse of source down to the
statement level. The fact that no source statement is
replicated may not seem significant either.

However it does mean that every statement assembly exists
as a list of statement or assembly names. Such lists of names
replace the source files used in programming currently. It
results in eliminating the need for "include" statements in
source, because the entire source is treated as an "include": a
named member on a list.

Another "side effect" of having a software automated data
repository/directory under the covers of the editor lies in
obtaining an integrated version control system (also
automated) performing all the functions of CVS and more...all
automatically. This versioning facility also supports unlimited
homonyms (same name, different referents) which
complements the support for unlimited synonyms (different
names, same referent).

All this arises from the separate naming (done automatically
by the software as well) and storage of each source
statement. With only one copy of a source statement present
in storage for any modification the software not only creates
a new version without deleting the old, but allows selective
replacement of the modification globally throughout the entire
lists of assemblies.

I don't know what your experience in program maintenance is,
but you quickly appreciate the value of automating the
synchronization of global changes across an entire set of
application systems...by a single person. You can quickly
appreciate the value of automatically synchronizing the global
recompilation of all affected programs...as part of a single
compile...by a single person.

If you look then at a single person participating in open
source, you can begin to understand how much you have
extended his scope of control. How much he can do on his
own independent of the cooperation of others. Then you can
appreciate how much more source in how much less time he
can contribute to the open source community.

Now we won't overwhelm you here with adding an automated
exhaustive true/false proof testing of all these modifications,
eliminating the need to release betas or the need for beta
testers...again by a single person. Nor will we mention the
effect this has on the rate of overall change in the source
along with its ability to match the pace of the dynamics of
change in the user environment. Naw, we won't do that.

We do, however, want Greg to know that we did listen to him,
even if we did not inquire why it was so important to keep
the "garbage collector" out of processing the data. As the
garbage collector operates under the covers, a hidden agent
as it were, why do we have to control where or when it
operates?

I do want to come back to a discussion of the peg solitaire
solutions, but this message already too long.

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

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 [ 15 | June | 2003 ]

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.