SCOUG-Programming Mailing List Archives

<< Previous Message <<

Date:	Mon, 16 Apr 2007 14:11:08 -0700
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Tunes anyone?

Content Type: text/plain

I bring you the following from the tunes.org website as little
else beyond this seems there. To stay abreast as a listener I
suggest you join the mailing list to listening in on the
infrequent messages as they occur.

***********************************************
What is TUNES?

TUNES is a worldwide, loose-knit group of computer
enthusiasts working toward a new vision of computing:

* Users are Programmers
* Unification of programming languages
* Automation of all that's repetitive
* Computing Freedom - open source, open systems,
re-usability & extendability

**********************************************

So what's not to like? If you substitute "developers" for
"programmers", you get the broader population that Warpicity
has in mind. The unification of programming languages
Warpicity does with SL/I while the Tunes advocates seem to
be shooting for a minimal set instead of a universal language.
In the automation of all that is repetitive Tunes has a lesser
goal than "let people do what software cannot and software
what people need not. Thus Warpicity proposes to automate
all clerical work as well as eliminate all unnecessary work.

On " Computing Freedom - open source, open systems,
re-usability & extendability" Tunes shows no inclination to
drop the source "file" system in common use in favor of
source data repository/directory. Thus it has no ability, or at
least proposes none, to bring re-use down to the statement
level. Certainly they have thus far not proposed anything
more than a program at a time approach. Beyond that they
still view versioning as a separate, non-integrated process.

When I first encountered Tunes they offered a chat session. I
thought I might listen in. However, once my id appeared they
began to question me, specifically inquiring if I had gone
through the two-year study period to be somewhere on the
same level playing field. As they say on their website, it's no
place for a dilettante.

That form of arrogance comes about when you think you
know more than anyone else and the near absence of
progress toward achieving your goal.

We have two descriptive forms of a program, one formal, the
other informal. One english, the other in your programming
language of choice. They intersect logically, descriptively
with respect to data, the objects of OO programming (and any
other form). Thus you have the need to synchronize these
two descriptions in the development and maintenance process.

We should ask ourselves why do we complicate things with
embedded comments in source code which the compiler must
process while ignoring it? Why should we have to retain a
separate, but equally important form(s) as documentation?
Why if we make a change to source code, should we also not
provide a change to all its use instances? Why maintain
source code separately from source text given their intimate
connection?

If you have reusability at the source code statement level,
why not have it at the source text sentence level? If you as
in Tunes state your desire to "automate all that is repetitive",
why would you not resolve the most repetitive reuse which
occurs?

The point is, one I will continually make, they stay within the
language box. You have a whole, 5-stage development cycle
from specification to an executable version. The believe they
can solve the whole from with a single stage in the middle of
the pack. The Data Repository/Directory has far greater
importance than SL/I and certainly as important to the
Developer's Assistant productivity as the two-stage proof
engine.

You see we could just start out with C. Granted we would
quickly come to a point where we would have to modify it
and very quickly after that change it into something that we
would no longer recognize as C. The beauty of basing SL/I on
PL/I is that no extension will impact the upward compatibility
of previous source. PL/I is a proper subset of SL/I. Anything
that works in it will continue to do so in all future versions of
SL/I.

Now I haven't taken to criticize PHP and Python, both deadend
products with replacements already appearing on the scene.
The real question we need to ask is why the academics even
now after some 50 plus years still can't seem to get it right.

I think this weekend I will provide an overview of the Data
Repository/Directory with the full set of relational tables,
columns, and attributes. I might toss in a little PICS (Process
and Inventory Control System) which underlies all
manufacturing. If we have some time left over, take a look at
the three forms of analysis (classification, structure, and
operation). Then illustrate how they all work together to
automate software source maintenance.

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

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