Why Forth, was:Greetings

[Jason Marshall]

Francois-Rene Rideau wrote:

> NB: don't post to both tunes-lll@bespin.dhs.org and tunes-lll@tunes.org
> since they are the same mailing-list!

My apologies.  I inherited a second address from Paul's message, thought twice
about whether it should be there, and then kept it.  I wasn't aware that they were
the same list.

> However, as usual, this won't work well for shared variables and resources,
> places where communication happen, or just user-redefinable objects.
>

It seems to me that as programs become more complex, this level of communication
seems to increase.  If that is the case, then pure programming becomes, what?  Less
relevant as time goes on?

> Don't get me wrong: pure programming is something great,
> and should be used whenever it can;
> programs are better automatically transformed in pure style
> for semantic analysis and optimization, when they can be.
> But sometimes, they cannot, and what I'm looking at is precisely
> a way to specify what happens at this point.
>
> Also, we have side-effecting implementations of pure programs,
> and it is important to explicit the correspondances
> between pure programs and their impure implementations,
> as well as being able to maintain the consistency of those implementations.
> In case you're interested, see my recent paper
>         On the Notion of Implementation
>         http://www.tunes.org/~fare/tmp/
>

I'll be sure to read this over the weekend.

> > Let me just say that I am of the opinion that 'better language'
> > is a lazy excuse for slow execution speed.
> Sometimes it is, but not always.
> Also, there is the question of slow at _what_?

Therein lies the question.  In the right light, most 'maxims' fall apart.
I should have given a less terse/flippant expression of this opinion.
Basically what I mean is that many people invent technical reasons for why
something is a certain way, that are really to some extent purely a figment
of their frame of thought.  That would go a great deal toward explaining why most
new programs are being written in what pessimistically amounts to thrice-modified
assembler.  I suspect, however, that this is as much the fault of the designers of
these systems as of those who would use them (what does C++ have that other
languages did not, years before?).  You can build a better drinking trough, but
will the horse like it?

> The kind of problems solved with some high-level languages
> would just never have been correctly solved in finite time in C;
> for these problems, these languages are just infinitely faster than C!

> Also, speaking of speed, do you take human development time into account?
> Do you take compile time into account?Often, the two above cost much more than
> runtime...

This is very true.  On the one hand you have a large C++ project, where a final
build might take hours.  On the other end of the spectrum, you have a Java program
of the same size, which takes perhaps 10 minutes to compile, if that.  Certainly
there exists a happier middle ground between those.  I adore the ability to rapidly
track down and fix a bug in Java (even in the presence of a suitably powerful
debugger).  On the other hand, it's very easy to write a program in Java that will
have all the cross platform and VM naysayers looking down their noses at you,
smiling smugly.

Finally, this reminds me of Maciste, that usually runs as

> the slow high-level inference engine pig that it is,
> but has heuristics to detect times when high-level inferences
> don't bring in enough information anymore, and will then
> compile the remaining problem subtrees
> into efficient partial-evaluated programs.
> So that again, speed is a question of the time scale you consider:
> micro-optimization for speed is sometime the enemy of macro-optimization.

Indeed.  Let's say that we run the program until it has reached its ideal state of
perceived optimization.  As far as the user can tell, no further changes make the
system go any faster, or respond more crisply.  It may fritter away some of this
speed later by making bad decisions, or due to changes in the utilization by the
users.  It may take hundreds of uses of the program, and/or involve the machine
consulting other computers for 'advice'.  This perfect state represents 100% of the
performance potential for the program.

Whether there exists a way to hand-code the software to run faster than this is
somewhat immaterial, though it would be nice if the margin between these was
generally very small, preferably within the margin of error of human perception.
As long as we define the end result as the measured quantity, it does not matter
much if one program perceives another as going faster, if the amount of
productivity being witnessed by humans is not appreciably different.

    Now that we have that local definition, I'll illustrate my feelings on the
subject.
I'd be perfectly happy, as an active computer user, with a program (e.g., a paint
program or a web browser) that took a week or so of use to get above 95% of its
performance potential, so long as it reached better than half of that speed fairly
quickly, and perhaps 80% within the first two or three executions.  I'd be
delighted if it could hit 80% on the first execution, but I doubt that'll happen
universally, or is really all that necessary.  Until the user figures out how to
really use the system, they won't be terribly productive.  Of course, if they can
accidentally start a task that will take five minutes to complete (with no way to
stop it), then maybe the designer needs to reconsider their interface a bit.  This
does not satisfactorily address the issue of software upgrades, however (I've grown
proficient at version 2.5, but why is version 2.6 running so slow?).

> The goal of reflection is precisely
> to let the user choose the details he wants to consider.
> However, in multi-user flavors of the system,
> security issues may also prevent users from accessing some details
> (least they do it inside unixish paranoid isolation boxes).
>

Which details do you refer to?  It seems to me that many aspects of these OO, GC'd
introspective 'platforms' essentially come down to codifying many aspects of Good
Programming Practices, which do a great deal to allow you to trust code written by
someone else.  Do you really need write protection on the bulk of memory pages if
the only untrusted code that gets into the system has to follow certain conventions
(which I believe falls loosely under the Provable Code heading) before it's even
allowed to be interpreted, or compiled to native code? If all memory accesses have
explicit or implicit bounds checking, at the LLL level, then system security can
exist completely in object interactions, and preferably on-the-cheap with code the
system has no reason to be paranoid about.

Is this not part of the philosophy behind these sorts of systems, including TUNES?

> > I would tend to believe that a LLL isn't intended for human consumption.
> Yes and no: there will still be things written by the human
> about the low-level details of the machine.
> Even if it's written in a fairly high-level declarative style,
> there will have to be a human somewhere who understands fairly well
> what code will be produced and why it does the Right Thing(TM).

The ideal LLL for such a system as this should be of a level that allows humans to
write a program that can manipulate it into something the silicon can understand,
and execute efficiently.  It would also be most beneficial if automatic code
generators, and the HLL to LLL compiler could efficiently generate the LLL as
well.  If the human has to have a visualization tool to fully comprehend what this
LLL is doing, I find that to be an acceptable requirement.

> Actually, I could contend that even Oberon's (compressed) parsed tree
> representation for programs _IS_ some kind of virtual machine;
> just not a _sequential_ virtual machine.

My first goal is in fact to write a very simple interpreter for the CPS grammar I
am working on (alright, so perhaps that makes it a second goal).  I may check out
Mr. Appell's code (a Standard ML environment), which he has made available.  It
appears the license is compatible with the GPL.

> So the morale of the story is just the more general cybernetical law:
> to achieve a means of efficient communication,
> keep the relevant information in your encoding convention,
> and eliminate the irrelevant noise.

Of course, the eternal question is: What is relevant, and what is not?
Most systems leave a lot of inferred and implicit behavior, that may not be exactly

the behavior that the programmer thought they had defined in their code.  So how do
you interact with the programmer to determine if what they said is really what they
meant?  These questions are things I think development environment builders could
be answering much more satisfactorily than they currently do, even given the
languages they are designed around.

Well, that's enough typing for one day.

Regards,
Jason Marshall