Re: The Promise of Forth

Jonah Thomas wrote:
John Doty <jpd@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Jonah Thomas wrote:
John Doty <jpd@xxxxxxxxxxxxxxxxxxxxxxx> 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.

Of course logic can be mis-used. So can anything else.

But the True Believers in logic do not understand this. Real logicians do, of course. Mathematician Reuben Hersh asserts (correctly, I believe) that mathematics and logic find necessary properties of imaginary objects. That's only useful in the real world to the (always imperfect) extent that those imaginary objects correspond to real ones.

What error in logic or its use did Berkeley make in his logical demolition of calculus? I know of none. Yet calculus, practiced in the way Berkeley proved was logically wrong, is used successfully to this day. I've never seen an engineer actually use either the ε-δ method or nonstandard analysis. Your life depends on the results of the illogical Newton-Leibniz calculus every day.

You sure do
pick-and-choose about what you believe.

It might seem that way if to you "truth" is a concept that applies to the imaginary objects of logic and mathematics. But I'm interested in practical, real-world truth.

Illogic is also easy to mis-use.

The discipline is testing against reality. You compare your hypotheses against experiment, observation, history, anything and everything you have.

The genius of the scientific method is that the reasoning behind the hypothesis does not matter: it can be superstition (Kepler), flawed mathematics (Newton), or simply a guess.

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.

When they're different enough that it causes problems, then you should
distingush between them.

That's not a logical statement. It requires judgment.

Of course no two things are identical so in the
extreme case you'd completely avoid generalizing. But we're finite
beings and we benefit by lumping things together to some extent.

Lumping the "truth" that pertains to imaginary objects with the "truth" that works in the real world may indeed be part of our muddle here.

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.

If you *lack* internal consistency then you get troubles from that.

Why? What if internal inconsistency does not cause failure of real world tests?

Ideally you want to get internal consistency and also have it match up
to the external world. You gain nothing by leaving the internal
contradictions in. That doesn't at all help you link up to reality.

Ah, but often it does, because removing contradictions breaks the link with reality. Happens fairly frequently in physics.

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.



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.

Sure, if you have the prestige to get noticed. Easier when the guys who
got the Nobel prize for the previous wrong interpretation were from an
institution that your worldclass institution is in direct competition
with.

Muller and Bednorz were very low profile until they made their discovery.

Another example that *would have* won the Nobel is cold fusion. The guys who came up with that weren't even physicists, but there was *tremendous* interest in it at places like MIT (I was there). Of course it dissipated when the results could not be reproduced, and as more details came out showing the original experiments were very sloppily designed and executed.

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.

Sure. At any given time we have all the hypotheses that stand up to the
testing so far.

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.

No thank you, I've done enough of that recently.
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. 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?

Is the cretan correct when he says no cretan ever tells the truth? If
he's right then he's telling the truth. That means the statement is a
lie. But if it's a lie then it doesn't prove a cretan has ever told the
truth. So it could easily be true. But if it is true then he's telling
the truth and it's a lie. It flipflops back and forth. You make models
that take finite time to go through this cycle and you get an
oscillator. Which is more applicable to language? If you're talking
about truth, a statement that denies itself cannot be true.

And that one (the famous Epimenides paradox) cannot be false either. But there are nonstandard logics that can accommodate this just as there are non-Euclidean geometries. And these days, Euclidean geometry is no longer our best model for the geometry of space: Riemannian geometry currently holds that title. So why should we expect classical logic to be the right model for all circumstances?

Your
physical model reflects that by oscillating, and if you interpret that
as a model of language that contains an internal contradition then you
have a good model. If you want to use your physical model to do
something else, something that depends on the speed your system does the
logic, that has nothing to do with the model of the language.

If you had a tireless logician who never got bored, you could give him a
piece of cardboard that had printed on it "The answer to the question is
on the other side of this page" and you might depend on him to turn the
page over and over in a regular rhythm. You could use him as a cooling
fan. The rate of airflow would depend on the speed he happens to think
it out and turn the page over, which does not at all depend on the logic
-- except that the more complicated the sentence he parses the slower
he'll do it.

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).

If Bohr got A and ~A then Bohr was confused. (Or he was scamming
physicsts.)

There are trivial truths and the great truths. The opposite of a trivial truth is plainly false. The opposite of a great truth is also true.
- Niels Bohr

He wasn't scamming anybody: he was creating a theory that *works*.

You can always win if you can get away with "Heads I win,
tails you lose."

Bohr's physics makes solid (although statistical) predictions about the real world. It just gets there in a way that many find illogical. But, despite herculean efforts, no reproducible discrepancy with experiment has ever been found.

If you have two theories that give different results,
and you can arrange to use one of them whenever you get one result and
the other whenever you get the other result, and you call them the same
theory, you potentially have a scam. If you get to decide which theory
to apply after you find out what the answer is, that isn't very good. If
you have a solid workable rule to explain when to apply each theory,
then you have something that works -- and you might as well give
different names to the circumstances that fit the different theories.

You need to study some physics. It isn't like that.

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 trouble is, illogic is confusion.

Only if you insist on using logic. There can be no justification for that except blind faith.

You argue that it's better to be
confused than to get it clear.


But the search for clarity encourages
good experiments. It shows up useful problems to resolve.

That is true. But one should not read any significance into a failure to resolve the "problems". There is no more reason to expect real truth from logic than there is to expect real truth from Euclidean geometry.

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.

Buhr was confused. He tried to apply concepts that did not apply, and
the result was further confusion.

No, the result was a theory that *works*. You are using some of the engineering fruits of that theory as you read this on your computer.

Besides, what is wrong with Bohr's statement? Why should you expect logic to apply in an area far outside the experience of the people who originally formulated it?


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".

Consider this a first approximation to your argument, with some of the
confounding complexities removed.
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.

Each organism has its own limiting factors.

Indeed. So, what are Forth's limiting factors?

Classical experiments with
flour beetles showed that in competition one species died out when the
moisture level was high, the other died out when the moisture level was
low, and in between it was something of a tossup. Suppose the moisture
was in the tossup range but you tried high and low salinity. High and
low temperature. Etc. You might find other ranges where other variables
are limiting.

Sometimes you emphasize the subliminal programmer-psychology factor, and
sometimes you deny it.

Huh? Example?

You point out that successful languages cater to
the way their users already think.

In some ways. On the other hand, you also have to show them something better than they've got.

But consider also that bragging
rights make a big difference. In the old days, assembly language
programmers had to be smart, they had the reputation for being the
smartest. But they wrote code that went obsolete as soon as the
particular processor went out of date. C let the elite programmers be
*more* elite. They were the smartest, they wrote the fastest smallest
code, they went hand-to-hand on the bare metal. C let them do most of
that and also write portable code that didn't go obsolete so fast.

It, along with Forth, also put elite programmer power in the hands of domain experts. That was a very good thing.


Forth gave a similar mystique, but there were many incompatible Forths.
Forth-83 made most of the Forth-79 code obsolete. And there was the
claim that Forth was easy. Nobody said assembly was easy, and C was
still hard.

But in my shop we just had one Forth, along with a large body of code. Still, when C came along, people rather quickly found that it gave them the ease of Fortran without the limitations. And by that time the edit-make-run cycle was down to about 30 seconds, fast enough to make Forth's interactivity seem a minor advantage.

There's far more prestige in doing things that only very
smart people can do, hard things.

Yes, but in my shop it was making the most sensitive and accurate instruments, not sophisticated code.

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?

First, it wasn't the same environment. Second, it was a different name.
Imagine you had two languages with two different names and there was no
important difference between them. Chances are one of them would tend to
win out. Why stick with two different languages when the weaker of them
has nothing special to recommend it? Why did C win out over Objective-C?
There were important differences in that case. Was it some fatal flaw in
Objective-C?

As someone who preferred Objective-C, I think the answer is similar to the answer for Forth: Objective-C has rather odd syntax, confusing to ordinary users.

How about Borland-C? Haven't there been a lot of C
compilers that lost out? Did each of them have a fatal flaw? Are you
sure that the survivors are all the best of breed?

They're good enough.


Yes, you said that repeatedly.
Indeed. One more truth the Forth community doesn't like to hear.


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?

At the time, C wasn't interpreted. Harder to build little scripted
widgets that did whatever you wanted. So fewer of them got built. Or
maybe some other explanation. I'm making this stuff up because I don't
know the answers and you ask for answers. I can make them up faster than
you can disprove them. And it's all historical stuff where we can't
perform good experiments unless they happened to get performed and the
results recorded. Unless we could get a time machine and access to a lot
of parallel worlds.

The best we can do is what it is.


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?

When you talk about particular limitations that matter to particular
users, people tend to respond. We've had some talk about how to improve
library support, how to add type-checking, how to implement other
languages in Forth, improved string handling, the problem of using
libraries written in other languages (mostly solved for commercial
implementations), etc.

It's all good, but not, in my judgment, adequate. Tinkering around the edges, constrained by the delusion that the standard is something valuable.

When you say that Forth is fundamentally
inadequate and requires fundamental changes to keep it from sinking into
justified oblivion, people mostly disagree with you.
Have you noticed this pattern yet?

Oh, I'm used to that pattern. It takes a long time to break down groupthink. Do you have *any* idea how backward and collectively stubborn NASA is? Nevertheless, one can sometimes get people to listen. HETE-2 was an example.


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.

Sure. Now, what Forth does is it gives you a chance to define what you
need using the resources the Forth VM gives you. The fewer layers of
abstraction etc you build into your solution the less cruft. That's fine
for people who care about elegant solutions. Do we want people to use
Forth when they just want to crank out a solution with no thought for
how the VM does things? We're getting pulled in lots of directions here.
We can add typecasting and it makes some kinds of optimisation easier.
Or we can eliminate some of the types we already have and get easier
programming at a resource cost. Different directions.

There are various ways to hide Forth details so it's easier to get quick
results. Like, locals in place of data stack ops. If we got enough of
that we could make a Forth application that could compete as a scripting
language. Is that worth doing? Why hasn't it been done more? I think the
main reason is that it doesn't get results that Forth programmers want.
We program for ourselves, not for scripters who might want a Forth-lite.

Forth is mainly for hermit programmers (and I include myself).


At the moment it seems like pretty much everybody's going with
abstractions. Solve the problem on an abstract level and get some sort
way to implement the abstractions, and you don't have to worry about the
details. Build up abstractions on abstractions. If you implemented the
abstrations *correctly* then your abstract code will eventually deliver
correct results provided there are sufficient resources available.

Forth is the main place I see where there's an effort to keep the whole
system simple. If there's some cheese in that maze, we're the ones
who'll find it. Should we give that up so we can instead compete with
other languages where they're strong? (Incidentally, am I wrong about
that? Are there others I haven't noticed who're working at whole-system
simplicity?
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.

Another approach is to watch what works for you. If Chuck had studied
successful languages in the 1960's, what would he have based Forth on?
COBOL and Fortran?

A good approach would have been a "machine-independent assembler" similar to the Forth he created, with an interactive Fortran or BASIC layer above. Bob Frankston actually did something like that when he created ECD BASIC a few years later, but ECD's hardware business lost too much money and the company folded, so few ever saw the product. But I did some of the early simulations for the RXTE (xte.mit.edu) design with it.

But Chuck was ideologically committed to a single layer of language, as strongly as von Neumann had been to octal a generation earlier.

--
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

  • 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: The Promise of Forth
    ... logical contraditions, it's sloppy. ... but that can simply reflect the difficulty with language. ... But our common culture still holds logic in a superstitious regard it manifestly doesn't deserve. ... (there are many "logics" these days, just as there are many "geometries") ...
    (comp.lang.forth)
  • 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: The Promise of Forth
    ... Lumping the "truth" that pertains to imaginary objects with the ... Ah, but often it does, because removing contradictions breaks the link ... Happens fairly frequently in physics. ... Other logics might have other uses. ...
    (comp.lang.forth)