SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Tue, 15 Apr 2008 13:16:07 -0700
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: Silence remains golden

Content Type: text/plain

Greg,

I look forward to your input. Perhaps we can have a general
discussion at this Saturday's SCOUG meeting.

At Warpstock98 in Chicago as the last speaker on the last day
I had set through several sessions in which the presenter
offered a method for the OS/2 community to react to IBM's
announced withdrawal of retail support for OS/2. Among the
more favored approaches was one which later developed into
ODIN. As I run across websites on my favored OS/2 machine
that tell me I need to update my flash player, I have to switch
over to my Windows machine to enjoy the latest and greatest.

I offered the Warpicity proposal as a comprehensive one and
not simply focused on a programming approach based on
current software tools. In my 36-year career in IBM with
literally hundreds of accounts and thousands of programmers
plus direct involvement in total conversions which took place
in the 50's, 60's and 70's I developed a larger focus on the
software development process as opposed to a singular one
on programming.

I have mentioned before the "backlog" problem which plagues
every IT enterprise. For programmers it means never wanting
for the lack of work. For the enterprise IT it means an ever
increasing inability to catch up. Moreover the promised
productivity of object-oriented programming and with it the
advent of UML has actually resulted in a loss, thus increasing
the per program cost in development and maintenance.

The fact that a backlog exists doesn't imply that change
requests occur too frequently as much as it says about our
ability to respond to them at a similar rate. Frankly you
would like a response which gave you a better than even
chance that your response actually produce a wait time
before the next change request occurred. Your overall goal
lies in having zero backlog on average.

Obviously we have not done this despite the gains that we
made in imperative generations from machine code (actual) to
symbolic assembler to HLLs. In fact even with a fourth
generation language like Prolog, which does offer productivity
gains over third generation, the backlog persists. So why then
would I propose a fourth generation capable language?

Why would Prolog not provide the same productivity benefits
that I ascribe to SL/I? Well, one, it's neither self-defining nor
self-extensible. Two, linguistically it's a derivative of C with
the two cripplers of "int" and null terminated character strings
among others. Most importantly, three, it relies on existing
tools like editors, separate compilers and interpreters, linkers,
builds, version control, etc. The to stay abreast of C with its
object-oriented C++ it had to offer an object-oriented form of
its own to work with UML. Talk about committing suicide.

So you takin a look at an already small, relatively speaking,
community like OS/2 along with a rate of decline as members
found it necessary to go elsewhere how then do you bring the
software development/maintenance process within the
capacity of the community? You obviously can't do it with
current tools and methodology which has a history of the
backlog situation. Yet you have to achieve the same results.

It comes down to a division of labor, that which you have to
do in terms of writing, rewriting, and organizing and that
which you can shift to the software, the tool. Thus the
introduction of the guide in the determination process of
letting people do what software cannot and software what
people need not. As it turns out, as shown by existing
available tools, the only thing that people need to do is write
specifications.

Now specifications are not a program until organized as such.
Thus you must have a means of inputting unordered
specifications to a software process which orders them in an
optimal manner. Therein lies the beauty of declarative
(fourth generation) languages despite SQL's ordering
requirements to the contrary. It lies with the two stage proof
engine of logic programming (fourth generation). In this
instance of ordering specifications into an optimal whole it lies
in the completeness proof, which does the analysis, design,
and construction stages of the software development process.
That leaves only the second stage of the proof engine, the
exhaustive true/false proof, to do the testing.

Minimal writing, maximal results.

Prolog does in fact work in this manner, but it doesn't do more
than one program at a time. It cannot, or rather currently
does not, allow processing of multiple programs where the
completeness proof can more globally do its organization and
testing. It cannot treat the source for .dll, .exe, .sys, etc. as a
processing unit. Thus the language does not fail as does its
implementation, the tool for processing the language.

So in SL/I and the Developer's Assistant we have the
combination of language and tool (implementation) free of
restrictions embedded in current tools. Processing at the
source level within a single tool incorporates within a single
process everything now done separately like editing,
compiling, linking, building. and versioning. Thus the ability to
maintain, i.e. synchronize, these functions within a single
source adds yet another productivity gain, the ability of the
tool to regenerate itself as just another application system.

I look forward to the discussion.

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

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 [ 15 | April | 2008 ]

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.