SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

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.

The Southern California OS/2 User Group
USA

SCOUG-Programming Mailing List Archives

Return to [ 15 | January | 2006 ]

>> Next Message >>


Date: Sun, 15 Jan 2006 00:09:01 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: Pushing ahead

Content Type: text/plain

Greg,

We often hear that we shouldn't waste our time reinventing
the wheel, in this instance an editor. In almost the same
breath...or at least the same paragraph...someone reels off a
list of editors. If we did anything of a count, it would appear
that reinventing is a popular past time.

I really don't care how many pages of source code it takes.
Instead of one or two thousand it could take ten or a hundred.
I do care whether or not it does what I want it to do. I do
care that I can take it from here to there. Otherwise open
source falls on its sword. It has a stated purpose of
"freedom", the ability to cut one's own swath, to go one's
own way. So why not make that freedom more of a reality?
Why not make it as easy as possible to exercise it? Why not
open up open source as much as possible?

When I write a PL/I program I use the IBM LPEX editor,
probably among the first of "smart" editors with colorized
syntax checking. If it were open source, I would probably use
it as a starting point. The point is having the source code,
understanding it in detail, and thus mastering a core set of
functions.

You may think it "natural" to have successive generations of
programming languages, each design to ease the task of
writing software over the previous. That makes it somewhat
curious that this ease doesn't translate into lower cost. In
fact it would seem that we mark progress in such items as
object-oriented programming with the result that we increase
the cost of developing and maintaining software as well as
the backlog. In short our progress seems to have the opposite
effect on productivity which seems on the decline.

Now the OS/2 community has declined significantly from its
peak. When your numbers decline, when you have fewer
people resources, to just stay even you have to increase
productivity. Well, it isn't going to happen by following the
"mainstream" with declining productivity and increased costs.
Outsourcing is an admission of a productivity failure: you get
the same or possibly less productivity but as a savings in cost.

Now when IBM essentially began its withdrawal from the retail
market with OS/2 and eventually from its other markets as
well I didn't waste time in anguish, cursing IBM, or whining
"poor me". Instead I took it as a challenge to the OS/2
community to establish its independence from any vendor,
essentially assuming responsibility for enhancing and
maintaining OS/2 on into the future.

At that time it was obvious that we didn't have the ability,
either the people or financial resources, to invest in OS/2
development and maintenance at the same level as that
deemed necessary by IBM or more importantly by Microsoft
with Windows. Their costs derive as a direct result of their
tools and methodology. Our use of the same would lead
ultimately to failure.

So we had to do something different. But what? We had to
lower costs through increased productivity. But how? We
needed to ease the cost of entry, to simplify and improve the
process. But how?

The Software Development Process (SDP) has five stages,
four of which occur in sequence (specification, analysis,
design, and construction) and one which occurs throughout
construction (testing).

In first, second, and third generation languages each of these
stages has at least one separate source language maintained
independently of each other. That means a change in one has
a need for reflection in the others: synchronization of change.
Each of these separate source languages depended on manual
entry and update.

Fourth generation languages also have the five stages.
However, only two, specification and testing, depends upon
manual entry and update. The remaining three (analysis,
design, and construction) occur within a completeness proof
stage through software. Fourth generation offers two forms
of logic, causal and predicate. If predicate logic is used, then
the almost all the testing can occur from within the software
within the exhaustive true/false proof stage.

I've been through this description before, emphasizing that it
reflects what occurs in practice daily, in fact billions of times
daily. I get rather tired and lately testy about people who
write SQL queries, a fourth generation language, and then tell
me that I have to prove something.

Now it may not seem to you that having to use "main" as the
entry name for a C external procedure seems much of a
problem. After all you can only have one external procedure
in a compile unit of work. However, if you eliminate that
restriction, which is an implementation and not a language
restriction, you can have an unlimited mix of "just" procedures
resulting in multiple output executables in a single compile
unit of work. That simply means you name external
procedures as you do internal ones.

If you always compile "programs" from source, i.e. all
associated procedures, you never have a need for a link or a
make process, each of which has its own source language.
When you have today's processors which will process
hundreds of thousands of statements per second, even a
two-thousand page JAVA program will hardly give it pause.

Each of the "improvements" I have proposed lead to increased
productivity. The greater automation, the more done within
the software, the greater the productivity. I assume it is at
least equal to that we provide currently to our client
processes: a fifty times time improvement, a two hundred
times cost improvement. At those levels the remaining OS/2
community can support its future on its own.

Eclipse will never come close to this. While its plug-in nature
eases the transition from one proprietary product to another it
does not alter in any manner the continuing need for separate
source maintenance of each product. Thus it does not resolve
source synchronization.

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

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".

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


>> Next Message >>

Return to [ 15 | January | 2006 ]



The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

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.