SCOUG-Programming Mailing List Archives

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

Date:	Thu, 19 Jan 2006 18:30:42 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: Getting there--from purpose to detailed plan

Content Type: text/plain

Greg,

Patience, patience, patience.

If you do decided at least to start this journey, I do expect
you to restrain from unnecessary "Are we there yet?"
interruptions. We will get there. Along the way as we
introduce the systemic changes, the little things that mean a
lot, you will answer your own questions, my son.

I feel somewhat embarrassed to admit working for a company
whose major salient emphasis lay in increased customer
productivity. We didn't perceive that something that
translated into lowering per unit transaction costs through
greater automation, i.e. software, did so as a high level
abstraction. Somehow when the client did the calculations it
provided a significant savings in time and money. For a high
level abstraction it had a low level basis in reality.

Actually as it conservatively provided a "50 times time
improvement and 200 times cost improvement" I thought it
reasonable to apply the same analysis with the same results
on the process which improved their processes, you know the
one we use to make theirs better. So why not do the same
for our own?

In truth even in my current IT activity that remains the driving
incentive for a client to change his travel arrangements. The
prospect of saving money, time, and resources, which
increased productivity does, seems to make a connection still.

Our journey starts with a "smart" editor. We will make it
smarter. We will make it better. As we do so, as we
integrate into it existing technology, you will direct your
question elsewhere as to why they didn't do it sooner. But
then you will have it to hand to them. You will have the
answer.

We will come to understand the GUI interface as we will have
to change. We will come to understand the underlying APIs as
we will have to use them. We will come to understand its
colorized syntax checking. We will add PL/I and SL/I to the
set of supported languages. At that point you will see the
syntax in VIM terms. At some point you will see it in SL/I.

At some point you will see the addition of semantic analysis.
At some point you will see the addition of interpretive code
generation. At that point we will have an interpreter. After
that point you will see the addition of standalone code
generation. At that point we will have an
interpreter/compiler.

Along with the interpretive mode we will add the use of
predicate logic in our exhaustive true/false proof engine.
Because we now understand the GUI interface we will "mark"
code from a single variable or a single statement on up,
specify the value ranges for the included variables, and
perform "automated" testing of such a complete nature
currently regarded as "impossible" or "impractical". That will
allow us to have as close to releasing "bug free" code as
possible. From the same GUI interface we can do complete
component (variable, statement), unit, integration, and system
testing across an entire application system unlimited by
number of programs, all from a single proof engine as a single
unit of work.

So patience, patience, patience. We will do the forest one
tree at a time. Eventually you will get the big picture.

Now I do admit that I designed the Data Repository/Directory.
Of course, it uses a "standard" relational database manager, in
all likelihood MySQL, and an application interface for access
by the editor/interpreter/compiler. I did decide on using
software to assign names to statements and sentences, to
store only source statements and sentences, and to treat all
assemblies as lists. That simply reflects some 40+ years in the
manufacturing/distribution industry with bills of material
processing. I saw no reason that we should deny ourselves
one of the major advances of the industrial revolution.

So, no, we're not there yet. We may decide to take different
roads on our way of getting there. I keep saying "we" to
show who will make those decisions.

Patience, patience, patience.

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

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