SCOUG-Programming Mailing List Archives

Date:	Sun, 1 Apr 2007 18:37:59 -0700
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: PyPy 1.0: JIT compilers for free and more - comp.lang.python | Google Groups

Content Type: text/plain

Sheridan,

Thanks for the reference on PyPy. I track passively several
groups with primarily academic participants who explore the
language arena as a solution to programming. Among them
are tunes (tunes.org) and maude. I can't make a meaningful
comparison to SL/I any more than I can to PL/I other than all
these languages ultimately come down to a C basis in terms of
data types and expression evaluation (no operations on
aggregates). As such C, C++, C#, and JAVA along with
Python, PHP, and Prolog have had some 37 years to come
close to the features of PL/I and will not probably in the next
30.

That doesn't mean I do respect their efforts and the ideas
which lie behind them. In truth, however, you will not hear
them touch upon the "backlog" problem which plagues the
industry. They do not propose any ability to respond to a
change request at a rate which precludes more than a
transient backlog.

Let's be clear on this point. The issue is not the programming
language and its source code maintenance. You can make
that as super fast as you like and still not solve the backlog
problem. The problem lies in the number of sources you have
to maintain. As long as you have an imperative-based
programming language which insists that the global source
organization is done by the programmer, who therefore must
not only write but also rewrite the source code, the backlog
problem will remain.

Add to that the imperative language need for manual source
writing and rewriting of specifications, analysis, design, and
testing source and the need to synchronize changes across all
of these I don't give maude, PyPy, or any of the other
third-generation HLLs a chance in hell of solving the backlog
problem.

I couldn't do it with PL/I for the same reason. It's only by
upgrading it to a fourth-generation language (SL/I) in the
same declarative class as SQL. By the addition of the
assertion statement, the list aggregate, and the integration of
rules through the "range" attribute of the data declarations.
That leaves only the writing of specifications up to the
programming. leaving global organization, analysis, design,
construction, and testing up to the software at machine
speeds.

I keep trying to emphasize that it is not a language issue as
much as it is a "numerous", manual source issue of writing and
rewriting with the synchronization which must occur along
with its sequencing that create the backlog problem. So I
propose a system with only one source code, specifications,
which can appear in any order. The software does the global
source organization optimally. That optimized source then
functions as the source for the remaining visual outputs.

You make a change to the specifications, the software gives
you new visual outputs in real time. So you can see the issue
here is not the language per se, but the amount of manual
source writing, rewriting, and synchronization which must
occur.

So we have the more complete language in SL/I. It's fourth-
instead of third-generation. Using predicate logic it can create
its own test data with an ease not available in the others.
This other languages have features that we can incorporate.
For example, the use of late-binding on data attributes which
essentially allows us to see a compendium of use instances of
data variables, allowing us to fix them a posteriori instead of
a priori currently.

I think we can gain much from a study of their interpretive
code generation. We have many areas in which we need to
gain experience. How better to do that than with real
examples.

In the end we will solve the backlog problem. That may seem
somewhat esoteric, exotic, or even meaningless. In our
current situation we continue to see advances occur in
products in Windows and Linux long before we see them in
OS/2/eCS. That means that we have a backlog. If we didn't
have it, then we could advance at their rate (as they have
not solved the backlog problem) or even faster.

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

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 [ 01 | April | 2007 ]

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.