One step at a time

[Lynn H. Maxson]

Like several others on this mailing list I have 
pursued a project on my own that parallels Tunes.  
I, too, want "...to replace existing Operating 
Systems, Languages, and User Interfaces by a 
completely rethought Computing System...".  After 
that point we start to differ in priorities.  For 
example at the end of this quote comes "...yet 
(eventually) a highly-performant set of dynamic 
compilation tools...".  This implies a shift in 
"system" priorities, a consideration of features 
separate from their implementation.

That from my perspective is in error.  I can only 
assume that it accounts for the several references 
in the Tunes HLL requirements list to the effect 
that "computer will this" or the "computer will do 
that".  As one who has practiced in this profession 
for 44 years I have yet to find a computer that did 
anything except what it was told in software.  What 
the software told it was in turn traceable to human 
direction.  Thus I cannot on the one hand propose 
wanting "this" without a clear directive of getting 
from here to there.  In short a systemic approach 
in which all inter-dependencies, inter-connections 
progress as a whole.

What I will concede and hold in common with Tunes 
is the need to shift drastically the division of 
labor in software development and maintenance from 
people to software.  Ultimately this division leads 
to "letting people do what software cannot and 
letting software do what people need not".  This 
same division of labor we have successfully applied 
to client processes, allowing their productivity to 
proceed apace with advances in technology.  We have 
dismally failed in applying our own methods to 
ourselves as clients.

That doesn't mean we haven't tried.  We have had 
our share of evolutionary success in the 
"structured methodologies": structured (peer) 
reviews, structured programming, and structured 
analysis and design.  Apparently among the Tunes 
advocates we should attach the same level of 
success to object-oriented methods.

In spite of all these successes software technology 
has lagged hardware and software development 
continues its spiraling costs in time an money.  
The question is why?  The answer is simple.  Our 
tool set, our means of implementing software.

Now we undertook a major effort in the 80's to get 
the different vendor tools to operate in a seamless 
manner, leaving it only the the users to pick and 
choose, to plug and play from the vendor-supplied 
tool set.  That effort was initiated by IBM in its 
AD/Cycle project which ultimately received a 
failing grade after investing some millions of 
man-hours and dollars.

The point is not to belittle an effort whose 
participants were ever much as serious as those of 
Tunes, but to understand what went wrong.  The 
shortest answer is the logical implication of 
success.  For most vendors success would have meant 
open competition, no proprietary (protected) 
niches, and most importantly a shrinking 
marketplace.

You can talk all you want about having software 
technology track that of hardware, but the 
productivity consequences are that fewer people 
become necessary for greater volume.  If we achieve 
it, we will sharply reverse the supply/demand 
equation from today's imbalance toward demand.  To 
be even clearer we will have a supply ability that 
will exceed demand.  That in turn leads to a 
reduction in supply to bring the two more closely 
into balance.

Quite frankly it is quite simple to place software 
technology on track with hardware.  For us it is 
the development of a single tool, a single 
language, and a single user interface (one with the 
tool).  In fact such a tool is part of the Tunes 
requirement though buried within the esoteric 
"Interactivity" feature.

As a tool, as something which "seeks" to assume 
ever more of the clerical ("that which people need 
not") work, leaving people free for more creative 
("that which machines cannot") pursuits, it forms a 
symbiotic system with the user.  The user extends 
its capabilities as it does to the user in return.  
Together they form a system whose direction derives 
from the user, for whom the tool is an 
"intelligent" assistant.

The tool then must assume all the Tunes 
requirements.  To be self-extensible it must be 
self-defining.  Here I part with another of the 
Tunes "assumptions".  While agreeing that an HLL is 
a high level language I disagree that it is a high 
level (programming) language.  For me it is a high 
level (specification) language, a HLL language that 
is self-defining, self-extensible, and most 
importantly self-sufficient, i.e. never requiring 
the interceding of another language.

This means that within its source form it can 
encompass all aspects of any hardware or software 
system.  As a specification language it means 
containing the specifications of any machine 
architecture for which we will execute software.  
Thus at the lowest levels of abstraction we will 
have the various target machine architectures with 
a selectable connectivity (a path) to any higher 
level abstraction (levels of abstraction).

I have such a language and a such a tool in mind.  
As far as I can tell they meet the Tunes 
requirements.  As a product, as a "tool set", they 
make "open software" under the FSF look closed.  
There are no need for restrictions on use, not need 
for standards, and the inability to create 
incompatibilities while remaining within the 
syntax.  It does not require protection because it 
cannot be violated.

If you want to actually engage in "complete 
rethinking", I would suggest that you do so.  That 
means starting with as clean a set of assumptions 
as possible.  That applies to programs (as human 
productions), to objects, and to source forms.  

I would also suggest that you not belittle other 
systems, but have a clear understanding of what is 
right and what is not so right within them.  Then 
you can profitably engage in a culling process for 
the "right" and a corrective one for the "not so 
right".  Every one of them is a serious attempt by 
their author(s) and advocate(s) to do at least in 
part what we are attempting.  In that manner we can 
continue as part of a "common cause".