SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Mon, 29 Aug 2005 01:32:43 PDT7
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: What did I miss?

Content Type: text/plain

Greg,

Thank you. I had this feeling that some things had occurred in
the two meetings I missed about which no one communicated
to me. Thus the difficulty and confusion I had with Steven's
earlier response.

You didn't mention which VIM or Python downloads you used
as source for compilation. Or cal.c for that matter. I have to
work my way through these. Thus it would be nice to be on
the same page as you.

I really don't have a favorite between Watcom and GCC. I
don't really care about the popularity scores of either. I do
care about the ease with which a casual programmer or a
wannabe can engage in a major premise of open source: the
ability to customize source to meet individual needs. That has
something to do with how complicated and complex the
source.

I also have concerns about collaboration where a small group
of people seek the same thing above the individual level in
customizing source. If not CVS, then what? Also how do we
evaluate a VIM-based IDE, whether GCC or Watcom, against
the ECLIPSE model which IBM has incorporated within its latest
IDE package to lure current collaborators using Notes?

I've mentioned before IBM's expensive, cooperative foray with
AD(Application Development)/Cycle. Its graphical
representation consisted of three layers.

The top layer included the five stages of the software
development cycle: specification, analysis, design,
construction, and testing. The second layer contained line
segments of vendor products which supported intervals within
those stages. The third layer contained the data repository, a
set of agreed-upon interfaces to which the vendors would
modify their products to allow customers to select a set of
products providing a seamless fit from input of requirements
into the five stages to output of tested production code.

Most notable of AD/Cycle was that it failed. That failure fell
on IBM which assumed responsibility for the data repository
whose content depended upon agreement among competing
vendors. In truth it failed not because it couldn't happen, but
because it could. That realization shook the vendor
community with it emphasis on proprietary code, based on
different sets of inputs and outputs. They realized that in
effect it "opened" their black box to easier substitution by
that of a competitor. They engaged in a "you first, not you
first" form of passive resistance until the user community
perceived this threat as a failure.

The open source community has no such protective needs.
Thus it could well as I have done propose a single IDE which
incorporates all five stages of software development. That
possibility of a single IDE we find implicit in any seamless flow
of a process from its initial input to its final output.

While it could do so, the open source community has thus far
failed to do so. Moreover it has increased the cost in people
resources over closed source efforts. Doing a comparison
alone on dollar costs for donated labor between the two fails
to address the actual cost in people resources, their time,
effort, and skill levels. It's that cost that threatens the
survival capability of the OS/2 community.

That cost ultimately comes down to an aggregate, effective
number of man-hours contributed per unit interval of time
whether chosen as days, weeks, months, or years. If that
contribution has to come from the community itself, then we
have to have a fit between the man-hours needed and those
available.

Now believe it or not, accept it or not that "man-hours
needed" depends as much on the number of available people
contributing and a given skill level as it does on the "means"
available to them: the methods they use and the tools which
implement them. If you improve the means, the tools, and
thus raise individual productivity, you reduce the number of
people resources, man-hours, required.

What you shoot for lies in improving the means to a point at
which your available interval-based man-hours suffices or
exceeds your needs. While we have no accurate figure for
the OS/2 community which may have in fact stabilized in terms
of total reduction, thus far the current means in use as well
as the numbers contributing within the OS/2 community has
not kept pace with other platforms.

Therein lies our challenge. Can we through existing means,
whose mastery we attempt, bring on enough skilled man-hour
contributions to maintain a perception of survival momentum?
If we cannot, can we change the means (methods and tools)
sufficiently to increase individual productivity to the level
necessary?

Even if we could do it with existing means, why would we not
still seek to continually improve them, to increase individual
productivity well beyond sufficient to extraordinary? Why
would we not pursue it to where more and more of open
source finds itself well within the means of individuals to
pursue their own customized source? In short why would we
not engage in continually bringing open source closer to its
stated goal?

Would not the closer we got make it the more likely we
would succeed in our desire for the longer term survival of
OS/2? Mensch and Ueber-mensch, existing means and
something beyond them, a next level followed by a next level
and so on.

Thus as we engage in increasing our mastery of existing tools
we can do so with a view of upgrading or repackaging them
to increase productivity.

We could, for example, consider changing them in a manner
supportive of Knuth's "literate programming" which allows
descriptive text to appear side-by-side with source code
loosely and not tightly coupled, i.e. not present as "comments
in source". Along with that have a system which separates
referents (objects) from references. The referents then form
a data dictionary and the references the contexts of their use.
This then allows maintenance of a referent on the basis of its
references whether text or source code. Referents by
definition are reusable. This allows the same for references.
This lowers maintenance costs thus increasing individual
productivity. It also means that comments will not appear
"within" source code but optionally "with" it. This allows
reuse of current comments as source text.

Now I have defined a data repository/directory using a
relational database model that does this...and more, much
more. It incorporates version control integral within the
process to a level beyond that implemented in current
offerings.

Heute gehoert uns VIM, morgen die ganze process.

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

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 [ 29 | August | 2005 ]

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.