Re: The Promise of Forth

Jonah Thomas wrote:
John Doty <jpd@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Jonah Thomas wrote:

Your language reflects your ideas. When the language contains
logical contraditions, it's sloppy.
Yes, but that can simply reflect the difficulty with language.
Einstein insisted that his ideas were visual, not linguistic. Language
has its limits.

Sure. And when your language includes internal contradictions, that
displays a difficulty with language that perhaps can be corrected.
That's what logic is for.

There is no support in history for this view: it is merely a traditional faith of our culture. Logic has a long history of failure when applied incautiously to the real world.

Note that this is not especially controversial among 21st century logicians (I am the proud father of one). But our common culture still holds logic in a superstitious regard it manifestly doesn't deserve. You're using a device that can evaluate logical propositions billions of times faster and more accurately than you can toi look at this message. Can it think rationally?

Usually what has happened is that you've
given the same names to two different things,
Are there different things? Language insists on dividing continua.

If you have two different tests for soil pH, and one test tells you your
soil sample is pH 4.6 while the other tells you it's pH 10.5, you have a
problem. One or the other or both of your tests are not accurately
measuring pH but measuring something else. If you call the result of
both tests pH then you wind up with "The pH of this soil sample is 4.6
and 10.5".

But go for the hard case: what happens when they're close, but not identical? The difficulty of dealing with this logically is at the center of Berkeley's critique of calculus.


Similarly, if you wind up claiming that the same political candidate is
a reactionary conservative and also a wild-eyed leftist radical, your
language is faulty. Better to use language that better describes what he
wants to do instead of the labels that don't work well.

and you use them as if
they were the same thing. That's a clue to how to refine your
language.
It's an infinitely long road.

As is the rest of learning. But when you find contradictions in your
language, that's a good indication about the first steps. Fix the
mistakes in your descriptions and you won't confuse yourself as much.

How do you identify the mistakes? Logic is a very poor guide: it tends to force *internal* consistency on ideas at the expense of disconnecting them from the real world.

Give the different things different names and the contradictions go
away. The language gets easier to use, because you don't have to
"just know" which times the names refer to one thing and which times
to another.
It requires an infinite vocabulary, but we are finite creatures.

I've noticed when you don't like an idea you demand that it give perfect
results.
But when you do like an idea you only require it be a step in
the right direction. If you have two different pH tests that are mostly
comparable, no problem. When they measure two different things it might
turn out that both tests have practical value. But it only adds to the
confusion to give them the same name.

You have done this "Either it's one or the other" in several
contexts now. You consider the existing conventional wisdom and then
you consider one new idea, and you talk as if one or the other of
them must be right. This is unscientific. If you show that the CW is
wrong, it does not mean that any particular alternative must be
right.
Unscientific? *All* scientific inquiry is like this. Science proceeds
by falsification. One can *never* in science prove a hypothesis is
true.

The big value in comparing multiple hypotheses that all fit the known
data, is that they may give different predictions for data that hasn't
been collected yet. So they give a clue for what data is worth
collecting next. If they disagree, at least one of them will be wrong
when you look at the results they predict differently.

Yep. That's how I make my living.

Of course, if one
of them has no particular following then you don't win much by showing
it's wrong. And if you show the CW is wrong, people are likely to be
slow to notice.

Not in physics. Overturning the conventional wisdom with a clean, reproducible experiment (e.g. Muller and Bednorz, high temperature superconductivity) is the fast track to the Nobel.

You could have made a mistake. People figure you
probably did, when you get results that don't fit their expectations.

It's utterly unscientific to claim that falsifying one hypothesis shows
that another is correct.

A hypothesis that stands up to testing is better than one that doesn't. That's proven to be an effective path to practical knowledge. But scientific hypotheses are generally false in a logical sense. Pretty much all of the physics we teach engineering students is just approximations of the real thing, falsified by experiments outside the domain in which we expect it to be used.


They could easily both be wrong.
Happens all the time. But what can you do except look for a better
one?

Exactly. Arguing at great length that there is only one viable
hypothesis available is not particularly appropriate.

You are invited to do so.


If you define something named A, then you want the definition to be
nice and clear. If you get A and ~A at the same time, it means you
haven't defined A clearly enough after all.
The law of the excluded middle. Classical logic's most powerful and sloppy postulate. Not always present in modern formal logics, and
often violated by physical models of logic (what happens if you
connect the output of a logic inverter to its input?).

If you connect the output of a logic inverter to its input you get
something that doesn't reach a stable solution.

Eh? In my ASICs I do exactly that to get a stable regulated voltage at the gate threshold. Very stable. With multiple gates you can make nice oscillators. Very useful.

That's the physical
analogue of finding a logical contradiction.

But it's not. Classical logic has no such behavior (while Spencer-Brown's nonstandard logic can model oscillators not regulators). The classical logic model and the physical model disagree on what happens when you assert A=~A. Which is more applicable to the real world?

But it's a choice between A and ~A.
It isn't a definite choice between A and B.
Bohr would vehemently disagree.

Then Bohr would be wrong.

Wrong in science means that a theory makes incorrect predictions. Bohr was often right (none of us is ever always right).

You cannot justify judging right and wrong in the real world using logic. You cannot show any evidence that logic is infallible: you have only a tradition of faith here. Honest examination of actual attempts to use logic to find real world truth reveals millennia of failure.

The description I labeled A might not be a
good way to describe whatever it is you want to describe with it. It
simply may not make sense to say an electron is smelly or to say that
it's odorless. But if the A description does make sense then you will
not say that it's both A and ~A. When you find yourself making that
claim you are saying that the description does not make sense.

Bohr would tell you that there is absolutely no reason to expect classical logic to apply to the quantum world. And note that "under what circumstances may we apply this logic?" (there are many "logics" these days, just as there are many "geometries") is a perfectly respectable question among modern logicians.


Here's how I've understood your basic argument: If Forth was the
best computer language it would have taken over the computing world
by now.
Gross exaggeration of my position.

Yes, but effective. This is your claim when we remove the wishy-washy
disclaimers.

Hmm, you accuse me of demanding perfect results above, yet that is apparently the result of *you* removing the "disclaimers".


It has not done so. So it must have one or more fatal flaws that
keep it from being great.
Consider the history. Forth *was* a widely respected and used language

circa 1980. But C ate its lunch. And the explanations that do not involve flaws in Forth (including its culture) don't work.

They can work. You can argue that the 3F claim works better.

The obvious conclusion from that is that we should
form a harmonious group that searches through everything we know
about Forth and other languages to identify Forths Fatal Flaws
(appreviated 3F). Once we get a consensus what the 3Fs are then we
can harmoniously cooperate to fix them. This will give us a new
language that we can label "Forth" which will inevitably take over
the world.
Nah. We should be *experimenting*. We should be publishing stuff
people will use (not yet another Sudoku solver).

Well, in one extreme that says we should all go ahead and do whatever we
were going to do anyway. The result (apart from arguing about it) is
experimentation. In the other extreme we should try to cooperate on a
large common project to leverage our efforts.

"Underground Forths are needed."

It could be argued that we have an adequate number of incompatible
Forths already.

Yes, but mostly the differences are trivial incompatibilities, not major innovations.


Various people have proposed other things that have kept Forth from
taking over the world. You have rejected each of them on dubious
grounds. For example, there was the argument that Forth has never
gotten enough institutional support. You said that this couldn't
have been The Reason because languages that got the *most*
institutional support(PL/1, Ada, etc) have tended to fail and be
replaced by other languages that got less institutional support like
C and Java. But consider -- would you be certain that Forth has only
one Fatal Flaw, and that only Forth has one? Perhaps the languages
that got the most institutional support happened to have fatal flaws
of their own that kept them from great success despite that support.
Sure. You ever program in PL/I? Ugh! But then, there are also many examples of languages with weak early institutional support like C and

Python that have done very well.

Yes, you said that repeatedly. In general when you look at why a plant
or animal hasn't taken over an ecosystem, you look at the *limiting
factors*.

That'll explain the difference between a desert and a rainforest. It won't explain which plants thrive where: you have to look at the characteristics of the plants themselves.

Plants need sunlight, and water, and minerals, and CO2. They
need a place that doesn't have too many things that are poisonous to
them, and they need the herbivore load not to be too severe. They need
temperatures within an acceptable range. Some of them need the soil to
spend some time dry enough. Etc. Whichever of their needs is in shortest
supply is the one that limits them. Similarly, Forth might have run into
some external limit

Why didn't C, in the *same* environment, reach the same limit?

before it reached the limits that might have been
imposed by its chaos of incompatible compilers, or by its mass of
self-taught programmers with no common coding standards, or its lack of
standards for library construction, etc.
While C and Java got *enough*
support that the lack of it didn't stop them.
C? AT&T's support for C came *after* its success was clear. Before
that, it was just a toy to keep their CS research group happy and
productive.

Yes, you said that repeatedly.

Indeed. One more truth the Forth community doesn't like to hear.


And Forth got none.
Forth had lots of institutional support in astronomy: why didn't it continue to thrive there?

I could make up various stories. I can imagine that C had the cachet of
being a portable assembly language, the coolest of the cool at the time.

Nah. The cool stuff isn't the software.

Forth may have been easier for astronomers to get results in for
themselves, but when they did they had to keep getting results for
themselves. After you build a system in Forth can you hire a journeyman
Forth programmer to maintain it for you? Astronomers may have noticed
that using Forth tended to send them into a career trajectory where they
did more programming and less astronomy.

Yes. Forth was harder to maintain.


And self-taught programmers in those days may not have understood the
lessons that are now generally known about maintenance. You build
whatever shortcuts look useful today, and then you build new shortcuts
tomorrow, and in 2 years you look at your old code and it doesn't make
sense any more.

Why wasn't that just as much a problem for the self-taught C programmers?

A giant mess of kludges. That doesn't have to happen in
Forth but Forth makes that very easy if you're heading that direction
anyway. You wind up with a great big pile of unmaintainable code that
you can't fob off on paid programmers. So you dump Forth and start over.

Sometimes external forces matter a lot. There was a time when
WordPerfect was a leading word processor. But Microsoft Word mostly took
over. At the time a lot of people said Word was inferior. They wanted to
go on using the system they were familiar with. But they kept getting
documents from other people in Word and they had to be able to handle
that, so they had to switch.

Before 1980, the imported code in my area was essentially all Fortran. Forth held its own against that. But C was tougher competition. Importation was not a factor early in the eclipse of Forth by C (everybody was writing their own C code, just as everybody was writing their own Forth code), but later on it certainly accelerated the process.

In the legal field though, a lot of judges
wouldn't go along. They refused to accept Word documents, they wanted
WordPerfect. Judges were so important everybody else in that arena had
to be compatible with them. As late as 10 years ago lots of legal stuff
was still done with WordPerfect because of it. If astronomers already
had to deal with C (machinery they bought that was already programmed in
C, numerical stuff that was getting converted from Fortran, etc) then
they might not be as effective as the legal profession in resisting
those forces.

I could probably make up lots of other stories. But i wasn't there. You
were there but I've seen little reason to believe your explanations.
They could be true but you don't look reliable on the topic. For me it's
an open question.

What I say just doesn't match your prejudices, I think.


I
remember when Forthers were tremendously excited because Harris
Semiconductor was making the RTX chips. It wasn't just that there
were going to be 16-bit specialty Forth chips. It was that Harris
was providing Forth with its first ever institutional support. And
then Harris mothballed the RTX. Forth has survived with no overt
institutional support whatsoever, except for what Harris provided.
Whatever institutional support Forth has gotten has come from
classified military programs and secret business ventures.
Pure nonsense. Was it just hobbyists using Forth at MIT, SAO, NRAO, KPNO, etc.?

Perhaps we mean different things by institutional support.

Could be, but I fail to see what difference it makes, except if you're desperate to avoid facing the problems in Forth.

More important, you have championed the idea that computer languages
should fit in with the ways that people are predisposed to think.
But you violated that idea by your presentation. What you're saying
would be fine if you collected a bunch of guys who used to use Forth
and who were kind of nostalgic for it, who had to quit using it
because it didn't work for them. They'd be predisposed to believe in
3F. They might get all fired up to remove the 3Fs and create the
language that will take over the world the way Forth should have.
But those who've given up think even less of its future. It's rocky here, but it's bare lava there.

Why do you persist in using this single approach that doesn't work? Why
argue 3F when other paths lead to your results without needing 3F?

How can you improve a piece of engineering without recognizing and fixing its limitations?

But what if you instead presented interesting ideas. Could we build
an extension onto Forth that wasn't postfix? Of course we could. We
mostly haven't bothered because we haven't much wanted to. If we had
such a thing we could measure how much extra complexity it added to
a Forth compiler. We wouldn't have to argue about whether it would
be too complex, we could measure it. We could measure the slowdown
in runtime and the slowdown in compile-time. There might be people
who'd find those penalties acceptable.
You're going down the MAGIC/L road. It almost worked for Loki. What
was missing there? Can it be fixed? What can we learn from their
failure and other successes? I think Python is telling us a lot about
libraries.

OK, let's look at Python. What people say is that Python is great
because it has a lot of libraries. And Python has a lot of libraries
because they have a culture that encourages library-building?

Also a really, really easy and effective import mechanism.

And as a
result they have software tools that make it easy to write libraries and
find libraries you might want, and install libraries etc. OK, if a Forth
can interface to a Python library, how much harder would it be to
automatically define Forth commands that have that interface? If you
could automate that process then for every public-domain Python library
you could create a Forth library that does the same thing, with little
effort.

But the languages are fundamentally different, and have different application domains. Python's foundations are wrong for Forth jobs and vice-versa. The point of looking at Python is to study the support structure atop the foundations: syntax, scoping, importation, etc. A 21st century Forth might do well to superficially resemble Python, but fundamentally it should be very different. Otherwise, what's the point?

The big effort would be creating the documentation and example
code etc. But it looks like a start to have a long list of Forth
libraries, even if the documentation is weak.

I googled "Python library" and picked a random reference on the first
page. http://www.scipy.org/

Then I picked a random library. http://abel.ee.ucla.edu/cvxopt

I picked documentation for a random collection of routines.
http://abel.ee.ucla.edu/cvxopt/documentation/users-guide/node14.html

3.2 Level 1 BLAS
The level 1 functions implement vector operations.

scal(alpha, x)

Scales a vector by a constant:

\begin{displaymath} x := \alpha x. \end{displaymath}

If x is a real matrix, the scalar argument alpha must be a Python
integer or float. If x is complex, alpha can be an integer, float, or
complex.

So we'd have a Forth routine named scal that takes parameters x alpha,
where x is somehow an array in Python format. How would it know whether
to get an integer from the stack or a float from the float stack? Python
knows. That would have to be in the interface. Probably Forth would need
at least two routines, one for an integer alpha and one for a float
alpha. A third for a complex alpha. I don't see how to fully automate
this. Some of the work could be automated.

nrm2(x)

Euclidean norm of a vector: returns

\begin{displaymath} \Vert x\Vert _2. \end{displaymath}

Better. nrm2 is the name, x is the parameter. We might need some kind of
datatyping so the Forth code would know what kind of array it was.


It doesn't look completely straightforward. You have to have your data
in a format Python will understand. That can be automated but you have
to tell the automated routine what kind of data it is. You can probably
automate the calls easily enough so that users don't have to arrange
that themselves, and some of the documentation looks easy to dump to
Forth. But there are parts of it that would be hard to automate.

Please! Give up the worthless side issue of Fatal Flaws and tell us
about things we can try out.
"Underground Forths are needed". I'm very pleased by the recent StrongForth discussion, as it seems to me that the StrongForth
approach fixes some major issues that prevent traditional Forth from
being used as a reasonable foundation for a user-friendly language.

I'm glad to have a StrongForth option. But I think if we want a
"user-friendly" language, we ought to re-think what we mean by
"user-friendly". To my way of thinking, it means that the user can pay
attention to the things he cares about and ignore the things that to him
are boilerplate.

Forth has always done some of that. When I looked at my first assembly
language I found myself juggling registers. There were registers that
were reserved for essential OS functions. I could use them if I saved
them and restored them. Each subroutine I called would trash some
registers and preserve others, and it required its inputs in particular
registers and left its outputs in particular registers. It was a pain.
But then I tried Forth. The registers were abstracted away. All my
inputs were on a stack, and the outputs were on the same stack. I lost
some "efficiency" because my Forth primitives were grabbing things off
the stack and moving them to registers and doing the ops and moving the
results back to the stack. But I was happy withi that. It was fast
enough, and I could deal with the problems I wanted to solve instead of
picky registers.

The problem is that the bar keeps rising here. As people do more ambitious things with computers, they have less time for the boilerplate. Evolve or die.


I liked your idea of using 8-byte cells for every data type. When memory
is not an issue, that makes lots of things simpler. A Forth that does
that could import standard code just fine. Redefine C@ 2@ F@ as @ .
Redefine D+ as + . Etc. Your code won't export to standard systems but
code that ignores memory use will probably have to be rewritten anyway
for systems where that matters.

If performance isn't an issue, you can do implicit datatyping. You know
what type a number is when it's first entered. You can track what type
to expect off each arithmetic operation, when you know the types of the
inputs. You can do dynamic typing and the user never has to declare
types. Of course the result is extra complexity under the hood, hiding
things from users. But if datatypes aren't the problem I want to solve,
why not? Ignore the stuff you don't care about (like registers and CHAR+
CELL+ ALIGN ALIGNED etc) and solve the problems of interest. Then when
it's working if performance turns into an issue you can go back and
optimise.

Which details are worth paying attention to? Which are easy to let
people ignore, and then when they want they can drop back to Forth and
pay attention to those again?

The only way I know to attack these questions is to study successful languages, and published code in them. Users can't tell you what they would want, but their behavior speaks volumes.

--
John Doty, Noqsi Aerospace, Ltd.
http://www.noqsi.com/
--
History teaches that logical consistency is neither sufficient nor necessary to establish practical, real world truth. Those who attempt to use logic for that purpose are abusing it.
.

Relevant Pages

  • Re: The Promise of Forth
    ... but that can simply reflect the difficulty with language. ... And when your language includes internal contradictions, ... But when you find contradictions in your ... But there are nonstandard logics that can accommodate this just as there are non-Euclidean geometries. ...
    (comp.lang.forth)
  • ESSLLI 2009 - Final Call for Participation
    ... The European Summer School in Logic, Language and Information ... Non-deterministic Multi-valued Logics - Arnon Avron and Beata Konikowska ... Foundations and main properties - Philippe de Groote and Sylvain Salvati (Introductory course, ... An introduction to minimalist grammars - Greg Kobele and Jens Michaelis (Advanced course, ...
    (comp.specification.z)
  • Re: Rules of deduction.
    ... derived from words in spoken language, eg. if, not, all, some. ... The rules of inference in symbolic logic are derived from methods ... it is very interesting to see how quantification differs ... modern logics. ...
    (talk.origins)
  • Re: object system...
    ... granted, this assumes the barber used imperative logic, an actual human ... The paradox only says that the statement is contradictory within given ... bounds of a given language, and is conditional to the logic. ... all extended logics have to be based on a ...
    (comp.object)
  • Re: [Lit.] Buffer overruns
    ... this is a long rant about the links between language ... Both to some extent but definitely worse within the C community than in, ... >> culture (I am contrasting Ada and C only because I have a lot of first ... culture of low level design that it has unwittingly fostered. ...
    (sci.crypt)