SCOUG-Programming Mailing List Archives

Date:	Mon, 3 Feb 2003 11:29:46 PST8
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	SCOUG Programming SIG <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Just breezing

Content Type: text/plain

You have to be careful what you ask for, because sometimes
it's already there. As I find emx in general confusingly
complicated I desperately searched Hobbes for relief. As part
of that search I happened to chance upon a WARPIN version
of emx. If it works as well as the Watcom install, we ought to
reconsider the packaging on the SCOUG CD.

When we initially started the discussion on open source in the
SCOUG board meeting I made the point that however free it
may be for the taking, it makes no sense if the giving didn't
also occur at an acceptable rate. Perhaps SCOUG with its
highly talented sources could do something to increase the
number of givers. That meant getting potential givers over
the hump of installing and using the toolset. I admit that I'm
still trying to get over that hump myself.

I remain firmly convinced that the current toolset stands as
the most serious challenge to either open or closed source.
It's not because of my inadequacies (which are obvious)
that I make such a statement, but the empirical results of
those no so handicapped. The investment of people resources
needed to maintain pace with the dynamics of change is more
than the OS/2 community either has or can afford. Frankly it's
the same for the Linux community.

This seems to fly in the face of all the different projects now
active in the OS/2 community, particularly on the european
continent and into Russia. Not all these are open source. Not
all are free. And not all are going any further.

How can SCOUG best contribute to these efforts? What can
we do to jumpstart a similar open source effort on this
continent? In my mind it lies with improving the toolset with
having people do less and the toolset more. I get somewhat
dumbfounded when someone responds that I am proposing
something new or untried when I have only used examples
from existing and proven technology.

We have to start somewhere from some common open source
starting place. We have opted for an emx-based environment
and the HPCalc application. We need to see what difficulties
people encounter to see whether we can prevent them for
others. We need to bring people up to the starting point with
as little grief and effort as possible.

I'm about to create three copies of HPCalc source in three
different directories. I will use one for emx, one for Watcom,
and one for VisualAge C/C++. My experience with two of
them so far, emx and Watcom, is that they support C
differently. I think it important to understand the differences,
their significance, and what we can do to minimize them.

On the other hand I am going to have to forego my favorite
DB2 as the preferred relational database manager and gain
some experience with open source alternatives like Postgres
and MySQL. I do this in preparation for accessing database
data from an editor. Having all tools open source insures that
we can modify them for better integration.

Object-oriented technology places great emphasis on reuse.
They create object classes as a reusable source for usable
instances, which we replicate in each instance. Within each
object class we have a set of associated methods, i.e.
application code. The methods act as intermediaries for
actions on objects through messages. However, in order to
avoid replicating methods common to multiple object classes
we have to create a hierarchy of object classes and within
that hierarchy a concept of inheritance: belonging to any
object class is the set of methods belonging to any parental
path above it. Some object-oriented languages even in the
C++ family support single-parent inheritance while others
support multi-parent inheritance. If you take this in
conjunction with different object class libraries support
different object class hierarchies, you end up with a set of
incompatibilities.

I think you can understand why we have such an emphasis on
compatibility and standards with JAVA and its libraries. That
lies at the heart of the legal battle between SUN and
Microsoft. It's no good to have a "write once, run anywhere"
application, if it can't.

We have two forms of reuse, one with replication and one
without. The one with replication we have with the %include
statement in C. Within a single application the one without
replication is the reusable "external" procedure. An example
of this lies in the four .c source modules called upon by the
"main" routine, hpcalc.c: change.c, hex-oct.c, ini.c, and
interface.c. While they are not replicated within this
application, they are for each application which uses them.
To avoid this replications we could create them as "sharable"
modules as DLLs.

At least two purposes exist for reuse. One to minimize
storage: the fewer replications, the less storage consumed.
The other lies in minimizing maintenance, i.e. having only one
source to maintain. If the source is a dll, we have only one
source to replace. If it is not, then we have to replace every
replication. That means we have to know every place it is
replicated.

From our perspective we can reuse "external" procedures.
We can make them dlls to avoid replication or we can
replicate them as needed per application. Notice, however,
that we cannot do this for "internal" procedures unless we
use the %include to represent their presence within an
"external" procedure. While we can do this, it's rarely used in
practice. Regardless "internal" procedure reuse occurs
through replication, either through the %include, physically
copying the source code, or physically writing it.

Now what's weird here is that we have no need for internal
procedures. They are not required by any characteristic of
the C language. They are only required by the restriction of C
compilers. One shouldn't be too harsh here. It is a restriction
common to almost all third generation language compilers.

The compiler restriction of processing no more than one
external procedure at a time is unnecessary. It has never
been necessary. The only way one procedure can talk to
another is via an internal reference from the caller to the
called, the invoking to the invoked. All this through the
application programming interface, the API.

This internal call mechanism creates in effect a logical
hierarchy of procedures. At the root of this hierarchical tree
lies a procedure, a "main" procedure, notable only that it
invokes without itself being invoked. It's a very simply matter
then to avoid the use of internal procedures entirely, using
only external procedures. In fact using an unordered set of
external procedures as their order is strictly determined by
their invoking sequence.

So you can do away with this compiler restriction. Doing so
allows us to go to a single form of procedure writing as well
as a single type of reuse. This includes a full use of a shared
form, i.e. dll, or replication.

If you do this, you eliminate the need for make or a makefile
or for that matter a linker. It all occurs within a single
compilation. Moreover you can have more than one "main"
procedure, i.e. one that invokes only (not invoked), within a
compile step, a compile unit of work. This means that if you
make a change to a procedure, you can recompile it with the
set of all procdures, which it either invokes or is invoked by,
as a single unit of work. That means the automatic
synchronization of change management through an entirely
internal process, i.e. the compiler, and not through cooperation
of an external organization of people.

With the exception of Cobol all other third generation
languages allow reuse only at the procedure level, Cobol has
the concept of named paragraphs which consist of one or
more sentences (statements). Instead of an %include
statement within a procedure Cobol uses the PERFORM
statement which invokes a named paragraph as a subroutine.
Cobol then provides granularity of reuse down to the
sentence (statement) level.

This becomes important when you consider reuse of the
control structures of structured programming: sequence,
decision (if...then...else..., case group), and iteration (do
while,do until). These control structures follow a "one
input/one output" flow logically in the same manner as an API
call. Like procedures control structures represent "pluggable"
and thus reusable units.

Now fourth generation languages like Prolog support this
higher level of granularity from the statement level on up.
This comes from no more than giving a control structure a
name and invoking that name from within some other control
structure. Remember that in structured programming a
procedure is no more than an assembly of control structures.
There is no reason to treat logically the invocation of a
procedure, i.e. API, than a control structure.

We've come this far to point out that we can have granularity
of reuse either shared or replicated down to the statement
level. We have had Cobol programmers doing it since the
early 60's. C programmers don't do it due to the awkwardness
of the %include statement, the use of a file manager (instead
of a database manager), the compiler restriction on one and
only one external procedure, and editors that don't act upon
%include statements even though they are smart enough to
recognize them.

We have a toolset and an umpteen-year-old methodology
that from time to time variants have given us a glimpse of
something better and easier. So far we have only discussed
reuse through manual replication, i.e. %include statement, and
not that through software replication which occurs in fourth
gneration languages.

The issue is not that we are dealing with an unknown or
unknowable. The issue is that we are not taking advantage
of what we know to enhance our toolset. Certainly if you do
not know this, then this SCOUG exercise will give you
first-hand experience. You will learn not only C, but what C
can become. It's getting to that point, making open source
maintenance as easy in the large as it is in the small, that will
empower individuals to contribute in all areas.

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

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 [ 03 | February | 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.