SCOUG-Programming Mailing List Archives

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

Date:	Sat, 14 Jan 2006 11:55:58 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, Steven,

Keep up the good work. I appreciate it when people offer
more examples of the type of software development I hope to
avoid and quite possibly eliminate. Tying into Eclipse I would
definitely not recommend personally. Before I offer my
reason(s) why I would like to inject, "Yes, Steven, I have used
the Watcom IDE."

You have to give IBM credit. It doesn't give up on its
monsters. It's earlier one came under the moniker of AD/Cycle
(Application Development/Cycle) represented by a three-tier
hierarchy.

The top tier contained the sequence of the five stages of the
SDP (Software Development Process): Specification, Analysis,
Design, Construction, and Testing. By implication the flow
from one stage to the next was seamless, i.e. through defined
interfaces.

The second tier consisted of separate horizontal line segments
representing how different vendor products overlay the SDP.
Clearly some gaps existed in which had no vendor products.
In others vendor products overlapped each other. This
emphasized a "major" client complaint that no "seamless" path
existed from input of requirements into the SDP to a finished
product on its output. The intent of AD/Cycle lay in allowing
any number of such seamless paths among the different
vendor products to occur, thus allowing the client to choose
among competitive offerings.

The third tier, also known as the data repository, was
intended to contain the set of interfaces to which the
vendor's would adapt their products to allow the desired
seamless flow. IBM assumed responsibility for the product,
originally announced for implementation in OS/2 and then later
shifted to MVS.

I've said it before. I will say it again. The vendors on realizing
the competitive impact, i.e. threat, of changing their product
interfaces to allow the seamless flow became overly
courteous to each other with a "You first, no, you first"
attitude. As a result the data repository did not come about,
AD/Cycle became perceived as a failure based on IBM's
inability to produce the data repository.

Now Eclipse represents another approach by IBM to achieve
the goals of AD/Cycle. Except this time you have a set of
APIs which vendors can use to "integrate" their products into
the underlying process. Thus the vendors can sit within the
protected walls of their proprietary products, in their own
little worlds as it were.

This has two effects. One, is increased software costs. Two,
is lower software productivity. You have product integration
at a price which we in the OS/2 community cannot afford. So,
yes, we could decide to tie into Eclipse, but we would perish
in the process.

The function of an editor is in entering, adding, deleting, and
changing source code. You can't do anything with or about
source code without engaging in this. So if you have an IDE, it
must allow this.

You can increase the function of an editor by allowing the
syntax checking of the source. You can enhance the visibility
of the results of syntax checking by using colorizing the
different syntactical units. You can further enhance the
function of a editor by doing a semantic check on the
syntactical units. You can enhance it further by generating
code based on the results of the semantic checking.

If you generate code for immediate execution, you have an
integrated interpreter. If you generate code for separate
execution, you have an integrated compiler. The only
difference lies in the type of code generation. They are
identical up to that point.

Thus you don't need more than an enhanced editor with
optional code generation. That's a fact. Every interpreter
works in this manner. Only compilers seek to separate
themselves from enhanced editors. Compilers also repeat the
syntax checking done by the editor, thus unnecessarily
duplicating effort. In fact one of the purposes of an IDE lies in
giving the appearance of a seamless fit between an editor and
a compiler. That's part of the reason why they have the "I" in
IDE.

In normal operation a difference does exist between an
interpreter and a compiler. An interpreter's smallest
executable unit is a statement. A compilers smallest
executable unit is a program which contains at least one
"external" procedure, which consists of at least two
statements, a procedure beginning and a procedure end.

In the compiler world external procedures may contain zero,
one, or more internal procedures each of which may contain
those of its own. Alternatively some programming language
implementations allow for compilation of multiple procedures,
called a "package" in PL/I, one of which must be "the"
external procedure with the remaining as "internal".

Notice here that a tree hierarchy exists with an external
procedure at its head followed by the "calling" hierarchical
sequence of the internal procedures. Note also that internal
procedures are "called", while external procedures (except
for recursion or self-calling) are not. Thus an external
procedure has a call count of zero, while an internal
procedure has a call count of one or more.

We can use this "characteristic" to allow multiple external
procedures on input. After a complete semantic check we will
have a list of procedures with a zero call count (the external
procedures), each at the head of a hierarchical list of
associated internal procedures. Thus the code generation
process can process each external process tree separately. In
doing so create separate executables as a single unit of work.

This says that with an application system of multiple programs
we can input the entire source for all of them, generating all
the executables as a single unit of work. This guarantees the
synchronization of global changes across all programs.

Note that in processing of source code only with an unlimited
mix of external and internal modules, where their only
difference lies in the call count, we have no need for linking,
thus none for a linkage editor (a separate language) or a
make or bake file (each with its separate language).

So we only have one source language to learn and maintain in
what we have covered thus far. The truth is in my proposed
approach there will never be more than one source
programming/specification language necessary. If you look at
Eclipse, you will see a separate source language for each of
the proprietary modules. So why would I ever propose
starting with Eclipse?

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

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 [ 14 | 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.