Proposals

[Lynn H. Maxson]

Jason Marshall wrote: "Now do you understand the 
sabre-rattling?"

Easy, Jason, put it back safely in its sheath.  I 
don't mind reading what I already know in the off 
chance that it might provide some further insight.

If you had rather pour through an example with 50 
or 100 million lines of code, instead of lesser 
number which illustrates a point, you should have 
so stated.<g>

As to the traveling salesman problem, yes, I am 
aware of it.  In fact at one time in my IBM career 
I was engaged in marketing a solution that IBM (in 
France) had developed which had the characteristics 
you designated (hill-climbing, etc.).  The 
resistance that we faced had nothing to do with the 
runtime, but with what the customer had to input 
with respect to routes.  These were distribution 
accounts from grocery chains (Ralphs, Lucky, Alpha 
Beta), restaurant suppliers, liquor 
distributors,...you name it, we had it in Southern 
California.  That effort for data collection and 
coversion of route information was estimated at 
about six months.  It involved scheduling multiple 
vehicles across all routes.  The daily execution 
time was certainly well within the "window of 
opportunity".

The truth is that optimal or perfect is sometimes 
an elusive goal.  Nominally we settle on solutions 
when are the best at the moment and evolve from 
there to successively better solutions, accepting 
full well that we may never reach the "perfect" 
solution no matter how close we may come.

The question really is in deciding between a 
specification language and a programming language. 
As a user would you really want only to state the 
goal and its conditions in a rather haphazard 
manner as they occurred to you or would you prefer 
to have to describe in intimate detail not only 
"what", but "how", and "in what order"?

"As a user" I thought described the intent of the 
Tunes HLL.  Further that the range of possible 
users be as broad as possible.  However difficult 
something may be for us "in the know" and thus 
represent a challenge if a user requests it, the 
issue is to "minimize" the effort of the user.

Writing 50 million lines of code is not something 
we would want to place on a user.  I would imagine 
that M$ would prefer any means that lets them get 
the same results (or better) writing only, say, 
50,000 lines of code or 5,000.  What you write in 
is a language.  What you have to write depends upon 
the descriptive ability of that language (in 
cooperation with its implementation<g>).

Language plus its implementation does make a 
difference in terms of user effort.  Now Jean 
Sammet in her book "History of Programming 
Languages" in 1970 covers something around 500 to 
700 different programming languages.  I infer from 
remarks made by Brian Rice in an IRC session that 
there were an equal number of new ones since with 
which I also was not familiar.<g>

Forgetting the difficulties associated with some 
problems the truth is that we have used various 
programming languages (including most recently OO) 
to produce millions of successful results.  It may 
not work perfectly, but we have a technological 
history of hardware and software of successfully 
encompassing solutions that we could not afford 
earlier.  Again it is not a "perfect" world, but 
one our experience indicates does progress toward a 
better one.

In that time, however, we discovered that 
development was the easy part (in spite of its high 
cost), what was killing us and bringing accounts to 
their knees (and experiencing increasing backlogs 
of changes) was the maintenance of what we had 
developed.  OO was supposed to address this.  It 
has failed as badly as its predecessors.

So how do you improve maintenance?  How do you 
develop a language and its tool(s) that allows new 
development to continue without interruption and 
essentially supply the ability to incorporate 
changes as fast (or faster) than they occur?  If 
the Tunes HLL can't do that, then you might as well 
put it on the junk heap with all the other (useful) 
failures.  If Slate cannot do that, then why are we 
considering it?

It is the user who has the problem.  It is the user 
who pays for the solution.  It is the user who 
expects us to do what he must do in his arena, 
providing him with a means that keeps his 
competitive ability intact, one that tracks 
"immediately" to changes in his environment.

Let's not argue over what we agree on.  While I 
haven't studied all the possible programming 
languages to date (nor has anyone else), my not 
knowing one does not invalidate what I have gleaned 
from others.  Elsewhere in another response I 
reiterated the "generational" development of first 
(machine) to second (symbolic assembler + macro) to 
third (procedural and Charles Moore to the contrary 
this includes Forth<g>) and now to the fourth 
(specification).  Each new generation encompasses 
all the abilities (or capabilities) present in the 
previous.

So unless I missed something in the material I have 
not read (go figure) the Tunes HLL either 
establishes a new (fifth) generation or else starts 
at the fourth.  Any other decision by definition 
would be regressive, i.e. less than the best so 
far.

Each new generation has reduced the user's writing 
task in some way.  However the first three limited 
themselves to the construction stage in the 
five-stage software development process: 
specification, analysis, design, construction, and 
testing.  The fourth, specification language, 
shifted the focus from construction to the entire 
process, all five stages.  The only writing which 
occurs is during the specification stage.  The 
results of all the rest you get for "free" in terms 
of human involvement.  Except for the writing of 
specifications the remainder is automated.

Now I have not submitted either of the problems you 
mention to my Prolog compiler nor do I have any 
intention of doing so.  Do I think my Trilogy would 
scale up to a 100 variables in a single equation?  
It might, but it is designed for DOS.  This means 
it will get started and abort before finishing due 
to real memory limits.  I have managed to blow the 
32MB stack on my OS/2 system with the classic 
recursion equation of only 3 or 4 variables.<g>

In short it is possible to express a problem set 
(requirements), a solution set (specifications), 
and still not get a result.  It is also possible to 
do them successfully.  Our task on the one hand is 
to make our implementations such that the class of 
"failures" continues to diminished.  On the other 
hand the task of the Tunes HLL is to do the same 
for the user.

It may not be perfect, but at least I am "smart" 
enough to know that I am closer with a fourth 
generation language than with a third, regardless 
of its bells, whistles, or esoteric features.