SCOUG-Programming Mailing List Archives

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

Date:	Mon, 4 Aug 2003 20:31:15 PDT7
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: Re: Warpstock 2003 Presentation

Content Type: text/plain

"So, umm, I don't get to see any code?"

Peter,

Of course you do. But first let's understand that a macro in
assembly language always produces inline code, never the
option of out-of-line (or subroutine). Two different
templates, invocations, and source code for the same
functional result.

I almost giggled with your jump past the header of the
subroutine and then jump back as well as the need for the
flag and associated extra coding. In fact unless you took care
to insure name correspondence, a restriction not present in a
subroutine invocation, it wouldn't work. No implementation
could help you here.

The issue is having one piece of source code which the
programmer can invoke on an instance-by-instance basis to
execute either inline or as a subroutine. In either case the
programmer invokes it identically except for indicating the
meta-programming option. Appending, for example, the
source text "inline" prior to the statment terminator. If he
doesn't indicate it, it defaults to subroutine. Thus only one
set of code exists, the source template, which the
implementation can do in one of two programmer-defined
ways.

The programmer, for example, can invoke a sort routine as "rc
= sort(A, flda, fldb, fldc);" as he would in a subroutine. If he
wanted it inline, he would write it as follows: "rc = sort(A,
flda, fldb, fldc) inline;". Any particular instance he can switch
from one form to the other either by including "inline" or not:
a one-word change. You have no such capability in assembly
language expressible as simply or easily.

Suppose that you had a variable-length, character variable
which not only had an upper limit but whose use dictates a
lower one as well. You currently have no means in an HLL to
express this rule. Thus you, the programmer, has to enforce
the rule (assuming, one, that you know it, and, two, that you
remember it wherever) in every instance of its use.

You cannot, for example, declare it as part of the data
definition, which allows you only to specify an upper limit: "dcl
jimmy char (17) varying;". Now how much of a jump to rocket
science is it to be able to change this to "dcl jimmy char (5:17)
varying;"? Suppose if it is text, that it contains caps only: "dcl
jimmy char (5:17) varying range ((A...Z)...);".

Now you have rules embedded within (or associated with) the
data declaration. This not only dictates the logic which the
implementation must verify for correctness, but it also means
that it must include the "exception" code as well to indicate
any error in execution. Obviously (something which you may
not have considered) it should allow the programmer to
dictate what should occur in the instance of an error: "on
range (jimmy) begin; ....end;". Just your typical PL/I-like
exception handling capabilities.

Oddly enough this "range" attribute in a declare statement I
have found sufficient for expressing the range of all rules
with respect to any data element or aggregate. It even
allows for expressing dependencies between two or more
data variables.

For example, suppose that "jim" and "jane" are single
character data elements. "jim" can have only the values "c"
and "f" when "jane" is "d" or "x" when "jane" is "a". We
could express this in the following:
"dcl jim char(1) range ('c' or 'f' when jane = 'd', 'x' when (jane
= 'a');"
"dcl jane char(1) range('d', 'a');"

This moves responsibility for enforcing the rules as well as
notifying any exceptions detected during compilation or
execution to the software. That means it writes the
necessary code, not the programmer. That means it
remembers to write the code, not the programmer. It also
means that if you are a "newbie" to the application or set of
applications, you still cannot introduce a coding error with
respect to these rules.

You could have hundreds and thousands of such rules
embedded within the software of an enterprise. Now you find
that the effect of turnover in personnel and the learning
curve is reduced significantly. You now have a software tool
that can immediately indicate a rule-breaking coding error as
well furnish the particular rule(s) broken. Your
documentation of the rules lies in the source code itself. In
that manner the two will never get out of sync nor can you
change one with simultaneously changing the other: they are
one and the same.

In truth, Peter, current implementations suck relative to what
they are capable of performing. Again the conflict between
the production cost to recover in the sale of the product
versus the savings (or reduced cost) incurred in its use. The
advantage of open source as a community of users and
producers lies in offsetting the increase in production costs
with the reduction in use costs.

This results in producers having only an interest in their
survival in terms of ROI. If they cannot profit in the sale of
the product or increasing its functionality, they will either limit
or cease it altogether. Other than the sale of the product
they have no means (currently) of participating in the savings
associated with its use. That's where the business models,
based on ROI, of open and closed source differ. It has nothing
to do with one being superior or inferior to the other. They
use the same tools. They have the same human resource
costs.

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

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 [ 04 | August | 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.