SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Sun, 3 Aug 2003 19:15:00 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: Re: Warpstock 2003 Presentation

Content Type: text/plain

Steven Levine writes:
"Not at all. If that's the way you read it, I apologize. ..."

Peter Skye writes:
"...Either this is a bad example or I don't understand your
point. It isn't the HLL per se that slows down the execution,
it's the logic algorithm in the compiler's library used to
generate the machine instructions. ..."

Sheridan George writes:
"Might I suggest making this month's meeting an overview and
a start on the details then next month present a short refresh
of the overview and the rest of the details."

Frankly I enjoy the feedback. I would hope my somewhat
emotional response with respect to C's mythical closeness to
assembly language does not discourage Tom Novelli from
participating actively. Unfortunately I used the word
"condescending" inappropriately. My apologies to Steven.

I understood basically his point. However I have a major
concern in essence in presenting material in a manner which
effects a skills transfer. I regard it as extremely important
that anything anyone does within this project anyone else can
replicate or duplicate with equal ease. That means
communicating in more detail, almost in excruciating detail,
the tools and the methods in their application.

For example, take any one of the assembly examples Steven
provided and insure that everyone else gets the same results
as he did. I think it important that we synchronize in this
manner as milestones in getting from where we are to where
we dynamically define we want to be.

Sheridan threaten to take some action relative to our web
pages. Perhaps it's there that we will establish our sync
points.

Peter seemingly misses my point on the value of open source
while at the same time making it for me. I certainly agree
that tradeoffs exist over software performance. Or even that
performance itself in the absence of time constraints may not
be of concern. However, I disagree that we ever for any
reason have to compromise performance of an HLL relative to
that possible with symbolic assembler. I generally feel that
something not functionally necessary in assembly code, e.g.
Peter's reference to a general inclusion of code for something
that never occurs, need not occur in the code generation of
an HLL.

I can (and have) accounted for some of these things
frequently over the years. However, it seems founded in
historical convenience based on technology limits then, e.g.
memory size or cost and processor speed, which have since
disappeared. For example, if I have a hundred times faster
processor now than then, I have no concerns that the
software tools invest ten times (an order of magnitude) more
effort toward producing an optimal result.

The technology increasingly allows us to move away from
general solutions to specific ones with respect to global
optimization. That simply means that software technology
should progress apace with that of hardware technology. It
doesn't mean that we should use enhanced hardware
technology to compensate for software. Our software tool
implementers along with our software methodologies, more
recently object-oriented, have relied more on improved
hardware to compensate for poorly designed (and thus
implemented) software.

I have stated the need to maintain software at a rate at least
equal to its associated change dynamics. I continually get told
that it's impossible for the simple reason that we have never
been able to do it. Nothing fails apparently like never having
succeeded.

My own analysis points to the labor-intensive aspects of the
standard, five-stage software development process. The
process regardless of methodology invoked remains
essentially unchanged today. Yet we have in logic
programming a means of eliminating the labor-intensive
activities involved with analysis, design, and construction,
leaving only specification and testing. Logic programming
offers us with predicate logic a means of adding testing as an
automatic software activity.

Open source allows us as a using community to make decisions
on software tools in which we recover the investment not in
the cost incurred in the production of the tool, which closed
source must expect to recover in order to make the
investment, but in the reduced costs in time and money from
the productions based on the use of the tool. In short the
profit lies in the results of its use not in its production. That
profit in its use covers then the cost of its production.

Thus only open source, in which the producers and the users
are the same community as opposed to closed source where
their interests do not coincide, offers the producers the means
of recovering the investment in improving tools as the users of
such tools. Relatively speaking it may cost several orders of
magnitude more to incorporate a productivity enhancement in
a tool. The using community as the producer of the enhanced
tool recovers in its repeated application of lower costs over
time.

That longer term cost amortization is part of the business
model of open source offering at least one difference from
that of closed (for profit) source. Closed source can only
amortize costs based on per unit price of the volume sold.
Any profit from its use accrues to the user and not the
producer. Therefore the only ones who can justify higher
production costs are the users who benefit from it.

So, Peter, if you look at the open source business model in
light of the previous, no reason ever exists why you cannot
have all three (faster, better, cheaper). You have to think
outside the box of the software tool which is absorbed in the
more inclusive box of its use.

So what I want then is a software tool that is community
owned and operated whose enhancement justification goes
beyond its increased production costs to include the reduced
cost associated with its repeated use. The tradeoff lies in
having sufficient participation by members in the community
engaged in continually enhancing the software tools. Given a
reasonably fixed investment for any enhancement the smaller
the community the greater the percentage of participation
required.

It lies in the "synthesis of form" involving LISP, APL, PL/I, and
logic programming. To get there means communicating why
everything else available is unnecessary, which is different
from useless. You communicate it by establishing a
framework for comparison and evaluation which clearly
establishes the better among good choices.

Along the way you establish that any advantage in symbolic
assembly is only temporary and eventually non-existent.

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

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