SCOUG-Programming Mailing List Archives

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

Date:	Wed, 22 Jan 2003 19:13:04 PST8
From:	"Hakan" <agents@meddatainc.com >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Shall we begin?

Content Type: text/plain

Lynn (and others),

Which languages and which tools do the members of the SCOUG Programming
group use?

Hakan
(Philly OS/2, now PASUG)

On Wed, 22 Jan 2003 07:39:53 PST8, Lynn H. Maxson wrote:

>Sheridan writes:
>"...I really like the idea of encapsulating code and its
>explanatory text in one document then having a tool that
>distills the code out to create a runable program.
>
>Kindly provide us with a snipet of the .html that you envision."
>
>I hate to blindside anyone. I could furnish and will within our
>expose of HPCalc literate programming examples using
>embedded html code. I will do so to give anyone experiential
>evidence that you don't want to do it this way.
>
>You see you shouldn't have to distill code from associated
>text in an html document. That's the hard and most
>expensive way. Greg touched upon this in his presentation
>when he mentioned accessing code through a database
>instead of a file manager.
>
>If for the moment you accept that the smallest unit of
>information for source code is the program statement and that
>for source text is the sentence, then you should also accept
>that these smallest units of information (UIs) are also the
>smallest reusable units. As such each should be named and
>stored separately.
>
>It should come as no surprise to anyone that the html codes
>themselves are source text subject to the same reuse rules as
>any other, specifically that each html code has a name. With
>the exception of data declarations in which the name is
>embedded within the declaration and thus "content"
>determined, the software can automatically assign names to
>all other source types, code and text, on the basis of
>"context" naming. A context name, for example, by
>agreement could be the first 16 bytes of the source text
>(proper name) appended with an index value to allow for
>synonyms to create a "compound, unique name". If the actual
>source text is less than 16 bytes, then you simply pad it on
>the right with blanks. Thus you have a proper name
>appended with an index value that results in a unique name
>that serves as a primary key in a table with a relational
>database.
>
>Every source statement (code) or sentence (text) then has a
>unique, context-based name that the software instead of the
>user can automatically generate, store, maintain, and retrieve
>from the database. To create ordered assemblies of each or
>both intermixed you need only to give the assembly a name
>and associate it with an ordered list of source names.
>
>Now you don't actually have to name the assemblies as the
>software can do it in the same context-based manner as it did
>for the source statements and sentences. Now oddly enough
>this granularity of reuse and naming convention places the
>responsibility for reuse of statements, sentences, and
>assemblies entirely within the purview of the software. The
>software will guarantee that no more than one copy of the
>source statement, sentence, or assembly exists in the
>database regardless of its number of uses: only the name is
>replicated in each use instance.
>
>That means if you want only source code, then your
>assemblies only include the names of source statements and
>other assemblies. The same situation applies if you only want
>source text. The same situation applies if you want some
>mixture of both, i.e. literate programming. As each html code
>is source text sentence, then the same situation applies an
>html version of a literate programming document.
>
>The beauty is that the documents function only at output
>results and never as source. Thus you never have to maintain
>them per se. If you make a change directly to them, the
>software will automatically reflect those changes in the
>database to statements, sentences, or assemblies, in effect
>creating new versions (proper name plus index) of each.
>
>Thus versioning becomes a builtin function applicable to any
>named source or assembly, i.e. unrestricted. It's entirely a
>software function, occurring automatically as part of the
>editing process. This makes existing versioning systems like
>CVS pale in comparison.
>
>Now why do this? If you make a change to source code, it
>may cause a need to change the source text associated with
>the code. You need then to reflect the changes in both in
>whatever assemblies in which their names appear. In effect
>creating new versions of affected assemblies.
>
>You have the choice, again through the software, to reflect
>the changes completely (and automatically) or selectively.
>Selectively allows you to determine on a per instance basis
>whether or not the change should occur. For example, you
>may make a code change to an assembly, essentially changing
>its logic. You may do so in order to have a logical choice in
>processing.
>
>Now you have two versions of an assembly. You will want
>each to have different associated source text to support
>literate programming usage. However, the new version may
>apply only to a subset of existing uses. You can ask (query)
>the software to give you a list of its uses (where-used).
>Then selectively by examination decide on which use
>instances to change (new versions) and which to leave alone.
>
>A side effect of all this is the elimination of embedded "copy"
>and "include" statements in source code. Effectively you
>need only the name of the highest level assembly selected
>under the menu option of "data" (instead of file) and
>sub-menu option of "open". This brings in the entire source,
>which means it's all viewable as an integrate whole within the
>editor.
>
>This is a rather long answer to a short question. I include it in
>part to illustrate that which is accomplished with ease using a
>database manager that now is quite complicated and
>expensive using a file manager. So Greg remains correct
>about the advantages of using a database instead of a file
>system. He may not have thought it as far out as this, but he,
>you, and others will eventually get there.
>
>
>=====================================================
>
>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".
>
>=====================================================
>
>
>

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

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 [ 22 | January | 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.